I was pondering whether you need to know about React Class Components before learning React Functional Components.

A little background about me: I work in an internal department, commonly called “shadow IT” because it’s not part of the official IT.

This is important to say because most people I’ve known came from different backgrounds than that in Computer Science (and similar). I, myself, didn’t come from a CS background.

And because of reasons, where I work we can’t just hire people, we have, kind of, pick people in other areas to come work with us and this usually means people with little to no experience in programming (even when they actually want to).

I’ve already put some of my thoughts on this before (check my other posts), but this time, I got into a discussion about whether you need or not to learn React Class Components before learning React Functional components.

This is an old discussion

This is not about React. In the frontend alone we had Vue2 and Vue3 also AngularJS, and Angular 2+, also the era of jQuery, lodash, and moment.js.

This is also not about frontend or frameworks. We had python2 and python3 and JS before and after ECMAScript 5.

This is just the top of my mind and there are many more that I myself have no idea or experience with. (Examples are welcomed in the comments!)

How much do you need to know about what was?

For a beginner, my opinion is that you don’t need to know anything but whatever is freshest out there.

When I learned React, I knew class components existed and that was it. Functional components were enough for everything I needed and even today, as far as I’m aware you need class components for one case only (Error Boundary), and even then there are packages that neatly abstract that into functional.

More than that, if you’re starting now, you would have multiple sources using the latest versions and a lot of people to learn with along than if you choose to start in an outdated or niche language/framework.

Imagine trying to learn COBOL as a first language today?

In the case of React, the problem is, of course, legacy. In React, you can have the legacy part side by side with the new code. In other languages/frameworks, you would have only the legacy or it somehow segregated in a small part or microservice.

The overhead cost of the legacy stack

In the case of React, depending on your source and your legacy code, you would expose newbies to class components, Redux, and probably moment and lodash.

A totally valid stack back then, probably sprinkled with functional components, hooks, and a different version of ECMAScript functions being used depending on when it was written.

All of that before actually having to use the “current” stack and learn all the business rules and project structure.

Meanwhile today, you can start with functional components, hooks (including Context API), some basic JS, the business rules and project structure, and you tackle anything else you might need as you go.

The basics are important, just not now.

One would probably start to actually code a lot sooner and without a lot of unneeded preconceptions than the other one, that with luck, would only mix and stumble on a lot of things that they learned… that is if they didn’t give up before that.

There’s no need to “appreciate” all that came before, otherwise, you would need to start in Assembly, code all the Data Structures and Algorithms in C, and do all the Design Patterns in Java to finally do a “Hello, World” in JS.

Types, Data Structures, Algorithms, Design Patterns, and the older version of the framework, language, and packages you use today… that comes later and probably with a problem attached to it.

How much to start out?

Ignore all but the essentials and make it work.
Ask for reviews and make it right.
Learn some more and make it better.

(Yes, I’m parodying Kent Beck’s phrase: "Make it work, Make it right, Make it fast”.)

In other words:

• Learn the least necessary to make it work.
• Don’t try to understand all of it, just trust that it works and be happy for now.
• Have mentors, and ask for code reviews. In other words: code and show people your errors.
• Learn from the feedback and code some more.
• Learn yet more, go as deep as you need or want, and code more and better.

Your turn!

If you’re beginning, code and show us the code!

Else, comment on how you’ve started coding or why I’m wrong.

Cover Photo by Braden Collum on Unsplash