Echo JS 0.11.0

<~>
deerloper 2303 days ago. 
I'm wondering if it's possible to drop the PropTypes.
So far looks like yes but I'm concerned for any edge case I cannot foresee right now.

In this Twitter thread there some interesting thoughts (https://twitter.com/sospedra_r/status/1025318636175679488)

For example, when you consume directly from an API. Your static typing will not complain on build time but it might fail at runtime if the API payload contract changes.

What are your ideas and thoughts?

jaleksic 2302 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.
lorefnon 2301 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
dimorphic 2303 days ago. link 1 point ▲ ▼
Your concern should be for PropTypes also, as that's only for 'dev' mode. PropTypes, TS typings and Flow props (not sure on this cause i skipped it mostly) don't do anything as in checking for a 'payload' contract/schema. Typings doesn't fix that, your code has to 'consume' and map the API response in whatever format you want considering your types/props in the code.

Mhm? :)

P.S: try this with TS: https://github.com/typestack/class-validator