[rhacker]

Seems to be roughly the same amount of boilerplate as useContext, so I don't fully understand the separate purpose for it?

[tshaddox]

Recoil allows you to create atoms and selectors in loops without having to add an entire new Context.Provider component to the root of the React component tree, which would obviously not be viable since the entire tree would need to be torn down each time.

[beirut_bootleg]

This is the part that completely lost me. Why do you need an additional context for each item? Isn't one context holding all items enough?

[tshaddox]

If you have a lot of pieces of data in one React context, every component that uses any little piece of that data will re-render whenever any part of the data changes.

[rhacker]

React has more intelligence built in than that. That's definitely not quite how it works.

[davidmccabe]

React doesn't have to commit to the DOM if there are no changes, but it still has to render each component and compare the output. Even if the component is memoized, it still has to compare the props. This is fast enough most of the time but it can become a bottleneck in some cases.

[baddox]

Yes, and component memoization (and PureComponent and shouldComponentUpdate) only prevents re-rendering of the component's descendants. But every component that uses a context value will still re-render every time that context value changes, which could potentially be way too many.

For example, if every Cell component in a big Table component is using the same context value, they will all need to re-render when any cell value changes, regardless of whether the Cell component or some of its descendants are memoized. This is a common pattern in Redux, which solves this problem and will only re-render the Cells which are using cell values which have changed. Recoil would provide the same benefit.