TypeScript’s quirks: How inconsistencies make the language more complex

Re:TypeScript’s quirks: How inconsistencies make the languag... by shhsshs on Friday January 31, 2020 @11:53PM (#22208767)

Personally I dislike the fact that io-ts requires taking a pure functional programming approach to this validation. For most cases I just want to throw an error if something doesn't match up. My main use case for this is validating that my UI and backend API have the same ideas about the shape of the data, which will either always work or always fail. All errors should be caught during development and testing, so the "either" case will never realistically be hit in production.

Because of this I prefer runtypes [1], because it's much more simple to get my desired behavior. My only gripe is that errors aren't all that descriptive.

I guess I could write a function to pipe/fold into the type, throwing a descriptive error if something fails, but I like the simplicity of runtypes.

Edit: I just discovered io-ts ErrorReporter [2]. That's way better than my solution, and I'm considering switching now!

1: https://github.com/pelotom/runtypes

2: https://github.com/gcanti/io-ts/blob/master/src/ThrowReporte...

[ Parent | on HN ]

Re:TypeScript’s quirks: How inconsistencies make the languag... by Shacklz on Sunday February 02, 2020 @09:00AM (#22216924)

We wrote a bunch of utility methods around io-ts at work with custom error reporting/handling, otherwise it can indeed feel a bit too fp-/boilerplate-heavy for your every day frontend development, especially in combination with other stuff such as rxjs/redux.

But once you have those set up, it's an easy breeze, and the benefits are enormous. Our helper-method with the hopefully self-explanatory name "validateOrThrow<T>(t:TypeGuardForT)" is essentially called at every point where there is some form of incoming external data, and the amount of debugging-headaches that have simply disappeared because of this is mind-blowing.

[ Parent | on HN ]