Great write up, thanks! I’m recently doing more and more typescript (coming from Java) and it’s sometimes confusing to get things right. Although I would also use a type it’s pretty handy for tests to use objects as types as you’ve shown.
The one thing that bugs me the most about the TS type system is the type erasure at runtime. I’ve had some bugs where while debugging I had a string in a variable of type int...
Hi Jan, Thank you for reading and commenting.
If your TS configuration is strict this should not be normally possible, unless of course, you're loading and parsing external data at runtime, which is very common.
For instance, you expect an object's id to be of type number but the JSON response from the server has it as a string.
One way to avoid this is to validate the server response at runtime. You can do this using something like ts.data.json or io-ts
Here's an article on dev.to showing how to use ts.data.json
In my case, it was an input element that was bound to the component in Angular. The types were correct, but the form returned strings...
Ah. I'm afraid I don't have enough experience with Angular. I suppose there are other reasons for that miss-type to happen: a library could be exporting the wrong types.
You can see it in the dom, that all form values are strings in the browser. There are no types. When you bin an integer to a form input, it will be a string eventually. When the user modifies it, the new string goes back to the model.
I really wish there were some statically typed version of TS that would be compiled to WebASM... maybe that would be a way to circumvent the JS quirks at runtime.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.