🚀[FEATURE]: Typed @Selector Decorator

[ConnorUllmann]

Relevant Package

This feature request is for @ngxs/store

Description

The Selector decorator is able to decorate functions whose arguments do not match the selectors/states passed into the decorator.

Describe the problem you are trying to solve

When the selectors passed into the Selector decorator do not match the arguments of the function being decorated, runtime errors can occur due to mistyping. One simple example of this is when a selector returns a type like string | null and another selector consumes it under an argument typed as just string, resulting in the latter selector failing to handle the null case correctly. More extreme failures cases are situations where selector arguments are mistakenly swapped, forgotten, or changed to return a new type entirely--mistakes which can be hard to notice until runtime without strong typing.

Describe the solution you'd like

Once NGXS is upgraded to Typescript >=4.0, the new variadic tuple types can be used to add strong typing to the Selector decorator.

Here is a stackblitz which defines a new Selector decorator (which is just a passthrough to the NGXS Selector decorator) that adds this typing. The my.selectors.typed.ts file is a copy of my.selectors.ts but with its Selector import changed to point at the new selector--you should see several selectors with errors in my.selectors.typed.ts that do not show up as errors in the other. See selector-typed.ts for the new decorator.

Before:

After:

Notes

• The Select decorator may be able to receive the same treatment (can't decorate a property whose type does not match the return type of the given selector).
• Adding the ability to get the state model given the state would be great--in the current stackblitz, if a state is added to the decorator's selector list, the corresponding parameter in the decorated function's arguments is typed as any instead of the corresponding state model.
• selector-typed-state-injection.ts details an alternative decorator which works with the "injectContainerState" selector option but weakens the typing and does not protect against writing selectors outside of state files that assume an injected state parameter.

[markwhitfeld]

Hi @ConnorUllmann and welcome to your project!!! I have some good news. VERY solid typing is coming to a createSelector near you in the next version of NGXS (dropping in the next week or so)!

With respect to the typing of @Select and @Selector, we have tried it before (albeit a few versions of TS ago) and actually rolled it out, only to find that it breaks if the thing being decorated is not public. So we had to roll it back 😢 .
I have not had a look at your solution yet, but will it survive this test?

[markwhitfeld]

Oh wow! I think you may be on to something there!!!
I wonder if you would be able to get this working without vardic types, and just the constructs that TS 3.2 offers?
Or if not, what is the minimum typescript version for this?

[ConnorUllmann]

I was able to get this running against Typescript 3.2.4 with these two changes:

1. In selector-typed.ts, replace this:
   return SelectorNGXS(selectors) as SelectorTypedPropertyDescriptor<T>;
   with this:
   return SelectorNGXS(selectors) as unknown as SelectorTypedPropertyDescriptor<T>;
2. In selector-typed-state-injection.ts, replace this:
   N['length'] extends T['length'] ? DescriptorArg<T> : [any, ...DescriptorArg<T>]
   with this:
   N['length'] extends T['length'] ? DescriptorArg<T> : DescriptorArg<[StateClass, ...(StateClass | Fn)[]]>

The first change doesn't appear to have any change in functionality, but the second will cause the typing not to catch quite a few situations on any decorator which includes an injected state parameter (mostly around enforcing count of parameters). I toyed around with a few changes without much luck, so I believe the variadic tuple types in TS 4.0 are relevant for using the tuple T as a rest parameter here.

I also tried making the selectors private and didn't see any issues crop up--let me know if I'm not properly reflecting the problems you had before. app.component.ts uses the NGXS decorator and app.typed.component.ts uses the new decorator, and I separately tested in app.typed.fixed.component.ts that if I fix all the typing issues the new decorator errors with that the app runs correctly.

[markwhitfeld]

@ConnorUllmann Did you have any luck in further improving the typings using the examples I sent you?

[ConnorUllmann]

@markwhitfeld sorry for the delay; took me some time getting it together but I think I have a solution which is compatible with TS 3.2.4

I haven't been able to get it working locally against the NGXS repo as an "opt-in" typing, but I was able to get around using variadic tuple types by using function overloads like the ones for createSelector that you mentioned.

Here is a stackblitz for the simpler version of the typings which supports any number of arguments but does not support state injection.

Here is another stackblitz for the version of the selector which is compatible with state injection and requires the function overloads. I only added overloads for 0-3 arguments but hopefully it's clear how it could be extended to allow more.

I added the new NGXS typings you sent me in a separate new-selector-types.ts file (e.g. SelectorReturnType, SelectorDef, etc). I tried to find these types locally in my fork of the NGXS repo, but I didn't see them on master and as a result couldn't put together a pull request. Is there a place I should be able to find those?

[markwhitfeld]

Thank you @ConnorUllmann!
Those types do not exist in the codebase yet, but will be coming soon when I add the improved createSelector.
I will have a look at how we could make this opt-in, and potentially force the use of injectContainerTypes: false ;-)