4 ms·

React Component Principles and Best Practices for Better Software Architecture

16 points by petar_ivanov 2y ago

petar_ivanov 2y ago
In this article, we will go through: Function Components vs. Class Components Name of Components Helper Functions Repetitive Markup Component’s Size and Length Props Ternary Operators Lists Mapping Hooks vs. HOCs and Render Props Custom Hooks Render Functions Error Boundaries Suspense
- spoiler 2y ago
  Instead of a config object and a .map(), just using plain components make more sense: <ProductList> <Product name="Foo" price={1.99} /> <Product name="Bar" price={2.75} /> <Product name="Baz" price={3.49} /> </ProductList> If the list is large or dynamically tendered, then sure mapping over a list makes more sense. Also, passing in props as object isn't always sensible. Sometimes just spreading them out as individual props makes more sense if they're consumed together (ie to an Address one I'd prefer to use individual props instead of <Address address={address} />). There's nothing too wrong with components that have many props (I guess same thing that applies to functions with long argument lists applies here too, which is they can be annot to call, but use common sense). The re-rendering thing shouldn't be a problem. You want thing to re rende if props change (assuming there's not an accidental referential instability causing spurious re-rendering) There's also less potential performers gotchas with objects vs primitives due to how props get reconciled between rerenders), but this depends a lot on how the objects are created too. As a rule of thumb, people should prefer primitives, not rich objects that get passed as a single props. The caveat here is that there's exceptions The other stuff is sensible Edit: wordsmithing
zorrn 2y ago
[flagged]
latsu 2y ago
I think I'm growing tired of reading articles and books that disguise opinions as "Best Practice." I find most of these types of articles and guides lacking in substance. All of them seem to use blanket statements that lack any evidence as to why the claim being made is true. We are just expected to trust the author, when the author isn't even an expert in the topic they are discussing.
- spoiler 2y ago
  Some of these are (hopefully) common knowlwdge to react devs by now. Although, even though I disagree with some things on that list. They're most certainly not considered good practices, but they're also not the end of the world, really. The "burns" they'd acquire when applying some of the these tips would lead to great learning opportunities too (without being major setbacks). Overall, a very decent article for someone starting off with React!
- pylua 2y ago
  This is very common and will happen almost everywhere you work. As an industry we should spend our time pursuing other areas that are more objective. I have nothing against the article, or the author, but especially with linked in expert opinions there is a lot of noise.
- danielhep 2y ago
  The author does have this disclaimer in the article: > Take everything as an opinion. Software can be built in multiple ways.
puskuruk 2y ago
There is nothing new. Why people upvoted this article?

16 points by petar_ivanov 2y ago

In this article, we will go through: Function Components vs. Class Components Name of Components Helper Functions Repetitive Markup Component’s Size and Length Props Ternary Operators Lists Mapping Hooks vs. HOCs and Render Props Custom Hooks Render Functions Error Boundaries Suspense

spoiler 2y ago
Instead of a config object and a .map(), just using plain components make more sense: <ProductList> <Product name="Foo" price={1.99} /> <Product name="Bar" price={2.75} /> <Product name="Baz" price={3.49} /> </ProductList> If the list is large or dynamically tendered, then sure mapping over a list makes more sense. Also, passing in props as object isn't always sensible. Sometimes just spreading them out as individual props makes more sense if they're consumed together (ie to an Address one I'd prefer to use individual props instead of <Address address={address} />). There's nothing too wrong with components that have many props (I guess same thing that applies to functions with long argument lists applies here too, which is they can be annot to call, but use common sense). The re-rendering thing shouldn't be a problem. You want thing to re rende if props change (assuming there's not an accidental referential instability causing spurious re-rendering) There's also less potential performers gotchas with objects vs primitives due to how props get reconciled between rerenders), but this depends a lot on how the objects are created too. As a rule of thumb, people should prefer primitives, not rich objects that get passed as a single props. The caveat here is that there's exceptions The other stuff is sensible Edit: wordsmithing

zorrn 2y ago

[flagged]

latsu 2y ago

I think I'm growing tired of reading articles and books that disguise opinions as "Best Practice." I find most of these types of articles and guides lacking in substance. All of them seem to use blanket statements that lack any evidence as to why the claim being made is true. We are just expected to trust the author, when the author isn't even an expert in the topic they are discussing.

spoiler 2y ago
Some of these are (hopefully) common knowlwdge to react devs by now. Although, even though I disagree with some things on that list. They're most certainly not considered good practices, but they're also not the end of the world, really. The "burns" they'd acquire when applying some of the these tips would lead to great learning opportunities too (without being major setbacks). Overall, a very decent article for someone starting off with React!
pylua 2y ago
This is very common and will happen almost everywhere you work. As an industry we should spend our time pursuing other areas that are more objective. I have nothing against the article, or the author, but especially with linked in expert opinions there is a lot of noise.
danielhep 2y ago
The author does have this disclaimer in the article: > Take everything as an opinion. Software can be built in multiple ways.

puskuruk 2y ago

There is nothing new. Why people upvoted this article?