Echo JS 0.11.0

<~>
jaleksic 2085 days ago. link 1 point ▲ ▼
I used flowcheck in a project once, with flow checking even at runtime.
It's deprecated in favor of https://github.com/gcanti/babel-plugin-tcomb now. Still not the same as proptypes.

I've seen typescript react code recently where in addition to typescript interfaces, proptypes were used too. Not sure why that is. I understand that typescript gives you good integration with some editors or IDEs. Not sure why you'd need proptypes on top. But then again, I don't really know much about the topic. Maybe somebody will clarify things in this "thread".

Personally, I'm happy with the way proptypes work. I see it as lightweight assistance during December, not as something that guards me/my code against bugs or problems.

Replies

lorefnon 2084 days ago. link 1 point ▲ ▼
Library authors would often use prop-types in addition to typescript so that library users who are not using typescript will get runtime warnings when incorrect types are used. 

Also prop-types support adhoc runtime validations which can't be done through typescript at compile time. I have, for example, used this feature to reuse mongoose schema validations in client side in past.

Of course keeping equivalent prop-types and typescript/flow types in sync in a large project is a pain. 

An interesting alternative here is prop-types-ts [1] package by the same author [2] which uses io-ts [3] to unify runtime and compile time type checking.

[1] https://github.com/gcanti/prop-types-ts
[2] https://github.com/gcanti
[3] https://github.com/gcanti/io-ts