Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
React render function organization
class ParentComponent extends Component {
render() {
// My basic render function structure:
// 1) Extract values from props and state
const {a, b, someBoolean, someList} = this.props;
// 2) Render any dependent items into temporary variables, such as conditional components or lists
const conditionalComponent = someBoolean ? <SomeComponent /> : null;
const listItems = someList.map(item => <ListItem item={item} />);
// 3) Use a single JSX structure, with the temporary variables in the correct spots.
// Note that I avoid logic inline in my JSX. That's perfectly legal, but I prefer to
// make the use of that logic as clear as possible by keeping it outside the JSX.
return (
<div>
<div>A: {a}, B: {b}</div>
{conditionalComponent}
{listItems}
</div>
);
}
}
@approots

This comment has been minimized.

Copy link

commented Sep 28, 2016

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.

@justrossthings

This comment has been minimized.

Copy link

commented Oct 27, 2016

Thanks for sharing

@DenJohX

This comment has been minimized.

Copy link

commented Oct 27, 2016

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
    }
}
@kyleshevlin

This comment has been minimized.

Copy link

commented Apr 18, 2017

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?

@buoyantair

This comment has been minimized.

Copy link

commented Jul 24, 2017

This is sweet!

@ryanflorence

This comment has been minimized.

Copy link

commented Sep 18, 2017

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.

@ajchambeaud

This comment has been minimized.

Copy link

commented Nov 12, 2017

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...

@ZanshinPost

This comment has been minimized.

Copy link

commented Dec 3, 2017

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

@medv

This comment has been minimized.

Copy link

commented Jun 25, 2018

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

@hsavit1

This comment has been minimized.

Copy link

commented Sep 24, 2018

so no render props ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.