4 ms·
I tried to introduce `zod` (https://github.com/colinhacks/zod https://github.com/colinhacks/zod) to achieve the same thing within my current team. The idea was
by lhnz 5y ago
I tried to introduce `zod` (https://github.com/colinhacks/zod https://github.com/colinhacks/zod) to achieve the same thing within my current team.
The idea was that API responses that weren't reflected in the types would cause hard errors that we had to fix, and that we'd be forced to make sure that the mocks in our tests were up-to-date valid responses. Similarly to the article, I also made it so that in production they would log warnings, because I didn't want to expose us to the possibility that validation could take down the app.
However, TypeScript is new to my current team, and so nobody wanted the introduction of a validation API on top. It ended up being ~20 lines of code I couldn't get merged. Since TypeScript was new to the team syntax like `z.infer<typeof User>`, generic code and a whole new way to define types at runtime made them feel like it was too complicated.
Did others have similar problems introducing something like this?
- samhh 5y agoI struggled introducing fp-ts into my last team but io-ts was a much easier sell, as was fast-check. It's a lot easier to get buy-in when you can demonstrate that it will reduce bugs thereby improving the customer experience and reducing development burden. Something like io-ts or zod gives you confidence that the types in your application are correct, so you don't need to code or unit test defensively. This ties into the idea of pushing unsafety to the edges of your application. It can also be a quick way to discover that types don't align because of a backend API change; we had our io-ts decoding hooked up to Sentry. Likewise with fast-check I argued its utility in its introduction PR and made clear that it's an opt-in method of testing, and it caught a bug we hadn't spotted within a few weeks. You can't really argue with results like that. At a certain point though, if your team is unwilling or unable to recognise the limitations of TypeScript and therefore the necessity of constructs like `z.infer` or `t.TypeOf`, you might just have to accept it or move on. In my experience you can't move a team that far from where they'd already be heading without your presence. If you're surrounded by folks without experience in static typing, it's already a major win to have introduced TypeScript at all.
- capableweb 5y ago> and a whole new way to define types at runtime made them feel like it was too complicated How you made this happen? My impression was that TypeScript doesn't have runtime types and stopped looking at TypeScript after that as it basically makes TypeScript useless for myself and my team.
- samhh 5y agoLibraries like io-ts and zod take care of this for you. For io-ts for example you just need to define a type guard function that asserts "x is Y" and away you go, you've got a runtime codec; it knows how to "decode" data, and it knows what that represents to the type system at compile-time. You'll generally only need to use the built-in combinators though e.g. `t.type({ prop: t.string })` produces a codec for `{ prop: string }`, and you can get that type at compile-time without effectively rewriting it using `t.TypeOf<typeof myCodec>`.
- mnahkies 5y agoIt's a nice library, although I personally prefer explicitly writing the type out beside the codec. Otherwise you have to translate the codec to the type in your head when reading the code without an ide that can show you the type. This also gives you a "test" if you will that the codec is parsing the structure you think it is
- IshKebab 5y agoYes definitely. I have trouble just introducing Python type hints, despite the clear insanity of working with a large convoluted untyped codebase.