5 ms·

Flow is not a replacement for propTypes, they are complementary. Flow for compile-time errors, propTypes for runtime errors.

namuol 10y ago
For those who want the best of both worlds: https://codemix.github.io/flow-runtime https://codemix.github.io/flow-runtime
raquo 10y ago
It is though. Runtime type validation is just a clutch that's needed when you don't have compile time validation.
- streptomycin 10y ago
  Technically true, but how many projects actually are 100% typed, including: * absolutely no any types or other imprecise types, no files skipped, no lines skipped, etc * every single piece of external data (API requests, reading from localstorage/IndexedDB, etc) is explicitly validated to make sure it exactly conforms to expectations * all dependencies are also typed to the same standard (not just some type definitions slapped on top of an npm module, those could easily be wrong and often are) Probably some are. But none of mine are, sadly. And I don't think I'm in the minority.
  - raquo 10y ago
    You could make some of the same arguments against prop types - what if you miss them, what if they are incorrect (too narrow). Regarding third party libraries, with prop types you are effectively writing your own bindings to the parts of those libraries that happen to go through your props, except you fail far away from where the error is produced. Prop types are also a very ad-hoc solution to a very general problem. Why are props for UI components especially deserving of type checking? What about the rest of your application code? Event your components' state is not worthy of type checking? With JS or typed-JS languages like Typescript or Flow you will never get full type safety (Flow is better at safety than TS if you're interested). For me the solution is to either go 80% of the way for 20% of the effort with those languages, or go full Scala.js or something that is actually type safe. And the latter has many goodies like https://github.com/lihaoyi/autowire https://github.com/lihaoyi/autowire to make API calls typed.
- untog 10y ago
  Not necessarily - you could be parsing a JSON API response or something.
  - raquo 10y ago
    If you don't trust your JSON input to be of proper type, you should validate its type immediately when you receive it, before you start fanning it out to your code. Spreading this work to prop types just makes it harder to keep track of it, and harder to find the source of the problem. Besides, some of that broken JSON data might never even be passed through proptypes (e.g. if that data lives only in a component's state). Also, there are compile-time solutions to this in some compile-to-JS languages, e.g. like https://github.com/lihaoyi/autowire https://github.com/lihaoyi/autowire for Scala.js
- linkmotif 10y ago
  Let's not forgot prop type checks are removed during build (if you are building). So they don't happen in production. Like some kind of type erasure, but not :D.

namuol 10y ago

For those who want the best of both worlds: https://codemix.github.io/flow-runtime https://codemix.github.io/flow-runtime

raquo 10y ago

It is though. Runtime type validation is just a clutch that's needed when you don't have compile time validation.

streptomycin 10y ago
Technically true, but how many projects actually are 100% typed, including: * absolutely no any types or other imprecise types, no files skipped, no lines skipped, etc * every single piece of external data (API requests, reading from localstorage/IndexedDB, etc) is explicitly validated to make sure it exactly conforms to expectations * all dependencies are also typed to the same standard (not just some type definitions slapped on top of an npm module, those could easily be wrong and often are) Probably some are. But none of mine are, sadly. And I don't think I'm in the minority.
- raquo 10y ago
  You could make some of the same arguments against prop types - what if you miss them, what if they are incorrect (too narrow). Regarding third party libraries, with prop types you are effectively writing your own bindings to the parts of those libraries that happen to go through your props, except you fail far away from where the error is produced. Prop types are also a very ad-hoc solution to a very general problem. Why are props for UI components especially deserving of type checking? What about the rest of your application code? Event your components' state is not worthy of type checking? With JS or typed-JS languages like Typescript or Flow you will never get full type safety (Flow is better at safety than TS if you're interested). For me the solution is to either go 80% of the way for 20% of the effort with those languages, or go full Scala.js or something that is actually type safe. And the latter has many goodies like https://github.com/lihaoyi/autowire https://github.com/lihaoyi/autowire to make API calls typed.
untog 10y ago
Not necessarily - you could be parsing a JSON API response or something.
- raquo 10y ago
  If you don't trust your JSON input to be of proper type, you should validate its type immediately when you receive it, before you start fanning it out to your code. Spreading this work to prop types just makes it harder to keep track of it, and harder to find the source of the problem. Besides, some of that broken JSON data might never even be passed through proptypes (e.g. if that data lives only in a component's state). Also, there are compile-time solutions to this in some compile-to-JS languages, e.g. like https://github.com/lihaoyi/autowire https://github.com/lihaoyi/autowire for Scala.js
linkmotif 10y ago
Let's not forgot prop type checks are removed during build (if you are building). So they don't happen in production. Like some kind of type erasure, but not :D.