-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return type of selectQueryParam is incorrect #4286
Comments
Hi, it seems like you're right! |
I can. I don't think it will take that long to fix but I probably won't be able to work on it till this weekend. |
@Tezra we're currently preparing our v18 release, do you think you can create a PR for this? |
@timdeschryver The codespace container is failing to build for me (error below). So seems I can't create a PR at the moment or run the tests. As far as I can tell, the only change needed for the PR is in @ngrx/router-store/src/models.d.ts; line 7 (Plus updating any typing elsewhere that clashes with this.)
|
Which @ngrx/* package(s) are the source of the bug?
router-store
Minimal reproduction of the bug/regression with instructions
Sorry I can't provide a minimal example, but for some reason my StackBlitz example always returns undefined (https://stackblitz.com/edit/angular-63sasz?file=src%2Fapp%2Fmy-counter%2Fmy-counter.component.ts, incase you can fix the configuration). This bug is a discrepancy between the static and runtime typing though. (example snippet below).
The selector from selectQueryParam says the return type is
string
, however the actual type at runtime isstring[] | string | undefined
, based on if the query param appears 0 (undefined), 1 (string) or more (string[]) times.Expected behavior
For the runtime type to match the Typescript type.
Versions of NgRx, Angular, Node, affected browser(s) and operating system(s)
As far as I can tell, all.
Other information
Fixing this would be a breaking change, but the incorrect type is an issue for strict projects trying to take advantage of the string[] behavior, and if the url is modified in an unexpected way, may crash pages that think they are type safe.
I would be willing to submit a PR to fix this issue
The text was updated successfully, but these errors were encountered: