posts/no_react_context_is_not_causing_too_many_renders

[utterances-bot]

No, react context is not causing too many renders

A lot of people are under the impression that context shouldn't be used to store state, because it'll cause the entire application tree to re-render. This is a misnomer.

https://blacksheepcode.com/posts/no_react_context_is_not_causing_too_many_renders

[DeedleMan]

Thanks for the article! Well, how do we avoid rerender of RenderTracker on every keystroke in the last example?

[michaelwlu]

Great post. The point about directly rendered children and children passed in as props, what does that mean in terms of practical application? Should directly rendered children be avoided inside components that are consuming a context (assuming you're trying to hyper-optimize for performance)?

[iamsyh]

@michaelwlu i think they meant to demonstrate that just simply being children passed via a provider doesnt cause rerenders of said children unless they are consuming the context

[iamsyh]

Deedleman you could memoize it cause its re rendering due to the whole component and all its rendered elements are being rerendered

[dwjohnston]

@DeedleMan

Thanks for the article! Well, how do we avoid rerender of RenderTracker on every keystroke in the last example?

Use native form functionality and uncontrolled components.

Usually you don't actually need the value, until the user is pressing some kind of submit button. So do this:

function MyComponent() {
    

     return <form onSubmit={(e) => {
              const formData = new FormDate(e.currentTarget); 
              const formValue = formData.get('some-name'); 
              // do whatever you need with the value. 
      }}>
            <input type='text' name='some-name'/>
            <button type='submit'>Submit form</button>
     </form>
}

[dwjohnston]

@michaelwlu

Should directly rendered children be avoided inside components that are consuming a context (assuming you're trying to hyper-optimize for performance)?

So for example, say you had a component like this:

function MyWidgetPanel() {
    const [value, setValue] = React.useState(0)

    return <div className="widget-panel">
        {/* 👇 Controlled component causing a render on every keystroke */}
        <input type="text" value={value} onChange={(e) => setValue(e.target.value)} />
        <div className="header">
            <WidgetHeader />
        </div>
        <div className="main">
            <WidgetContent />
        </div>
        <div className="footer">
            <WidgetFooter />
        </div>
    </div >
}

This could be refactored to something like this:

type WidgetPanelProps = {
    headerContent: React.ReactNode;
    mainContent: React.ReactNode;
    footerContent: React.ReactNode;
}

function MyWidgetPanel(props: WidgetPanelProps) {
    const { headerContent, mainContent, footerContent } = props
    const [value, setValue] = React.useState(0)

    return <div className="widget-panel">
        {/* 👇 Controlled component causing a render on every keystroke */}
        <input type="text" value={value} onChange={(e) => setValue(e.target.value)} />
        <div className="header">
            {headerContent}
        </div>
        <div className="main">
            {mainContent}
        </div>
        <div className="footer">
            {footerContent}
        </div>
    </div >
}

The controlled component would still be causing renders every keystroke, but at least it won't be causing renders on the WidgetHeader, WidgetContent and WidgetFooter components.

[mrfratello]

Thanks for the article.

I would also like to exclude the rendering of the StateChanger component, since it does not depend on the value, and the 'setValue` function is constant.

I wish the useContenxt hook had a second comparison argument, as in memo (or move this comparison to createContext)

[ALBlash]

loved it 👏🏻

[srsandy]

Good one!