RFC: Add ComponentStore for managing local component state

[spierala]

A Component Store could be beneficial to manage state at a local (component) level.

But let's see what we have already in MiniRx...

MiniRx Store and Feature Store manage state at a global level:

MiniRx Store

• Is a classic Redux Store which manages a global state object
• In most cases the global state has the lifespan of the application
• Redux with its Actions and Reducers allows us to use Redux Dev Tools
• Store Extensions like the UndoExtension or ImmutableExtension are MetaReducers, which require Redux too

Read more in the MiniRx Store docs here: https://mini-rx.io/docs/redux

MiniRx Feature Stores

• Feature Store state is also registered in the global state object
• Feature Stores use Redux under the hood, so we can also use Redux Dev Tools and benefit from other Store Extensions (e.g. UndoExtension, ImmutableExtension)
• Feature Stores allow to interact directly with a specific feature state with a more easy API (no Redux Boilerplate :))
• API: select, setState, undo, effect, get state()
• Feature Stores are destroyable, therefore they can take the role of a Component Store

Read more in the MiniRx Feature Store docs here: https://mini-rx.io/docs/fs-quick-start

Feature Stores as Component Store

MiniRx Feature Stores come close to a Component Store since they are destroyable.
See an example in the Angular Demo here: https://angular-demo.mini-rx.io/#/counter

The "counter" Feature Store looks like this:
https://github.com/spierala/mini-rx-angular-demo/blob/main/src/app/modules/counter/state/counter-state.service.ts

Note that it has to provide a unique feature key:

constructor() {
    super('counter-' + id++, initialState);
}

The feature key is used to register the counter states into the global state object:

The counter component provides its own instance of the counter-state.service. See here:
https://github.com/spierala/mini-rx-angular-demo/blob/main/src/app/modules/counter/counter/counter.component.ts#L9

When the counter components are destroyed then the corresponding feature states are removed from the global state object.

Feature Stores as Component Store PROs & CONs

PROs

• Existing functionality can be reused (the Feature Store class) to have a store with the lifespan of the component
• The component state can be inspected with Redux Dev Tools, we can undo state changes, etc
• Feature Stores automatically use the extensions which are provided for the global store (e.g. ImmutableExtension)
• Since the component state is registered in the global state we can easily write selectors which combine other global state with the "component state"

CONs

• It is necessary to provide a unique feature key when instantiating the Feature Store
• When we register / unregister hundreds of Feature Stores at the same time there is a visible performance impact (only at the moment when the register/unregister happens, afterwards it is fine)
• If there are a lot of Feature Stores used as Component Stores they might "pollute" the global state object with a lot of state which is meant as local state.
• Local component state changes trigger emissions on the global state object which is odd and less performant.

MiniRx Component Store?

What could it look like?

• Same API as Feature Stores (select, setState, effect, undo, get state())
• No need to provide a unique feature key

Mini Redux?

• The Undo functionality would require that the Component Store is a little Redux Store itself
• If the Component Store is a little Mini Redux we could easily add support for some of the existing MiniRx extensions: ImmutableExtension, UndoExtension, LoggingExtension. Not sure about the Redux Dev Tools extension.

MiniRx Component Store PROs & CONs

PROs

• Component Store would be more performant than Feature Store (mostly if you have hundreds of components using Component Store)

CONs

• It could be confusing for the user of MiniRx to see another Store variant which is very similar to FeatureStore ("when should I use which one?"). We would have 3 variants: Store, Feature Store, Component Store
• There will be a lot of duplication in the docs since most of the API is identical with FeatureStore
• MiniRx would loose its focus on global state-management ( thats maybe a marketing thing ;) but I think a young library like MiniRx should have focus to become successful )
• Thinking about the future: enitityAdapter for Redux and a EntityFeatureStore? Would we need then also a EntityComponentStore?

Make the best of Feature Store?

Internal unique id creation?
We could try to make the registration of multiple Feature Stores more straightforward, especially the unique id thing, which could be handled internally

Detached Mode?
Prevent Feature Store from the registration on the global Redux store. Instead the Feature Store could fall back to a local Redux.
Again we need Redux mostly to keep the undo functionality (using the UndoExtension).

Non Goals

• Be a copy of ngrx/component-store

What do you think?

[nartc]

Thanks for opening this RFC.

TLDR; Dedicated Component Store is nice to have but not necessary. FeatureStore is probably a better solution with some rework

Initially, I think a dedicated Component Store solution would be nice to have for the following reasons:

• Easy to get started with (just a glorified Service-with-a-Subject)
• Pathway to migrate to FeatureStore if needs Global functionality

But the CONS you've outlined in the RFC are all valid. The overlap between Component Store and Feature Store will be large and will cause a lot of confusion for the consumers which, to me, I think is even worse than NOT having a Component Store at all.

That said, I'd still like to see a local-focused solution in terms of State Management from MiniRx. Maybe Feature Store can be reworked to be more local-focused? Several concerns come to mind:

• Selector usage needs to be simplified for Local State management. Memoized selectors are great but might be overkill for a Local State solution.
• Ease of instantiating multiple instances of the same Store.
• Utilize the existing Extension?
• (Will be really nice) if Redux Extension can be worked in, this is currently missing from other Local State solutions (RxState, ComponentStore)

PS: Should this be a Discussion rather than an Issue?

[spierala]

Thanks so much for your feedback @nartc!

I have the same feeling that it is probably better to not have a Component Store in MiniRx. And FeatureStore can be reworked to be more component state friendly.

Here some feedback on your feedback :)

Easy to get started with (just a glorified Service-with-a-Subject)

