feat(store): add dispatch utility

[arturovt]

No description provided.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 1c7a57e. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 4 targets

• nx run-many --target=test --all --configuration=ci --maxWorkers=4
• nx run-many --target=lint --all
• nx lint-types store
• nx run-many --target=build --all

---

Sent with 💌 from NxCloud.

[bundlemon]

BundleMon (Integration Projects)

Unchanged files (2)

Status	Path	Size	Limits
✅	Main bundles(Gzip) hello-world-ng17/dist-integration/main.(hash) .js	68.48KB	+1%
✅	Main bundles(Gzip) hello-world-ng16/dist-integration/main.(hash) .js	67.03KB	+1%

Total files change -9B -0.01%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history | Target branch size history

[markwhitfeld]

I think we should include the dispatch utility in the @ngxs/signals package so that it is grouped together with the other utilities that follow the "signals style".
It is also easier to move something into the main package at a later stage, than it out of it.
What do you think?

[arturovt]

I thought similarly, believing it should be a part of the signals package, mainly because those utilities are quite similar.

[profanis]

I think we should include the dispatch utility in the @ngxs/signals package so that it is grouped together with the other utilities that follow the "signals style". It is also easier to move something into the main package at a later stage, than it out of it. What do you think?

Although it makes sense to have select and dispatch under the same package, I feel that the dispatch should be part of the core.
I am thinking of a case where a consumer is not yet about to move to signals but would love to use the dispatch utility function. Having an import like this import { dispatch } from @ngxs/signals could confuse.

[markwhitfeld]

I think we should include the dispatch utility in the @ngxs/signals package so that it is grouped together with the other utilities that follow the "signals style". It is also easier to move something into the main package at a later stage, than it out of it. What do you think?

Although it makes sense to have select and dispatch under the same package, I feel that the dispatch should be part of the core.
I am thinking of a case where a consumer is not yet about to move to signals but would love to use the dispatch utility function. Having an import like this import { dispatch } from @ngxs/signals could confuse.

Good point @profanis. What would you propose as the ideal split of APIs to packages here?

[rhutchison]

you could move select to @ngxs/store and keep the @ngxs/signals library as the interop for @ngrx/signals.

select and dispatch can be used without needing @ngxs/signals. You only really need @ngxs/signals if you want to use signalStore.

[profanis]

you could move select to @ngxs/store and keep the @ngxs/signals library as the interop for @ngrx/signals.

select and dispatch can be used without needing @ngxs/signals. You only really need @ngxs/signals if you want to use signalStore.

I like that!

[markwhitfeld]

I see these utilities as generally useful, and not specific to ngrx signal store though.
Keeping them all together in the signals package advocates for a specific style of declaration, to which they are all consistent.

[rhutchison]

I see these utilities as generally useful, and not specific to ngrx signal store though. Keeping them all together in the signals package advocates for a specific style of declaration, to which they are all consistent.

What is your recommendation?

[arturovt]

Merged. Can revert if we agree to do this.

[markwhitfeld]

I'm happy for all of this to move to the @ngxs/store package.
I think it makes more sense to all be core.