15 Matching Annotations
  1. Aug 2021
    1. All consumers that are descendants of a Provider will re-render whenever the Provider’s value prop changes
    1. My personal summary is that new context is ready to be used for low frequency unlikely updates (like locale/theme). It's also good to use it in the same way as old context was used. I.e. for static values and then propagate updates through subscriptions. It's not ready to be used as a replacement for all Flux-like state propagation.
    2. One problem with the "Context vs Redux" discussions is that people often actually mean "I'm using useReducer to manage my state, and Context to pass down that value". But, they never state that explicitly - they just say "I'm using Context". That's a common cause of the confusion I see, and it's really unfortunate because it helps perpetuate the idea that Context "manages state"
    3. createContext() was designed to solve that problem, so that any update to a value will be seen in child components even if a component in the middle skips rendering.
    1. The Redux FAQ has some rules of thumb to help decide whether state should go in Redux, or stay in a component.In addition, if you separate your state by domain (by having multiple domain-specific contexts), then the problem is less pronounced as well.
  2. Mar 2021
  3. Nov 2020
  4. Oct 2020
    1. Context can only store a single value, not an indefinite set of values each with its own consumers.
  5. Aug 2020
    1. I would shy away from using contexts as your application state. They're intended to be used sparingly. It's likely that some child is changing something in the context and as several items access that context, they're seeing that as a state change they have to care about. I'd highly recommend moving away from contexts as mini-stores and instead focus on how you structure your component tree and the state each one manages.
  6. Dec 2019
  7. Nov 2019
  8. Sep 2019
  9. Oct 2018