Actually it is easy to get started with Feature Stores too. You only have to extend FeatureStore and provide the feature key and initial state. Nothing more is required. configureStore / StoreModule.forRoot is optional and only needed if you want to provide extensions or initial global state.

Selector usage needs to be simplified for Local State management. Memoized selectors are great but might be overkill for a Local State solution.

Memoized selectors are optional. You can provide a simple selector function like this: todos$: Observable<Todo[]> = this.select(state => state.todos);. See also in the docs: https://mini-rx.io/docs/select-feature-state

Ease of instantiating multiple instances of the same Store.

This has to be improved for sure. See proposal below.

Utilize the existing Extension?

Do you mean using the existing Extensions? By default FeatureStores use the same Extensions which are provided via configureStore or StoreModule.forRoot

(Will be really nice) if Redux Extension can be worked in, this is currently missing from other Local State solutions (RxState, ComponentStore)

Is possible already and will be possible with a reworked Feature Store.
With a Component Store solution this could be more difficult. Having many instances of Redux Dev Tools is not so user friendly and probably not very performant.

Proposal reworked Feature Store

Feature Store should support an additional configuration object which supports a multi property.

export class CounterFeatureStore extends FeatureStore<CounterState> {
  constructor() {
    super('counter', initialState, {multi: true})
  }
}

multi: true will tell the Feature Store to allow multiple Feature Stores with the same key. Normally the registration of an existing key is blocked here.
Then it is the job of MiniRx to provide unique keys internally.

The unique key could simply be: featureKey + a sequential number.
E.g. for a feature key "counter": "counter-1", "counter-2", "counter-3" etc

Sounds feasible :)

Then I thought about something which could be nice regarding the "pollution of global state" concern: Group the related feature states under the given feature key:

From the "polluted" global state:

To this:

products: {}
user: {}
todos: {}
counter: {
    counter-1: {}
    counter-2: {}
    counter-3: {}
    counter-4: {}
}

Like this even hundreds of "Component" feature states would not be annoying to see in the Redux Dev Tools. Also you could write easily selectors which are concerned with grouped feature states. E.g. the sum of all counter counts :)

PS: This is a discussion now :)

[spierala]

Created a POC of the idea with {multi: true} and automatic grouping of the component states under the feature key:
#70

It seems to work and I really like the automatic grouping.
It is just a lot of additional code :|

FYI @nartc

[spierala]

POCs:

1.) Grouped Feature Stores

Instantiate many Feature Stores with the same key. The corresponding feature states are automatically grouped in the global state object:

Usage:

export class CounterStateService extends FeatureStore<CounterState> {
    constructor() {
        super('counter', initialState, { multi: true });
    }
}

PR: #70
Conclusion: The grouping of features is cool, but it requires a lot of code, adds complexity to the MiniRx source code.

2.) Many instances with unique featureKey

Many instances of the same Feature Store by automatically appending a unique ID to the featureKey

Usage:

export class CounterStateService extends FeatureStore<CounterState> {
    constructor() {
        super('counter', initialState, { multi: true });
    }
}

PR: #103
Conclusion: Easy solution and gets the job done.

3.) InstantiationModes (SINGLE, MULTIPLE, MULTIPLE_DETACHED)

• InstantiationMode.MULTIPLE: Many Feature Store instances by automatically appending a unique ID to the featureKey
• InstantiationMode.MULTIPLE_DETACHED will create a fully local FeatureStore. But it loses all Redux Extensions.

Usage:

export class CounterStateService extends FeatureStore<CounterState> {
    constructor() {
        super('counter', initialState, { instantiation: InstantiationMode.MULTIPLE_DETACHED });
    }
}

PR: #105
Conclusion: The fully local "detached" Store is very performant if you have to create and destroy many Feature Stores.
The API with the modes sounds like a complex feature of FeatureStore.
The FeatureStore source code becomes more complex (some if checks are required to do the right thing depending on the mode).

4.) Simple Store

The dedicated class for local state management: SimpleStore. It exposes this methods and props: setState, select, get state

SimpleStore is almost the same like StateService from my blogpost "Simple yet powerful state management in Angular with RxJS"

SimpleStore is also extended by FeatureStore.

Usage:

export class CounterStateService extends SimpleStore<CounterState> {
    constructor() {
        super(initialState);
    }
}

PR: #107
Conclusion: SimpleStore could be the perfect start into Reactive State Management. FeatureStore source code does not become more complex.
SimpleStore is different enough to not get confused with FeatureStore.
Using SimpleStore is ideal if you have hundreds of instances of the same store service.

5.) Component Store

Full-fledged Component Store for local state management.
State is fully local and independent from the global state object.

Feature Store and Component Store share almost the same API with a few exceptions...

Component Store:

• no undo: It would require Redux and the UndoExtension
• the constructor does not support a config object like in FeatureStore ({multi: true})

Feature Store extends Component Store. Having Component Store does not add much to the bundle-size.

Usage:

export class CounterStore extends ComponentStore<CounterState> {
    constructor() {
        super();
    }
}

PR: #153
Conclusion: The Component Store itself is great for managing local component state which does not belong into the global state. If you temporarily need Redux DevTools, then it is easy to refactor the service from Component Store to Feature Store.

Support for the Store extensions in Component Store is not foreseen. I doubt that the extensions are very useful in local state management. NgRx Component Store has proven it :)

Will it be confusing to have Feature Store and Component Store in the same lib?

If Component Store makes it into MiniRx then the docs section about it should be very thin. For most APIs the Component Store docs should refer to the APIs documented for Feature Store. Just the use-case and the differences with Feature Store should be described.
A dedicated docs page which compares Store, FeatureStore, ComponentStore would be very helpful.

I believe it is possible to add Component Store without to much confusion.