News for hackers. Stuff that matters.
Re:React Component Principles and Best Practices for Better ... by petar_ivanov on Thursday May 23, 2024 @10:48AM (#40455417)
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

Re:React Component Principles and Best Practices for Better ... by spoiler on Thursday May 23, 2024 @04:31PM (#40459565)
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