Hacker News new | past | comments | ask | show | jobs | submit login

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



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.


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 to make API calls typed.


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.


Not necessarily - you could be parsing a JSON API response or something.


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 for Scala.js




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: