30th May, 2021
5 min read
Not too long ago, I committed myself to learning React properly. As a long-time
software developer, I’ve been on and off React projects, depending on what the
team needed. Despite what others assume about me, my personal gauge of
understanding how the darn thing works is probably at the
Not too long ago, I committed myself to learning React properly. As a long-time software developer, I’ve been on and off React projects, depending on what the team needed. Despite what others assume about me, my personal gauge of understanding how the darn thing works is probably at the tinkering level.
I can do things. I can make ticket requirements happen. But there’s a lot of hand-holding from Google (not that there’s anything wrong with that either).
Over the past few weeks, I’ve immersed myself in a bunch of mini prototypes to figure out how certain concepts work, their nuances, and the things that no one really talks about in follow-along YouTube tutorials.
From this experience, I’ve discovered that there are a few meta things about being a software developer that can really hold you back when it comes to learning to code in React.
Everyone has a preference — and this preference can set you up for future prejudices against different ways of thinking. Why do we do this? Because we’re biased towards what we know and what we’ve experienced as something that works.
For OOP-biased developers, React will challenge and irk you with its decentralized way of thinking. While there are classes and all the lingo that goes with OOP, React is fundamentally pushing towards a single tasked functional approach with reusability in the forefront.
What does all this mean?
React is a big little library. Its sole purpose is to deal with UI and if you’re coming in from a framework mentality, it’s going to annoy you by forcing you to slim down the way you think about your code and the extent of what React can actually do.
Let’s get real — when you become comfortable in something, you just want to keep using it because it’s easy. Not only that, you know it worked in the past, so why not transfer it to a different space?
The issue here is that React is not trying to be Angular, Vue, .NET, Java, or anything other framework or language you’re used to. React is also not those things either. It is its own set of thinking, principles, and ideas enforced in a particular way that can clash with common ways of thinking.
While there might be similarities, it doesn’t mean that it is exactly the same. This is where developers fall apart.
As an Angular developer with a node.js and PHP background, React at first felt truly strange. The more I resisted it, the harder it was to make React do exactly what I wanted. However, what I was trying to do was make it into something I already knew rather than accept it for what it is. This is a common mistake that is not isolated to the task of learning React. It is an issue that spans multiple languages when developers move, or are forced to move out of their comfort zone.
When this happens, we become juniors once again, despite whatever our official title is. Then it becomes a clash of identity vs. reality because when you’re a junior, there’s a large swathe of knowledge area that you don’t know — but when you’ve got a senior or intermediate title attached against your name, you’re expected to have the capacity to perform your job.
So you start drawing on what you know rather than taking the proper time to learn the things you should know. It’s a cheat way to shortcut yourself into a working application — but it’s not a guaranteed way that will ensure that you are the best possible software developer in that particular area of coding.
Let’s get real, we’ve all done it at some point. If it’s not on React, then it’s on whatever thing you’re trying to learn. Here are some common ways to force React to be something it’s not based on what I’ve seen, what I’ve been told, and personal project experiences.
I’m not an expert in React and I don’t claim to be. Rather, this is more a reflection on unhealthy habits that we as developers have when we try and learn something new.
When we get stuck in our code patterns, it can be hard to let it go and accept that there might be a better way to do things — even if it seems inefficient at first. I’ve seen it happen in Angular projects I’ve refactored and the same underlying issues that caused it is easily transferrable to a React project.
React is strange — especially if you come from a background where everything is neatly sectioned off in classes and inheritable components. While on the surface, React allows this, it doesn’t mean that it is the best methodology for getting things done and structured in an architecturally sound way.
React is great. It gives us a ton of freedom to do what we need to do. However, with great freedom comes the increased potential for a project that’s structurally mangled.
When I first started using React, all the tutorials were pretty basic with file structures that were linear
Looking into another React extension
In a nutshell, the framework enables you to get up and running with React quickly
React class vs. functions. What's the big deal? What's the big difference?
Previously on Learn React from Scratch Series:
Learn React: Your First React Component ExplainedPreviously on Learn React from
Scratch Series: Learn React: Advanced JSX and Everything Else You Need To
KnowPreviously on Learn React from Scratch Series: Learn React: Quick