PropTypes?

Photo by Jon Tyson on Unsplash

Many developers use PropTypes to produce a better API for their consumers. But let me tell you this: propTypes are almost entirely useless. They bring nearly 0 value.

To illustrate this, let’s get back to the v-btn. This time we’ll assume that v-btn authors have used PropTypes. You, consumer, having no knowledge about the implementation of this component, added it into your template. You start the app, open the browser, and see… Nothing, again. The page is still blank.

But this time, at least you see a few errors in browsers console, politely hinting that you forgot to provide a prop. This is helpful. You know what to do: just add a required property to v-btn and be done with it.

But this is useless in production. End-users don’t keep a console open. They would only see an empty page (or at least not-rendered component). There is no way for them to understand what happened. PropTypes does not support you with a way to communicate the issue to the end-user. Technically speaking, there is no fallback.

Don’t get into the trap of “default value”. The default value is not a fallback. If you can default a property, that means consumer’s data is not that important to you. In other words, if a component itself can provide a value, the prop is not really required.

The second problem with propTypes is that it doesn’t reduce a long feedback loop. When you add a component to your code or change anything, you have to run the entire application, get to the point where the component should render, and only after that verify if it works. Here is an issue: this process can be enormously long.

What if you work on a large, extensive application with hundreds and hundreds of components? Or if the path of getting to this component is hard and thorny: click on five buttons, then submit a form, then wait for a response from a very slow server, then do this, then do that…

Just imagine, that you have to waste a few minutes of your life to run the app, then get to the point when your component is supposed to render, and all this just to see an empty page with console errors? And then repeat this loop, after you realize that you simply misspell the prop name? And then repeat one more time because the prop is expecting a string, not a number? And if you think about it, you would have to do the same even without PropTypes. They didn’t bring too much value on the table.

The heart of the issue is that propTypes communicate the error when it’s too late — it’s like reporting the misfunctioning rocket engine after the spaceship has already launched.

However, there is a way to reduce the feedback loop significantly and also provide insurance that end-users will never face failed components only because consumers forgot to provide proper data.