No more runtime errors from typescript
Update, November 2024:
- Using
Effect(which has swallowed fp-ts) for types functional patterns. We'll use it for remote data in the future. - Using
spectacle-tsfor upserting and accumulating (it's heavy on the typescript compiler) - For ADTs, I'm currently combining const records and tuples (usually not explicitly branded or discriminated) with
pattern-tsfor runtime introspection. - For strings, I found
string-tsto be quite handy
It's an uphill battle:
- Typescript was not made for type-safety. It's unsound and incomplete.
- The typescript compiler is extremely slow if it has to infer a type. But explicit annotations lead to new errors and may be far too large to write out.
- The typescript syntax is a mess. Type definitions are unreadable.
- Mastering typescript takes many years because it has arcane logic and excessive syntactical quirks.
Writing code in typescript means to decide on a case-by-case basis whether to opt in to the typesystem, given its high performance and maintainability costs. I'm currently approximately 30x slower in typescript than in elm or js.
We've had several errors that were almost impossible to locate. It turned out they came from uncaught errors somewhere in the graphQL pipeline.
Another class of errors comes from typescript's unsound (unsafe) default typesystem.
I've been using fp-ts, the latest successor of the ramda/fantasyland lineage, with much success.
fp-ts-std promises typesafe programs without the need for compile-to-ts languages such as elm.
https://github.com/samhh/fp-ts-std?tab=readme-ov-file
It makes fp-ts more accessible and readable (something ramda and elm definitely have over haskell) by adding nice utility functions.
In a similar vein, spectacles turn objects into typesafe ADTs with a beautiful accessor syntax.
https://dev.to/anthonyjoeseph/simple-immutable-data-w-spectacles-4nb5
To generate ADTs, I have tried to use the JS builtins with no success. There is a library similar to elm-any-type which I shall use:
https://github.com/sledorze/morphic-ts
The above libraries will turn all all runtime (i.e. build-time) errors of our typescript modules into compile-time errors. The only error surface that remains is the further-up stack.
To catch any future graphql or network error as early as possible, and provide detailed compile-time messages, we can use sth like remote-data-ts or any alternative listed in the 'fp-ts ecosystem' page.