React render function organization

render-logic.js

// See https://blog.isquaredsoftware.com/presentations/react-redux-ts-intro-2020-12/#/36 for slides
// My basic render function structure:
function RenderLogicExample({
  someBoolean, // 1) Destructure values from `props` object
  someList,
}) {
  // 2) Declare state values
  const [a, setA] = useState(0);
  const [b, setB] = useState(0);

  // 3) Render any dependent items into temporary variables,
  //    such as conditional components or lists
  const conditionalComponent = someBoolean ? (
    <SomeConditionalComponent />
  ) : null;
      
  const listItems = someList.map(item => (
    <ListItem key={item.id} item={item} />
  ));

  // 4) Use a single JSX structure filled with content
  return (
    <div>
      <div>
        A: {a}, B: {b}
      </div>
      {conditionalComponent}
      {listItems}
    </div>
  );
}

Yeah, this is clearer than {someBoolean && <SomeComponent}}. I take this one step further and extract to sub-render methods (e.g. {renderConditionalComponent()}). Since sometimes the logic is complex and calls for it's own render method, if I always do it then the code style is consistent.

Thanks for sharing

I would preffer to do the maps over a method instead of defining it inside the render, for example:

class ParentComponent extends Component {
    renderListItem(item){
        return (
            <ListItem item={item} />
        )
    }

    // some other methods...
    render () {
        // ...extract values from props, state and so

        // ...conditional components,

        // here the map is done without re-defining the
        // function each time we render.
        const listItems = someList.map(this.renderListItem);

        // continue with the usual
    }
}

I hadn't considered defining the map callback function as a performance boost. Given enough items to map, I could see this making a noticeable difference.

That being said, rather than creating a method, you could define it as a named function or variable in the render function. Perhaps between steps 1 and 2.

Is there any significant benefit to the callback being a method versus a named function?

This is sweet!

I keep all my control flow inline, but calculations outside. I like it all inline so I know why something is or isn't rendering without bouncing around the file. Every variable is an abstraction with a cost of indirection. Not every branch deserves a name, just like css class names, naming fatigue slows me way down, and the names usually don't help with understanding anyway.

You don't need any other method returning UI elements rather than the render one. If you need to split the render method, then you should probably create another Component instead. Scrolling class methods to change some UI behavior is not funny at all...

Nice.
minor remark, I would add index to the listitem

Defining a named function or variable in the render function is no different to just running the map directly in the render function. You are still declaring a new function every time render fires. Declaring it on the class, or outside of the functional component will use an existing reference to the function and improve performance in some cases, although not required for faster prototyping until an optimization step (if at all needed).

Adding index to listitem is an anti-pattern that will create mysterious problems down the track (unless you are familiar with these problems, in which case you already know to protect against it). Instead, the key should be set to a consistent value derived from the mapped items (ID, or a concatenated string of one/two string fields that appear in the object guaranteed to be stable/unique in this set of data).

https://codeburst.io/how-to-not-react-common-anti-patterns-and-gotchas-in-react-40141fe0dcd

so no render props ?

awesome, as a self-taught developer I'm always hesitating on simple things that I already know and do. Just reading codes from pros make me more confident about my thoughts and the style of the code I write, so much appreciated 💯