Shareable container implementation

[albertogasparin]

Evolution after #196 discussion.
We are inverting the Container / Store relationship. Now stores can link to a container via containedBy so containers can be shared across stores. Container actions also move to the createStore API (under handlers) so there is no need to distinguish between stores in a multi store containment situation.
This also makes Containers extremely lightweight, as they can be imported anywhere in the tree without risking importing actions and other Store specific implementations. It will also enable erroring whenever a store should be containedBy but it is not (#190).

From:

const Store = createStore({
  initialState: { count: 0 },
  actions: { ... },
});

export const CounterContainer = createContainer(Store, {
  onInit: () => ...
});

to

export const CounterContainer = createContainer();

const Store = createStore({
  containedBy: CounterContainer,
  initialState: { count: 0 },
  actions: { ... },
  handlers: {
    onInit: () => ...,
  }
});

We will still support the old API, which now becomes a way to provide overrides in specific situations (eg tests). So if a store has containedBy but the subscribers render under a Container that was created explicitly with that store argument, such container will own the state even if it was not the one specified in containedBy.
The risks of having both styles in a codebase should be minimal, and we can soft push to adopt the new pattern by promoting it by default on the docs and progressively move to it via linting and codemods.

[albertogasparin]

Please review @theKashey and @anacierdem 🙏🙏🙏🙏 (hopefully for the last time)

[theKashey]

Long story short:

• containedBy: CounterContainer to define a "boundary"
• createContainer to create a container in place - for testing, or just because one needs it in place. I've got example with "nested" containers passing "accumulated value" to the children.

And I really like how CounterContainer(from example) can provide props to all nested onInit functions, no matter how many stores are containedBy inside

[theKashey]

• the readme/docs update is very missing

[anacierdem]

Liked the new API, I definitely think this is the correct direction as well. Also it was a good opportunity for me to study the code a little. Let me know if I am off on any of my comments, would like to understand the library better.

Thank you @albertogasparin for this bold change!

[anacierdem]

Is this here for future reference?

[albertogasparin]

Yes, wanna test it in product behind FF, so this makes it easier

[anacierdem]

This indeed introduces a construct similar to that of #146 Even though I am not certain how it will turn out right now, feels like the correct direction.

[albertogasparin]

Addressed the PR comments and published the reworked docs

[theKashey]

Quite solid work, you've invested much more effort than I anticipated, but the outcome is also proportionally better 🎉

[theKashey]

Last moment question - should handle behaviour for stores marked to be containedBy or let's keep this behavior for

• separate configuration option, right now containedBy is "will be containedBy", not "must be containedBy"
• Non global states #190 in general. Isolation and "shareable" sounds like different things.

Why:

• there were a few examples when one had an intentionally placed Container, but the "read" or "write" operations were made from another branch, and something expected to be a singleton was behaviour as two isolated stores.
• problem was resolved by removing Container
• it took ~3 days to figure out the problem 😃

If there was something to shout at me earlier - that would save 3 dev days 😉

[albertogasparin]

If there was something to shout at me earlier - that would save 3 dev days

Yes, that will come right after this PR. Didn't wanna overload this one too much because it already has lots of changes 😄
It will be "must be containedBy", and Registry will validate whenever store has that attribute and throw an async error if that registry is the global one.