3 ms·

We use it for application-wide stuff that would need to be drilled down several layers, and isn't state. So -- as a contrived example -- if we have a form that

by frio 8y ago

We use it for application-wide stuff that would need to be drilled down several layers, and isn't state. So -- as a contrived example -- if we have a form that submits to a configurable URL (configurable at build time), then we wrap that URL up in a context. The eventual FormComponent will then consume the URL from context, rather than being drilled through n-layers of React components as a prop. Redux isn't the right answer here, because that URL's never going to change, but it used to do the job in a pinch. Other examples are react-redux itself (which uses the legacy context API) or react-intl (which uses the legacy context API), or a themeable widget set. You put a wrapping context at the top of your tree like <Provider>, <IntlProvider messages={someMessages} locale={this.state.locale}> or <ThemeProvider theme={myEmployersColours}>, and then nested deeply in the application you use a <Message> that will look at the context provided by the IntlProvider, or the context provided by the theme, to pull out the actual message/colors it should show. Basically, context is useful for encapsulating cross-cutting concerns :).

Waterluvian 8y ago
Aha. Okay I think I'm having a moment. I could possibly use this to pass a reference to a websocket stream for streaming data that's way too high frequency to be handled with redux actions. Say, 100 robots driving around, displayed by a map component. I want to handle the addition of removal of a robot as an action but the actual 10hz pose updates can just be handled by the canvas and ignored by react entirely. Maybe even context for camera streams too. Previously I would just handle a websocket stream as a global. Yuck.
- acemarke 8y ago
  Note that context updates do require that React walk over the component tree to find the appropriate consumers, and that itself has a cost. In fact, at the moment, it seems to be _relatively_ expensive, per the discussion in this issue : https://github.com/facebook/react/issues/13739 https://github.com/facebook/react/issues/13739 . We're actually working on converting React-Redux to use `createContext` in version 6. I had hoped that it would be a big performance improvement, but unfortunately our (admittedly limited) perf benchmarks indicate that the experimental v6 branches are slower than our current v5 release build. In v5, the individual connected components subscribe to the Redux store, and can bail out of calling `setState()` if no update is necessary. In v6, we've only got one subscription (in `<Provider>`), but any Redux store update requires that React walk the tree and update the context consumers so they can run `mapState`. So, React _always_ gets involved, whereas before we might skip React if nothing had changed. Per that issue, I'm hopeful that the React team can optimize deep context updates in the near future.

by frio 8y ago

Waterluvian 8y ago

Aha. Okay I think I'm having a moment. I could possibly use this to pass a reference to a websocket stream for streaming data that's way too high frequency to be handled with redux actions. Say, 100 robots driving around, displayed by a map component. I want to handle the addition of removal of a robot as an action but the actual 10hz pose updates can just be handled by the canvas and ignored by react entirely. Maybe even context for camera streams too. Previously I would just handle a websocket stream as a global. Yuck.

acemarke 8y ago
Note that context updates do require that React walk over the component tree to find the appropriate consumers, and that itself has a cost. In fact, at the moment, it seems to be _relatively_ expensive, per the discussion in this issue : https://github.com/facebook/react/issues/13739 https://github.com/facebook/react/issues/13739 . We're actually working on converting React-Redux to use `createContext` in version 6. I had hoped that it would be a big performance improvement, but unfortunately our (admittedly limited) perf benchmarks indicate that the experimental v6 branches are slower than our current v5 release build. In v5, the individual connected components subscribe to the Redux store, and can bail out of calling `setState()` if no update is necessary. In v6, we've only got one subscription (in `<Provider>`), but any Redux store update requires that React walk the tree and update the context consumers so they can run `mapState`. So, React _always_ gets involved, whereas before we might skip React if nothing had changed. Per that issue, I'm hopeful that the React team can optimize deep context updates in the near future.