I’m curious how the CornFlux architecture would avoid the problems of store visibility and…
Travis Nuttall

Yes, you can define stores in separate files, and you can actually reuse a container as a whole (with its ActionProvider decorations) since it’s a component. If that makes sense in your domain. But if you do (re)use it, you get it as-is; you can’t cause regressions in other domains that it’s being used in since it isn’t global.

When I look back at how things evolved in Bridge, lack of visibility in itself wasn’t the problem. The real problem was in extending the scope of modules like stores so that they could accommodate multiple, different domains (e.g. screens.) Duplication is actually a less harmful strategy here.

If we get to a point where defining stores is very cheap and easy (which is already halfway there with the abstractions we have for the caching layer and for remote requests), we don’t need to create those cross-dependencies between consumers anymore. Compose a “new” store with the parts that you need and add to it the domain-specific functionality.

We already do much of this with components. We can apply the same concepts to those traditionally-monolithic entities too.

Using a single store to represent the state of the entire application feels almost like Ember where you have access to everything. If I’m in domain X, I should not have access to things defined by domain Y. It just feels like one massive-scale leak.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.