Main StoreGroup

[azu]

We have two StoreGroups.

• https://github.com/almin/almin/blob/master/src/UILayer/StoreGroup.ts
  • Always Async
  • Cache State
• https://github.com/almin/almin/blob/master/src/UILayer/QueuedStoreGroup.ts
  • QueuedStoreGroup work as Sync or Async.
  • QueuedStoreGroup prefer strict design than ./StoreGroup.js
  • QueuedStoreGroup not allow to change stores directly.
  • Always change stores via execution of UseCase.
  • QueuedStoreGroup has not cache state.

StoreGroup feature depended on application architecture.
Two StoreGroup make user confuse.

Which is better?

We should include a signle StoreGroup.
Other StoreGroup should be separated as npm pacakge.

[azu]

I've tried to write new StoreGroup.

azu/almin-cqrs-example#2

It is more strict version of QueuedStoreGroup.

• It make StoreGroup#onChange is called when store is actually changed.
  • It means that it does diffiing prev state and next state.
• It make Store and State read-model.
  • It means that the user can only write pull-design code on Store.
  • No this.onDispatch, No repository.onChange in Store
  • Make CQRS come true. (read stack)

Cons:

• It make Store#getState signature change.
• Call Store#getState many time

We should measure performance of that.

[azu]

Store#getState<T>(prevState: T, payload): T;

I found a problem in this signature.
Logger like almin-logger can't get the state of store, because the Store#getState depended on prevState and payload.

• fix(logger): Store#getState may needed arguments almin-logger#12

Instead of that, a logger can get the state from StoreGroup or Context.
Because, call StoreGroup#getState() without arugments and return currect states.

Currently, StoreGroup and Store is inherited StoreLike interface.
Actually, StoreGroup#getState()'s signature difference from Store#getState(prevState: T, payload).
We make these difference thing.

[azu]

Add new StoreGroup #154

[azu]

We going to separate current StoreGroup and QueuedStoreGroup as a @almin/legacy-store-group module.

Why legacy?

We will define that new StoreGroup arguments is mapping object.
Current StoreGroup and QueuedStoreGroup accept an array of Stores.

Mapping Object?

new StoreGroup({
    "stateName": store
});

Pros

• Make type safe in current typescript feat(TypeScript): Make Context#getState explicit #166
• Define state name out of the Store

Cons

• Can't define state name in the Store
  • == Define state name out of the Store
• ?

[azu]

I've created almin/legacy-store-group: Almin old StoreGroup and QueuedStoreGroup implementation.