Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
React render function organization
// See for slides
// My basic render function structure:
function RenderLogicExample({
someBoolean, // 1) Destructure values from `props` object
}) {
// 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 = => (
<ListItem key={} item={item} />
// 4) Use a single JSX structure filled with content
return (
A: {a}, B: {b}
Copy link

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

Copy link

baebb commented Oct 27, 2016

Thanks for sharing

Copy link

DenJohX 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 {
        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 =;

        // continue with the usual

Copy link

kyleshevlin 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?

Copy link

buoyantair commented Jul 24, 2017

This is sweet!

Copy link

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

Copy link

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

Copy link

ZanshinPost commented Dec 3, 2017

minor remark, I would add index to the listitem

Copy link

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

Copy link

hsavit1 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