Nice! I found I have met the issue "what's the constraints of each property of the TS type?" Sometimes, the type have different state, like your said, the sum type is the key to handle this situation.
But, the intuitive feeling of using newType-ts and io-ts is that the amount of code becomes more and the complexity of the type increases. What do you think?
Hello! You are right, the complexity of the project increases with this approach. But as always, it's a matter of tradeoff:
Do we agree to increase complexity, but have a self-documented and safer code?
Or are we fine with simpler types, but with lots of comment lines to explain their constraints?
Or no comment at all, but then we have to look at the runtime code parts scattered everywhere in the project to understand all the constraints?
Personally, as a developer, I would rather have all my answers directly in the type definitions. It would save me time as I wouldn't have to follow all the code paths that use such type to understand its scope, and it would also help me write fewer unit tests overall. But, as you said, it comes at a price: adding some abstraction/library to allow us to write types this way.
In this series, I've used the fp-ts ecosystem, but you may also use another library that does schema validation. The ultimate goal is to guard any input that travels to the core of your application where lies the business logic, and define types that provide as much information as possible, including the constraints. If you can reach this goal with the simplest code possible, then you have won!
Hopefully I answered your question correctly :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice! I found I have met the issue "what's the constraints of each property of the TS type?" Sometimes, the type have different state, like your said, the sum type is the key to handle this situation.
But, the intuitive feeling of using
newType-tsandio-tsis that the amount of code becomes more and the complexity of the type increases. What do you think?Hello! You are right, the complexity of the project increases with this approach. But as always, it's a matter of tradeoff:
Personally, as a developer, I would rather have all my answers directly in the type definitions. It would save me time as I wouldn't have to follow all the code paths that use such type to understand its scope, and it would also help me write fewer unit tests overall. But, as you said, it comes at a price: adding some abstraction/library to allow us to write types this way.
In this series, I've used the
fp-tsecosystem, but you may also use another library that does schema validation. The ultimate goal is to guard any input that travels to the core of your application where lies the business logic, and define types that provide as much information as possible, including the constraints. If you can reach this goal with the simplest code possible, then you have won!Hopefully I answered your question correctly :)