4 ms·
Heh, it's amusing to see Redux Toolkit referenced here. I'm one of the two main RTK maintainers. My co-maintainer Lenz Weber is responsible for most of our TS
by acemarke 4y ago
Heh, it's amusing to see Redux Toolkit referenced here. I'm one of the two main RTK maintainers. My co-maintainer Lenz Weber is responsible for most of our TS type wizardry.
Agreed that writing TS types for libs can be a pain. I actually did a talk recently on "Lessons Learned Maintaining TS Libraries" [0], where I talked about some of the techniques we used, and some possible TS changes that would be helpful for us as maintainers.
As one recent example, TS made a change in a 4.8 pre-alpha that broke RTK's `createSlice` types. Lenz tried to come up with a fix, couldn't, and had to add a workaround to check what TS version is being used and specifically use an altered type. Since there _isn't_ a good way to know what TS version is being used, Lenz resorted to hacking together a new package that abuses the `typesVersions` property to define a different TS type for _every_ TS major+minor version combo, and then used that to decide what the RTK type should look like conditionally [1].
Another pain point is debugging type transformations. I reworked the Reselect types in 4.1.x to do a much better job of inferring the argument types for the final selector, based on the intersection of all the input selector arguments. This ended up as a monstrous type that does a types-level map + transpose + intersection [2]. It took me weeks to get this working right, and I frequently had to break it down into multiple small intermediate types to see how TS was processing each step.
I know that someone on Twitter was recently working on an alternate TS type-checker based on bytecode, and they said they had some kind of a working types-level debugger [3]. Having something like that officially, where I could see each step of how TS was transforming the types, would be _hugely_ valuable.
There's a couple folks like AndaristRake who are able to dig into the internals of the TS compiler itself to trace how it's interpreting the types. I definitely don't have that ability :)
[0] https://blog.isquaredsoftware.com/2022/05/presentations-ts-lib-maintenance/ https://blog.isquaredsoftware.com/2022/05/presentations-ts-l...
[1] https://github.com/reduxjs/redux-toolkit/pull/2547 https://github.com/reduxjs/redux-toolkit/pull/2547
[2] https://github.com/reduxjs/reselect/blob/v4.1.5/src/types.ts#L100-L148 https://github.com/reduxjs/reselect/blob/v4.1.5/src/types.ts...
[3] https://twitter.com/MarcJSchmidt/status/1539787500788613120 https://twitter.com/MarcJSchmidt/status/1539787500788613120
- helsontaveras18 4y agoI agree wholeheartedly that debugging types is very difficult. The best we have is hovering our mouse over the definition to see what type was created from the definition. Obviously not great. Also, debugging type differences with deeply nested objects (like what happens with graphql schemas) can be hugely painful. You need to copy the error message to its own file (since the errors can be huge) and debug what specific piece failed. I do feel the Typescript documentation is lacking and the only way to get better is to read open source projects to see how others have done it… which is only helpful when they’ve solved the exact problem you’re looking for. It’d be great to have a recipe book of common advanced typescript manipulations and how to compose them together.