I like learning, continuously improving my skills, and like most things I come across, they take a while to sink in. I’m sure it’s the same for most people.
We get exposed to an idea, come across it on Twitter or through a co-worker, then we think about it and compare it to what we previously thought. Some ideas make it to learnings quicker than others.
React was one of those ideas that I had played around with for a while in my head and in some GitHub projects, but over the last year or so – I’ve been on a journey to figure out what it means to build UIs professionally – and I don’t mean just getting paid for it.
Why I needed React ⚛️
When I built my first really complex UI – it was a mapping application – I had no framework, no coding standards, no transpiler or even a build step – I had jQuery_._
I remember vividly, sitting there after being told the client was very happy with the work I had done (very important of course), but somehow I still felt like the application wasn’t my best work. As months went on and maintenance and new features were requested, it became harder to squeeze new life out of the project.
I was still finding my feet in JavaScript and felt uneasy because I thought there had to be better ways to do the things I’m doing. Maybe it was just needing to be able to split-up files and create modules to import/export. Maybe I could have used a library like Lodash to help with some of the heavy lifting.
There’s a whole bunch of tools and techniques I would use now that would make the application completely different, but perhaps the biggest change is simply changing from executing a set of steps, one after the other and expecting a certain outcome, to declaring what the UI should look like when the application is in a certain state.
I know what you’re thinking, I’ve just described React, but I believe it’s bigger than that. You don’t need React to start thinking in this way – it made the idea popular.
When I built the mapping application, it was always a certain set of steps executed in a certain order that produced the outcome (and it was buggy as hell!). This is fundamentally the wrong way to build UIs. It assumes we know exactly which steps the user will take. How many bugs have you had to recreate by following a certain set of steps? All of them?
You could just say that maybe my code was shit, and maybe it was – but I think removing the steps and replacing them with “this is how it should look and behave” makes JavaScript applications much easier to understand and maintain.
You don’t need React
It’s not the fancy ES6 code I’m writing now, it’s the way I think about splitting up the complex logic that lets the user do things into small discrete functions that have reasonable inputs and testable outputs. These aren’t concepts invented by React.
Over the past year I have been a fairly heavy user of React and reading about functional programming principles – both of which are extremely popular in the JavaScript community. I have had the chance to develop different types of applications with React, some small components, sometimes entire user flows and I can honestly say it has changed how I think about programming in general.
It has flipped the front-end developer mindset completely, it’s even contributed to fatigue but if you’re like me, the buck doesn’t stop there.
How to make the pieces fit
For all of this to really sink in, I chose to think in this way for everything I build.
When I create a function, it should describe the output, just by looking at the function. I don’t mean docblocks (although you should still write them) but making sure your function:
- Takes a limited number of parameters, optional or otherwise
- Returns output based on those inputs
- Does not need anything from outside the function, nor does it affect the outside world
- Provides meaning through naming of the function and parameters.
I would love for React to stick around for a while, but I’m just as happy for the next tool or framework to blow everyone’s mind and see things differently. Without people building tooling and frameworks, publishing their thoughts and ideas on the web, there is no progression.
At the end of the day, like you, I live in the real world where things have to be done by an agreed upon time but I don’t think this is an excuse to put any less thought into an application or React component structure.
Code is for humans to read
It’s not about the way you write code, it’s about how others read it.
Ultimately someone else has to read your code, whether it’s a code review or just changing the file. So be kind to other developers, add code comments when things get a little funky.
When you commit code you should be able to be confident that someone else could pick it up and understand it. That’s what I think we should be striving for in terms of code quality.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler, Refactoring: Improving the Design of Existing Code.
Top comments (0)