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.

React Code Prejudice

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?

• each component is expected to do only one thing and do it well.
• data is unidirectional, meaning that you cannot flow your changes back up the hierarchy tree, or pass it directly to a sibling. The only way is to lift the state up the tree, which can mess with the way you think about architecture and structure if you’re not used to working in quasi global-like states/scopes where mutations can only happen in one space and from a single source
• and that’s about it

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.

Trying To Enforce What You Know On React

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.

Forcing React To Be Something It’s Not

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.

• MVC-ing React with dependency injection — because why not? We do it all the time in .NET and Java. We need it for the controller to work properly, and to share data and states.
• class-itus syndrome — we love classes! We must only use classes! Because we understand classes and haven’t looked into React hooks and functions properly. Well, we have, but we’ve committed to using classes and so we must stick to using classes rather than refactor.
• naming debates — it’s a component, so we must have component in the name somewhere because that’s what everywhere else is doing it. The thing is, everything in React is a component, sorta, so that just makes it redundant. With React, is it basically a game of name it exactly what it is in the least amount of words you need.
• formatting — we must make it look like Java/.NET/Angular/whatever native language or framework you’re used to — because it worked there, therefore it must work in React also. This point is just a reminder that this is the equivalent of telling someone speaking a different language that the way they’re structuring their sentences is incorrect in their own native language. Here’s an example. Asian languages call things like ‘fish sauce’ ‘sauce fish’ in their native tongue. To them, their version is the correct one. To a native English speaker, that is clearly weird and wrong — but it’s not. If you try to say it the ‘correct’ way in their language, you’re the one that’s wrong.

Final Thoughts

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.