You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This tracks a collection of in-code TODOs around here. Given the vega-lite API, hours, for example, could be typed as 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23, rather than number and be much more accurate, in terms of what is allowable. unfortunately, TS doesn't (yet) guard on less than/greater than, so this could be super cumbersome for API consumers (if they have a function which takes a number, after they've verified its range themselves, they'd need to cast to this union or a member of it). Obviously, then milliseconds is even longer.
Y'know, the more I write the more I realize with current limitations, this is a bad idea. This issue now tracks removing those TODOs from the code - until TS supports numeric range types and guards for them, specifying allowed numbers like this is just too cumbersome for API definers and consumers.
The text was updated successfully, but these errors were encountered:
This tracks a collection of in-code TODOs around here. Given the vega-lite API,
hours
, for example, could be typed as0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23
, rather thannumber
and be much more accurate, in terms of what is allowable. unfortunately, TS doesn't (yet) guard on less than/greater than, so this could be super cumbersome for API consumers (if they have a function which takes a number, after they've verified its range themselves, they'd need to cast to this union or a member of it). Obviously, then milliseconds is even longer.Y'know, the more I write the more I realize with current limitations, this is a bad idea. This issue now tracks removing those TODOs from the code - until TS supports numeric range types and guards for them, specifying allowed numbers like this is just too cumbersome for API definers and consumers.
The text was updated successfully, but these errors were encountered: