feat(signals): provide `@ngxs/signals` package with signals utilities #2141

arturovt · 2024-03-23T20:34:40Z

No description provided.

nx-cloud · 2024-03-23T20:36:20Z

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 0c0c064. 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 5 targets

Sent with 💌 from NxCloud.

bundlemon · 2024-03-23T20:40:35Z

BundleMon (Integration Projects)

Unchanged files (2)

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

No change in files bundle size

Final result: ✅

View report in BundleMon website ➡️

Current branch size history | Target branch size history

rhutchison · 2024-03-23T23:24:31Z

There are 3 utilities: select, produceActions, and produceSelectors

select:

@Component({...})
export class SomeComponent {
  user = select(AuthQueries.getUser);
}

produceActions/produceSelectors:

Allow users to quickly adapt ngxs store to @ngrx/signals (signalStore). We can provide the following recipes in the documentation:

export function withSelectors<T extends SelectorMap>(selectors: T) {
  return signalStoreFeature(withComputed(() => produceSelectors(selectors)));
}

export function withActions<T extends ActionMap>(actions: T) {
  return signalStoreFeature(withMethods(() => produceActions(actions)));
}

Usage:

export const UserState = signalStore(
  withSelectors({
    user: AuthQueries.getUser
  }),
  withActions({
    login: AuthActions.login,
    logout: AuthActions.logout
  })
)

rhutchison · 2024-03-24T00:04:45Z

packages/signals/src/types.ts

+// There's no reason to call the following function with an empty object as
+// `produceActions({})` or `produceSelectors({})`. We should prevent invalid
+// or incorrect use cases.
+export type RequireAtLeastOneProperty<T> = keyof T extends never ? never : T;


if we're using type-fest, you can use NonEmptyObject

rhutchison · 2024-03-24T00:05:09Z

packages/signals/src/produce-actions.ts

+import { ActionDef, Store } from '@ngxs/store';
+import { Observable } from 'rxjs';
+
+import { RequireAtLeastOneProperty } from './types';


import type { NonEmptyObject } from 'type-fest';

rhutchison · 2024-03-24T00:05:29Z

packages/signals/src/produce-selectors.ts

+import { Signal, inject } from '@angular/core';
+import { Store, TypedSelector, ɵSelectorReturnType } from '@ngxs/store';
+
+import { RequireAtLeastOneProperty } from './types';


import type { NonEmptyObject } from 'type-fest';

markwhitfeld

I think that this is a really great, simple utility. Nicely done!
Just needs docs ❤️

packages/signals/tests/produce-selectors.spec.ts

packages/signals/types/tests/produce-actions.lint.ts

arturovt · 2024-03-24T12:14:55Z

questions:

do we keep select name for the utility function?
I added docs and placed it under docs/concepts/select/signals.md, I ain't sure if it should be under concepts/select. Any ideas?

packages/signals/src/produce-selectors.ts

markwhitfeld · 2024-03-24T18:39:28Z

questions:

do we keep select name for the utility function?

I added docs and placed it under docs/concepts/select/signals.md, I ain't sure if it should be under concepts/select. Any ideas?

I think we can leave this utility function out for the first release of this. WDYT?
There needs to be a final discussion on naming.
I think that would be the correct place in the docs.

rhutchison · 2024-03-24T19:29:56Z

questions:

do we keep select name for the utility function?

I added docs and placed it under docs/concepts/select/signals.md, I ain't sure if it should be under concepts/select. Any ideas?

I think we can leave this utility function out for the first release of this. WDYT? There needs to be a final discussion on naming. I think that would be the correct place in the docs.

I think the utility function is super helpful, is inline with direction of replacing decorators with functions, and times nicely with the latest signal queries:

@ContentChild => contentChild and @ContentChildren => contentChildren
@ViewChild => viewChild and @ViewChildren => viewChildren

If we're looking to deprecate @Select it makes perfect sense to introduce select.

markwhitfeld · 2024-03-25T12:29:58Z

questions:

do we keep select name for the utility function?

I added docs and placed it under docs/concepts/select/signals.md, I ain't sure if it should be under concepts/select. Any ideas?

I think we can leave this utility function out for the first release of this. WDYT? There needs to be a final discussion on naming. I think that would be the correct place in the docs.

I think the utility function is super helpful, is inline with direction of replacing decorators with functions, and times nicely with the latest signal queries:

@ContentChild => contentChild and @ContentChildren => contentChildren @ViewChild => viewChild and @ViewChildren => viewChildren

If we're looking to deprecate @Select it makes perfect sense to introduce select.

This makes me so happy!!! There has been a lot of discussions about the naming of this utility, and I have always wanted to have it as select, advocating a signals first approach.
The hesitation has been that it doesn't match the method names of the Store methods.
Taking Angular's lead on this is a great motivation for this naming.
@arturovt I'm definitely happy for this utility to be called select.
@dmitry-stepanenko What do you think? You had raised the concern about alignment in the discussions.

markwhitfeld · 2024-03-25T12:36:49Z

Just a subtle naming discussion point...
Do you think produceSelectors is the ideal name? It produces something from selectors. It produces "select"s. What do you think of the name produceSelects?
I'm not pushing for either, just looking for thoughts on it...
cc @arturovt @rhutchison @dmitry-stepanenko @Carniatto @joaqcid @profanis

markwhitfeld · 2024-03-25T12:39:51Z

And, if we have a select utility to produce a single output as well as produceSelectors to produce a mapped output for selectors, do you think we should also have a dispatch utility for producing a single dispatch function from an action?
cc @arturovt @rhutchison @dmitry-stepanenko @Carniatto @joaqcid @profanis

markwhitfeld · 2024-03-25T12:41:09Z

Given my last 2 questions, it leads me to ask:
What do you think about produceDispatchers as an alternative to produceActions?
cc @arturovt @rhutchison @dmitry-stepanenko @Carniatto @joaqcid @profanis

rhutchison · 2024-03-25T13:30:59Z

And, if we have a select utility to produce a single output as well as produceSelectors to produce a mapped output for selectors, do you think we should also have a dispatch utility for producing a single dispatch function from an action? cc @arturovt @rhutchison @dmitry-stepanenko @Carniatto @joaqcid @profanis

I did start to discuss with Artur. asDispatch or dispatch?

export function asDispatch<TArgs extends any[]>(
  actionType: ActionDef<TArgs>
) {
  return (...args: TArgs) => inject(Store).dispatch(new actionType(...args));
}

@Component({...})
export class SomeComponent {
  user = select(AuthQueries.getUser);

  login = asDispatch(AuthActions.login);
}

rhutchison · 2024-03-25T13:38:57Z

Just a subtle naming discussion point... Do you think produceSelectors is the ideal name? It produces something from selectors. It produces "select"s. What do you think of the name produceSelects? I'm not pushing for either, just looking for thoughts on it... cc @arturovt @rhutchison @dmitry-stepanenko @Carniatto @joaqcid @profanis

Given my last 2 questions, it leads me to ask:
What do you think about produceDispatchers as an alternative to produceActions?
cc @arturovt @rhutchison @dmitry-stepanenko @Carniatto @joaqcid @profanis

Maybe toSelectMap and toDispatchMap. Would like to hear other's feedback before we merge.

arturovt · 2024-03-25T15:22:34Z

Given my last 2 questions, it leads me to ask: What do you think about produceDispatchers as an alternative to produceActions? cc @arturovt @rhutchison @dmitry-stepanenko @Carniatto @joaqcid @profanis

Since the function is generating dispatch functions rather than actions themselves a more appropriate name could be produceDispatchers or createDispatchers, or smth else.

markwhitfeld · 2024-03-25T18:29:50Z

I like select and dispatch.
Although, including the dispatch here which returns an Observable seems a bit odd for a @ngxs/signals package.
Would it rather belong in the core package?

If so, then what would that mean for the produceDispatchers (or whatever we call it). Does the same logic apply? Would that also shift to the main package?

rhutchison · 2024-03-25T18:46:44Z

I like select and dispatch. Although, including the dispatch here which returns an Observable seems a bit odd for a @ngxs/signals package. Would it rather belong in the core package?

If so, then what would that mean for the produceDispatchers (or whatever we call it). Does the same logic apply? Would that also shift to the main package?

dispatch should go in core, I think produceSomething should stay here,

I like select and dispatch. Although, including the dispatch here which returns an Observable seems a bit odd for a @ngxs/signals package. Would it rather belong in the core package?

If so, then what would that mean for the produceDispatchers (or whatever we call it). Does the same logic apply? Would that also shift to the main package?

dispatch should definitely go in core, not sure about producer, but makes sense to question it

markwhitfeld · 2024-03-25T18:49:50Z

In terms of naming, we have a few options:

produceSelects
makeSelectMap
createSelectMap
produceSelectMap
toSelectMap

rhutchison · 2024-03-25T18:51:25Z

In terms of naming, we have a few options:

produceSelects

makeSelectMap

createSelectMap

produceSelectMap

asSelectMap

I suggested toSelectMap and toDispatchMap, bc of the rxjs-interop naming convention

markwhitfeld · 2024-03-25T18:52:55Z

In terms of naming, we have a few options:

produceSelects

makeSelectMap

createSelectMap

produceSelectMap

asSelectMap

I think I prefer createSelectMap because it has similar naming to our other selector utilities (also starting with create...), which potentially makes it more discoverable too.

arturovt · 2024-03-25T20:23:55Z

i'm fine with it too. so do we go with createSelectMap and createDispatchMap?

Carniatto · 2024-03-26T06:21:52Z

Sorry I only saw the discussion now. Definitely the content of this PR is awesome, thanks Arthur for all the work.

I was wondering if we should align with the terminology we already have for the selector utilities. See https://www.ngxs.io/advanced/selector-utils

I'm okay with the proposed naming also, I'm just wondering if we want to create more context for similar functionality

dmitry-stepanenko · 2024-03-26T07:47:49Z

Awesome PR! I think I like the createSelectMap and createDispatchMap naming option.

@dmitry-stepanenko What do you think? You had raised the concern about alignment in the discussions.

@markwhitfeld back in the RFC we discussed that it will be selectSignal. At the same time I'm looking an it now and I think the select name aligns really well with all the new utilities angular has recently presented.

profanis · 2024-03-26T08:19:36Z

Great work @arturovt!
My delayed input is that I like the select utility.
As for the dispatchers/actions, I agree with Artur that the function is generating Dispatchers and as such, I am more towards the CreateDispatchers.
I am afraid that the name CreateActions or ProduceActions is not that clear in terms of its underlying implementation.

Having said that, I would vote for the naming convention Create*

markwhitfeld

Great! So it looks like we have consensus on select, createSelectMap and createDispatchMap.
We are just missing tests for createDispatchMap in this PR.
The one other thing to be settled is the inclusion of the dispatch utility, and if both the dispatch utilities should exist in the @ngxs/signals package, or in the @ngxs/store package.
Thoughts? @rhutchison @Carniatto @arturovt @joaqcid @dmitry-stepanenko @profanis

rhutchison · 2024-03-26T18:46:49Z

Great! So it looks like we have consensus on select, createSelectMap and createDispatchMap. We are just missing tests for createDispatchMap in this PR. The one other thing to be settled is the inclusion of the dispatch utility, and if both the dispatch utilities should exist in the @ngxs/signals package, or in the @ngxs/store package. Thoughts? @rhutchison @Carniatto @arturovt @joaqcid @dmitry-stepanenko @profanis

dispatch utility in separate PR #2143

I am not sure where createDispatchMap should land, but I'm leaning to say keep where it is bc of the use-case with ngrx/signals (signalStore)

arturovt · 2024-03-26T20:00:57Z

We can continue the discussion in a separate pull request related to the dispatch functionality. However, considering the dispatch map, it might seem odd to have different imports since these functions aim to provide the same utility value.

rhutchison · 2024-03-26T23:00:13Z

I believe it's ready to merge

arturovt · 2024-03-27T14:56:32Z

Merged. Can address any issues in subsequent PRs.

markwhitfeld · 2024-03-27T15:23:17Z

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.

arturovt force-pushed the feat/select-for-signal branch from 962a2ef to 49c8baf Compare March 23, 2024 22:47

arturovt changed the title ~~feat(store): expose function to select signal~~ feat(signals): provide @ngxs/signals package with signals utilities Mar 23, 2024

arturovt force-pushed the feat/select-for-signal branch from 49c8baf to 2308a9e Compare March 24, 2024 00:00

rhutchison reviewed Mar 24, 2024

View reviewed changes

markwhitfeld reviewed Mar 24, 2024

View reviewed changes

packages/signals/tests/produce-selectors.spec.ts Outdated Show resolved Hide resolved

packages/signals/types/tests/produce-actions.lint.ts Outdated Show resolved Hide resolved

arturovt force-pushed the feat/select-for-signal branch from 2308a9e to d111778 Compare March 24, 2024 11:10

markwhitfeld reviewed Mar 24, 2024

View reviewed changes

packages/signals/src/produce-selectors.ts Outdated Show resolved Hide resolved

arturovt added 4 commits March 25, 2024 07:31

feat(signals): provide @ngxs/signals package with signals utilities

398f382

fix: produced keys should be readonly (typely and technically)

f2912a6

docs: add signals docs

be58fe2

fix: do not expose select

5c7f03e

arturovt force-pushed the feat/select-for-signal branch from 995e18f to 5c7f03e Compare March 25, 2024 05:33

arturovt marked this pull request as ready for review March 25, 2024 05:33

arturovt requested review from kuncevic, Carniatto, poloagustin, joaqcid and splincode as code owners March 25, 2024 05:33

