Every time I use React I get a nice feeling in my belly, that could just be the nice lunch I had or that it seems to try to look after me and make it easy to write nice code you can come back to.
PropTypes is one of the features it offers and you should probably use it a whole lot more than you are.
Why React PropTypes rock:
One of the things I really like about React is how it helps you write maintainable code. Code that you can come back to in 6 months and quickly pick back up without too much additional effort.
One of the features baked into React that help with this is called PropTypes. This is a simply little helper function that you define in your component that will check that the properties you are passing into your component are actually the ones you think they are. Sort of Type checking on the cheap.
There are other ways you could do this but this is baked in and needs no more additional tools or parsers in your compile steps so I like it.
If you wanted a string you can get it to check that what you get passed is indeed a string. Need a required value? Yep you can get that done too. See the offical documentation on the how to use PropTypes, this post is more about thewhy and when to use PropTypes.
PropTypes will send a warning to your browsers console window to let you know if anything passed in was not as you expected. Great for simply things like NaN (Not a Number) being rendered out to the screen or catching otherwise nasty headscratching bugs caused by the wrong data being passed in you would otherwise miss.
This is all lovely but to make it more lovely React won’t break anything if your PropTypes method finds difference. Your code might break as a result but React won’t blow anything up on your behalf, it tries to be helpful but stay out your way. Its up to you if you listen to its wise advice.
All this is very good but I think a lot of people skip over PropTypes in the sake of "getting things done" and shipping the project or simply to get to the good bits quicker.
It takes time to create that little helper and most folks think they are awesome coders so of course they are not going to make any mistakes...right? I'm a bit more of a realise, I know I'm going to mess up its just a case of when.
But I’d like to make a bit of an argument for taking a little time to add in PropTypes to you components to help you awesome coders be more awesome.
PropTypes document the properties your component needs
I could have called this an interface or a contract but thats getting a bit code heavy for javascript land so let me ditch those overloaded words for "cheatsheet" instead.
By using PropTypes you are giving the next developer an at a glance cheatsheet of how to use your component and what is expected to be poked in to get the best out of it. That’s a powerful reason to use it right there.
Imagine knowing at a glance what that component needed without having to parse the code in your brain. Imagine why the heck Facebook added in the first place! For this reason we always put our PropType method at the top of our component code so its the first thing you see as its probably the most important when you come back to it in 6 months time.
You want to know how to use it and for that you need to know what to poke in.
PropTypes prevent build up of errors
I’ve had an occasion were another developer on our team was passing something though in the wrong type, they didn’t know it at the time as we didn’t have PropTypes setup then.
This prop inturn was just daisy chained down the component tree for another 2 or 3 levels. Nothing caught it until I started adding PropTypes to our tiny components (ones that don’t have anything nested in them) the leaves on the end of the component tree. This allowed us to trace the issue back up to its cause and put it right.
This fixed another bug we had that we didn’t know the cause of all thanks to PropTypes looking over our shoulder.
There are some issues though:
Bloat on live?
PropType functions are only used in development not production. This is great on the face of it, you don't want loads of noise about how badly you've coded up a site appearing the console window on live.
However it does mean you are sending bytes down the wire that will never be run which might put some of us off adding them in the first place.
It would be nice if there was a way to strip these out if you are building for production. That way you could use them heavily without the additional page weight of code that will never run on live being sent down the wire.
I’ve already written a stripper to do just this in webpack that’s about 6 lines long but it totally breaks all my source maps and I’m not smart enough to do it. If you have more brain power or knowledge please feel free to take that one on and I’ll owe you a beer.
Missing a strict mode?
As much as I like the laid backness of the "warn don't break" rule while developing it might be nice before production to make its a more "warn then break" to sort of force us to not ignore warnings before going to production.
When not to use PropTypes
Writing PropTypes for everything could get a little cumbersome if your project is still in the feeling it out phase. That’s often the time that things get changed often and it can make for quite a bit of additional keystrokes to keep everything in check.
However, unlike code comments or static documentation this is living breathing code so it "should" just be part of your job to keep this up to date as it is looking after your future self from cocking up.
However there is another issue, what if you have components that simply wrap another component and just passes the props down the tree untouched? Should you cut and paste the PropTypes between them for completeness?
Well if you really wanted too then yes you can but again if anything is going to change you have to accept the time cost of updating that interface between all the components (assuming you want to keep everything named the same).
An alternative method we’ve been using is to insist that you add PropTypes to leaf components, the fine grained ones as that tends to be where things are actually used or output to the user.
Adding them to other components is optional but encouraged. This way we can work back from the leaves to the trunk as time allows and the project takes shape and changes settle down. I'm still not aiming for 100% PropType coverage though, I think that would be too much of a mainteance headache for the gains at this time.
What if we are passing an object in a prop?
This is where things can get smelly.
You can define a shape (aka a class or interface of sorts) that your property has to have as a minimum which can be handy for small objects. But when you start passing around complex objects just how far do you go with this whole PropType stuff?
I think you can take this too far if you are not careful, too many checks makes it difficult to update and interrupts the flow when coding. Again for the sake of "getting things done" you often make changes and ignore the errors and promise to come back to PropTypes later to get rid of the warnings in the console but you never do.
Skip forward to you just commenting it out to get rid of the noise in the console while you fix another issue, so much for that. Don't worry we can all do it, it can be the price of "getting things done" sometimes, the trick is getting the balance right so you don't feel too dirty.
So use it wisely rather than making it easy to let the code start to smell, don’t set yourself up for a fall by PropTyping all the things. Again I suggest PropTypes on small self contained components and possibly their parent wrapper components as a minimum. After that is up to your judgement.
Summing up
PropTypes is no magic bullet but it is a handy and simple tool to help you write maintainable code that’s pretty much self documenting. Use it more than you have been but don’t go crazy.
As usual in this world of 0’s and 1’s / true and false that we work in there are many shades of grey, knowing where they lie is why you get paid.
If someone writes that PropType stripper let me know! I want in. I wonder if you could use PropTypes for automated documentation or for showing in the Chrome extension for easy "at a glance" sanity checking? Could be interesting...