It's one of those things that's great for a solo dev. But I'd cringe having to come into a codebase like this. And then have to learn all the pitfalls, and onboard folks and have them learn the pitfalls. . .
I also am a bit weirded out by the Effect.Effect<unknown, HttpClientError>. . . What is unknown?
`unknown` is a standard type in TypeScript for "it could be anything and you don't know what it is, so you need to introspect it and assert a type if you want to use it". (As opposed to `any`, which is "it could be anything but you don't have to introspect it to use it, you're just opting out of the type system".)
This is not "normie" TypeScript but I wouldn't characterize it as particularly scary.
It isn’t typed since the response from the http call can be anything. It could be a Todo, a generic success wrapper that contains a Todo, or maybe it was recently changed to return a Checklist instead of a Todo. Since the response can be anything we have two options, either make the type be any or unknown. any is an escape hatch typescript provides that allows anything, so if you access a field that doesn’t exists on the response you’ll get a runtime exception. With unknown typescript doesn’t let you do anything with the value until you figure out the type. In this example the next step would be to try to decode that unknown into a Todo, or fail with some error[1]. This guarantees that the object your code expects is actually what you are expecting both at compile time and runtime.
Given the goal of effect is to provide type safe tracking of a codebase; having an any breaks that assumption, while unknown forces you to add validation to keep it type safe.
I also am a bit weirded out by the Effect.Effect<unknown, HttpClientError>. . . What is unknown?