Is there any risk in registering the ComponentStore at the root level?

[lichunbin814]

I saw the article, they put the componentStore at the root level as a global store, which is convenient for development and can work normally.

However, in the NgRx documentation, @NgRx/Store is still used as an example if you want to manage global state.

In my opinion, it seems correct to regard componentStore as a global service, but it conflicts with the design concept of ComponentStore. I don't know if there are any objections. Do you have any opinion?

[e-oz]

I’m using it in multiple apps, this approach successfully works even with standalone components.

[lichunbin814]

@Harpush Is my understanding the same as what you want to say?

ComponentStore does not have excessive encapsulation, so it still retains the flexibility of Angular DI, allowing us to manage global/local states as if we were using Angular Service.

[Harpush]

Indeed - but I wouldn't call it encapsulation... The main difference is the lack of actions as another decouple layer. It has its disadvantages too (at least theoretically) - no dev tools and time travel and all logic is in one place so it might get bloated.

[lichunbin814]

@Harpush Regarding the point you mentioned earlier, I still don't understand, the additional benefits of changing to ComponentStore:
When the app is becoming large you tend to see effects doing two updates due to separation of concerns which result in selectors running twice. In component store you have debounce.

--

Because Store's Selector can also use debounce, am I missing any details?
demo link

[lichunbin814]

@Harpush I think even if it is not CompeontStore, in many Angular Services, there will be a problem of single file becoming bloated.

My current solution: Try to keep the CompeontStore as a single responsibility, and use different CompeontStores to avoid the problem of file bloating.

Do you have any other suggestions?

[Harpush]

There are two differences:

1. Component store has custom debounce which doesn't use timers (rxjs asapScheduler).
2. Each selector is debounced not just the end one in the UI which means the whole selectors logic running twice can be prevented. Your example only prevents UI updates.

Maybe there is a way to apply those benefits to ngrx selectors too. Anyway component store selectors are not free of problems either. That's why we wrapped it with a custom wrapper.

[timdeschryver]

There's no risk into using component-store as a global store. Projects have different needs, and teams have their own preferences. @ngrx/component-store started as a store for components, but I see more projects using it also as a global store, or in combination with @ngrx/store.