Re:Migrating 300k LOC from Flow to TypeScript
by cryptica on Saturday June 29, 2019 @01:42PM
(#20313783)
Protobufs is an antipattern. You can't expect external systems to agree with your system's type definitions. It just gives other people extra work when integrating with your system.
JSON is better because it allows external services to interpret the data in their own way regardless of their type system.
Re:Migrating 300k LOC from Flow to TypeScript
by Sahhaese on Thursday June 20, 2019 @10:19AM
(#20233163)
Typescript only checks all that at compile time though. The complaint here is that even a typed json.Parse<T> :(json:string)=>T will not actually give any type checking when you pass it a string containing any schema.
Re:Migrating 300k LOC from Flow to TypeScript
by WorldMaker on Thursday June 20, 2019 @01:53PM
(#20235381)
When you type json.Parse<T> you are taking on the responsibility that what is returned is actually T. If you want the type checker's help that you are sure it might not be T, then ask for it: json.Parse<unknown> or json.Parse<Partial<T>> is maybe more accurate, and would force you to write runtime checks. Partial<T> in particular is a great helper type that is often exactly what a lot of want in a json.Parse situation: gives you the field autocomplete you want, but reminds you that they may be undefined.
Re:Migrating 300k LOC from Flow to TypeScript
by wereHamster on Thursday June 20, 2019 @11:22AM
(#20233796)
A sound type system shouldn't allow you to write such a parser function without either you lying in its implementation or having to use unsafe code.
In a year or two, once everyone has switched to use `unknown` instead of `any` in functions which at runtime return… uhm… unknown values, we'll all be much safer. Because we'll be forced to use proper parsers and validators.
Typescript makes sure that all your code agrees with the protocol definition you have chosen. That alone is immensely valuable.