fix: expose select as agreed

0b81711

ngxs deleted a comment from codeclimate bot Mar 25, 2024

arturovt added 2 commits March 26, 2024 00:15

fix: rename to createSelectMap and createDispatchMap

a492a7d

ci: update naming

f007076

ngxs deleted a comment from codeclimate bot Mar 25, 2024

markwhitfeld reviewed Mar 26, 2024

View reviewed changes

fix: add missing test

0c0c064

ngxs deleted a comment from codeclimate bot Mar 26, 2024

rhutchison approved these changes Mar 27, 2024

View reviewed changes

arturovt merged commit b4d0487 into master Mar 27, 2024
12 of 13 checks passed

arturovt deleted the feat/select-for-signal branch March 27, 2024 14:55

markwhitfeld added this to the v.18.0.0 milestone Jun 24, 2024

markwhitfeld added the released label Jun 24, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(signals): provide `@ngxs/signals` package with signals utilities #2141

feat(signals): provide `@ngxs/signals` package with signals utilities #2141

arturovt commented Mar 23, 2024

nx-cloud bot commented Mar 23, 2024 •

edited

Loading

bundlemon bot commented Mar 23, 2024 •

edited

Loading

rhutchison commented Mar 23, 2024 •

edited

Loading

rhutchison Mar 24, 2024

rhutchison Mar 24, 2024

rhutchison Mar 24, 2024

markwhitfeld left a comment

arturovt commented Mar 24, 2024

markwhitfeld commented Mar 24, 2024 •

edited

Loading

rhutchison commented Mar 24, 2024 •

edited

Loading

markwhitfeld commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024

rhutchison commented Mar 25, 2024

rhutchison commented Mar 25, 2024

arturovt commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024

rhutchison commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024 •

edited

Loading

rhutchison commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024

arturovt commented Mar 25, 2024

Carniatto commented Mar 26, 2024 •

edited

Loading

dmitry-stepanenko commented Mar 26, 2024 •

edited

Loading

profanis commented Mar 26, 2024

markwhitfeld left a comment

rhutchison commented Mar 26, 2024

arturovt commented Mar 26, 2024

rhutchison commented Mar 26, 2024

arturovt commented Mar 27, 2024

markwhitfeld commented Mar 27, 2024

feat(signals): provide @ngxs/signals package with signals utilities #2141

feat(signals): provide @ngxs/signals package with signals utilities #2141

Conversation

arturovt commented Mar 23, 2024

nx-cloud bot commented Mar 23, 2024 • edited Loading

☁️ Nx Cloud Report

bundlemon bot commented Mar 23, 2024 • edited Loading

BundleMon (Integration Projects)

rhutchison commented Mar 23, 2024 • edited Loading

rhutchison Mar 24, 2024

Choose a reason for hiding this comment

rhutchison Mar 24, 2024

Choose a reason for hiding this comment

rhutchison Mar 24, 2024

Choose a reason for hiding this comment

markwhitfeld left a comment

Choose a reason for hiding this comment

arturovt commented Mar 24, 2024

markwhitfeld commented Mar 24, 2024 • edited Loading

rhutchison commented Mar 24, 2024 • edited Loading

markwhitfeld commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024

rhutchison commented Mar 25, 2024

rhutchison commented Mar 25, 2024

arturovt commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024

rhutchison commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024 • edited Loading

rhutchison commented Mar 25, 2024

markwhitfeld commented Mar 25, 2024

arturovt commented Mar 25, 2024

Carniatto commented Mar 26, 2024 • edited Loading

dmitry-stepanenko commented Mar 26, 2024 • edited Loading

profanis commented Mar 26, 2024

markwhitfeld left a comment

Choose a reason for hiding this comment

rhutchison commented Mar 26, 2024

arturovt commented Mar 26, 2024

rhutchison commented Mar 26, 2024

arturovt commented Mar 27, 2024

markwhitfeld commented Mar 27, 2024

feat(signals): provide `@ngxs/signals` package with signals utilities #2141

feat(signals): provide `@ngxs/signals` package with signals utilities #2141

nx-cloud bot commented Mar 23, 2024 •

edited

Loading

bundlemon bot commented Mar 23, 2024 •

edited

Loading

rhutchison commented Mar 23, 2024 •

edited

Loading

markwhitfeld commented Mar 24, 2024 •

edited

Loading

rhutchison commented Mar 24, 2024 •

edited

Loading

markwhitfeld commented Mar 25, 2024 •

edited

Loading

Carniatto commented Mar 26, 2024 •

edited

Loading

dmitry-stepanenko commented Mar 26, 2024 •

edited

Loading