All consumers that are descendants of a Provider will re-render whenever the Provider’s value prop changes

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.

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"

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.

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.

Talking of context, that's much closer to the approach I take with Svelte and use a writable store.

Another difference is that context in Svelte does not insert anything into the visual component tree. There is no <Context.Provider> element like in React

Context can only store a single value, not an indefinite set of values each with its own consumers.

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.

FieldsFor

A context wrapper that handles checkbox state changes. Must wrap <TriStateCheckbox /> and <Checkbox />.