feat(StateStore): state modifiers and store merging

[arnautov-anton]

Description of the changes, What, Why and How?

• adds state preprocessors (like middleware for state change before state is commited to subscribers)
• adds store merging

[github-actions]

Size Change: +5.08 kB (+1.24%)

Total Size: 414 kB

Filename	Size	Change
dist/cjs/index.browser.cjs	119 kB	+1.68 kB (+1.43%)
dist/cjs/index.node.cjs	163 kB	+1.71 kB (+1.06%)
dist/esm/index.js	132 kB	+1.69 kB (+1.3%)

_{compressed-size-action}

[MartinCupela]

Do we want to give a try to utils/mergeWith.ts? It could be handy for nested objects like message composer config is

[arnautov-anton]

I don't think this will be needed as the mechanism does only a shallow merge due to potential type conflicts, see this part which dissalows merging two stores if they have top-level keys in common.

const storeA = new StateStore({ a: 1, b: 2 });
const storeB = new StateStore({ x: 1, b: 'aa' });

storeA.merge(storeB); // type error -> both stores have `b` state property

If this was not in place, the state would produce unexpected results whenever either of the states changed.

If storeA updates b to, let's say 10 - the merged store would look like this: { a: 1, x: 1, b: 10 } while the merged type would look like this: { a: number; x: number; b: string | number }. Subscribers with selector pointing to b would receive 10. Then storeB updates b to hello now subscribers with selector poiting to b would receive hello and suddenly there's no value/type stability - this does not seem that bad until you decide to get latest value and you need b value to be a number but since storeA hasn't changed since, you'll get hello instead.

Potential solution to this problem is to have the actual merged state object look like this:

type MergedStateStoreState<X, Y> = {
   original: StateStore<X>;
   merged: StateStore<Y>;
}

But even in this form there's no need for mergeWith just yet.