Is it just me, or does the new context API defeat the ease and flexibility of the old context? Now I have to wrap users of context within a consumer component and a wrapper function call which is tightly coupled to the provider. Why can’t I simply have a props-like data structure with an origin of arbitrary anscentry?

In defense of the new stuff, the “tight coupling” I referenced isn’t as bad as it may initially appear (at least to me). For example, I saw instances created via createContext, but in reality it’s a class factory and you can instance those classes to your little heart’s desire. In other words, consumers aren’t tied to a single provider that was created with createContext. The component hierarchy is, in fact, traversed to find the closest instance of a respective provider and uses that for a data source. You can create multiple providers and have consumers pull from any one of those depending on the parenting.

This can give you the older style, “arbitrary” provider behavior assuming you only ever use the same provider/consumer classes. But that requirement still makes it more difficult since any redistributable components that may act as consumers since they have no implicit way of knowing what kind of provider is going to be used and thus won’t be able to implement a respective consumer, at least not unless explicitly given one. And at that point we’re back to passing props through children again. But at least it’s only through changes of responsibility.

So I managed to implement something with it specifically when you have many different files / components in files. It’s great I’m in love! When is the final release? Alpha got announced back in February already. I know they have fast release cycles.

After reading this, I guess I need to use redux here. What do you guys think?

Is it a Redux killer?

No. The new Context API has its limitations.

For example, it encourages the use of immutable or persistent data structures or strict comparison of context values which might prove difficult because many common data sources rely on mutation.

Another limitation is that the new Context API only allows for a Consumer to read values from a single Provider type, one consumer to one provider. Unlike the current API, which allows a Consumer to connect to multiple Providers.

Each provider will have its own distinct value. Consumers will look up the React dom hierarchy until it finds a matching provider and use its value.

If you have a single value you want to share, then you’d use one provider that wraps multiple consumers. If you have multiple renders targeting different DOM elements, you might want to use a portal to manage that while being able to keep your components within the same provider.

I think you got the idea with withContext, though I’m not sure your code makes a lot of sense. Aren’t you trying to avoid having <Consumer> in Factory, converting it’s value into a prop by using withContext?