Reflecting on 3 years of ReactJS (2015-2018)
We did React 0.12, 0.14, 15, now 16 (with create-react-app) over the span of 3 years (1 month shy)
It’s the most ridiculous engineering platform I’ve ever used, and yet the most coherent dev community I’ve ever experience, in my 2 decades on web dev work.
Can you imagine porting and upgrading the code base over and over, because old things keep breaking? Add to that this npm community with took so long to figure out how to keep dependencies properly.
On the days it doesn’t break, JSX became a rich language that I could write poems in.
It’s a strange but satisfying feeling, because every line of code I write, I feel like I was also making design decision for the platform, like choosing from the vast libraries of the interwebs built for react env.
Or making deliberate choices like adopting ES2017 when I can (property initialisers ftw!) and yet putting on hold other new ideas (generator functions meh…)
Even how you’d tear normal <html> code apart was an art. Classes are not for the sake of OOP but for the sake of common sense amongst the team (this box is a class! that div should split in to 3 components!)
By the time it was paired with our websocket services, it finally shined brightly.
Everything “reacts”.
Exactly what we needed for real time applications on the web, drawing plane icons around with dozens of telemetry numbers flickering and knobs to turn for Garuda Plex, and visualising data on all our other domain specific and bespoke web properties.
I have 5 takeaways if you’re coming into React land in 2018 and building for the long run.
1) I now believe in create-react-app: yes I was one of those who rolled my own gulp and browserify scripts to death. It’s not worth it. Leave it to the highly paid facebook engineers.
2) Pick one coding style and stick to it: This concerns more javascript than react, but seriously, don’t slowly morph your style over the code base as you learn more and more, ending up with a code base that has a mix of createClass to ES6 classes to const functional components. It will kill your brain as your try to maintain the code in the long run.
3) Schedule downtime for upgrades: Yes they break it so often that you might as well schedule react upgrades into your work plan. This is where previously made decisions that are no longer good can be fixed in isolation from all the new requirements. I once spent 2 weeks just rewriting the entire code base to replace .bind(this) with fat arrows =>
4) Limit every file arbitrarily: Divide and conquer dude. If you don’t know how and when to divide, then better start divided (follow any of your favourite model, e.g. have a abstract component that loads data, another that acts as a view controller, and the 3rd level onwards tiny components for display), and watch your tiny files grow. Alternatively, fix a max lines per file (for us it’s 1000). One you’re coming close to that arbitrary max, break your component into smaller piece.
5) Master the lifecycle: As in, not just learn one tutorial and leave it. Master it by looking under the hood, try the weirdest thing that the tutorials your peers wrote never mentioned, especially the lifecycle methods that you rarely use (componentWillUpdate anyone?) It turns out that was critical especially your application uses 3rd party javascript libraries that are not in “react land”. Ours was google maps and threejs. React, 讲难听一点, is the largest hack on the browser we’ve seen in years – and to respect this hack is to hack it to know where it breaks and where it will serve your purpose.
Happy Reacting!
p/s sorry this post is not about people fighting over propTypes, to redux or flux, shallow rendering benefits, and so on. That’s life in open source software, be a dev, deal with it!
