Skip to content

Let the type of sources in watch always be a tupel #2655

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

Closed
JensDll opened this issue Nov 21, 2020 · 3 comments
Closed

Let the type of sources in watch always be a tupel #2655

JensDll opened this issue Nov 21, 2020 · 3 comments

Comments

@JensDll
Copy link
Contributor

JensDll commented Nov 21, 2020

What problem does this feature solve?

When watching multiple sources you don't have to do explicit const assertion on the input array.

What does the proposed API look like?

Since TypeScript 4.0 and the ability to use generics in the tupel spread syntax, the sources parameter in watch can always be made a tupel type. Basically change the type of sources from T to readonly [...T]:

function watch<
  T extends Readonly<Array<WatchSource<unknown> | object>>,
  Immediate extends Readonly<boolean> = false
>(
  sources: T,
  cb: WatchCallback<MapSources<T, false>, MapSources<T, Immediate>>,
  options?: WatchOptions<Immediate>
): WatchStopHandle

// ----->

function watch<
  T extends Readonly<Array<WatchSource<unknown> | object>>,
  Immediate extends Readonly<boolean> = false
>(
  sources: readonly [...T],
  cb: WatchCallback<MapSources<T, false>, MapSources<T, Immediate>>,
  options?: WatchOptions<Immediate>
): WatchStopHandle
@posva
Copy link
Member

posva commented Nov 22, 2020

Wouldn't this be a breaking change for users with TypeScript < 4? It would be perfect if it could be introduced without breaking usage for TS 3.x

@JensDll
Copy link
Contributor Author

JensDll commented Nov 22, 2020

Yes, this would not work in a version smaller 4.0. In previous versions, there is nothing similar that I know of at least. However, there are discussions like this one that make me believe, that there is not really a straightforward solution. I guess this can be kept in mind for the future.

@JensDll
Copy link
Contributor Author

JensDll commented Dec 4, 2020

closing this because of #2425

@JensDll JensDll closed this as completed Dec 4, 2020
@github-actions github-actions bot locked and limited conversation to collaborators Oct 30, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants