As the need for these libraries fades, and we see a massive rise in new frameworks, I’d argue it’s not as clear when to reach for them. At what point do we need React?
Here’s my take.
Even “state” is a bit of a nebulous word. Imagine things like this:
- Which navigation item is active
- Whether a button is disabled or not
- The value of an input
- Which accordion sections are expanded
- When an area is loading
- The user that is logged in and the team they belong to
- Whether the thing the user is working on is published, or a draft
“Business logic”-type stuff that we regularly deal with. State can also be straight up content:
- All the comments on an article and the bits and bobs that make them up
- The currently viewed article and all its metadata
- An array of related articles and the metadata for those
- A list of authors
- An an activity log of recent actions a user has taken
React doesn’t help you organize that state, it just says: I know you need to deal with state, so let’s just call it state and have programmatic ways to set and get that state.
Before React, we might have thought in terms of state, but, for the most part, didn’t manage it as a direct concept.
Perhaps you’ve heard the phrase “single source of truth”? A lot of times we treated the DOM as our single source of truth. For example, say you need to know if a form on your website is able to be submitted. Maybe you’d check to see if
$(".form input[type='submit']).is(":disabled") because all your business logic that dealt with whether or not the form could be submitted or not ultimately changed the disabled attribute of that button. So the button became this defacto source of truth for the state of your app.
Or say you needed to figure of the name of the first comment author on an article. Maybe you’d write
$(".comments > ul > li:first > h3.comment-author).text() because the DOM is the only place that knows that information.
React kinda tells us:
- Let’s start thinking about all that stuff as state.
- I’ll do ya one better: state is a chunk of JSON, so it’s easy to work with and probably works nicely with your back end.
- And one more even better: You build your HTML using bits of that state, and you won’t have to deal with the DOM directly at all, I’ll handle all that for you (and likely do a better/faster job than you would have.)
This is highly related to the state stuff we were just talking about.
React encourages the use of building things into modules. So this form would likely either be a module of its own or comprised of other smaller modules. Each of them would handle the logic that is directly relevant to it.
React says: well, you aren’t going to be watching the DOM directly for changes and stuff, because the DOM is mine and you don’t get to work with it directly. Why don’t you start thinking of these things as part of the state, change state when you need to, and I’ll deal with the rest, rerendering what needs to be rerendered.
It should be said that React itself doesn’t entirely solve spaghetti. You can still have state in all kinds of weird places, name things badly, and connect things in weird ways.
In my limited experience, it’s Redux that is the thing that really kills spaghetti. Redux says: I’ll handle all the important state, totally globally, not module-by-module. I am the absolute source of truth. If you need to change state, there is quite a ceremony involved (I’ve heard it called that, and I like it.) There are reducers and dispatched actions and such. All changes follow the ceremony.
If you go the Redux road (and there are variations of it, of course), you end up with really solid code. It’s much harder to break things and there are clear trails to follow for how everything is wired together.
Manually handling the DOM is probably the biggest cause of spaghetti code.
- Inject HTML over here!
- Rip something out over here!
- Watch this area for this event!
- Bind a new event over here!
- New incoming content! Inject again! Make sure it has the right event bindings!
All these things can happen any time from anywhere in an app that’s gone spaghetti. Real organization has been given up and it’s back to the DOM as the source of truth. It’s hard to know exactly what’s going on for any given element, so everybody just asks the DOM, does what they need to do, and crosses their fingers it doesn’t mess with somebody else.
React says: you don’t get to deal with the DOM directly. I have a virtual DOM and I deal with that. Events are bound directly to the elements, and if you need it to do something above and beyond something directly handle-able in this module, you can kind of ceremoniously call things in higher order modules, but that way, the breadcrumb trail can be followed.
Complicated DOM management is another thing. Imagine a chat app. New chat messages might appear because a realtime database has new data from other chatters and some new messages have arrives. Or you’ve typed a new message yourself! Or the page is loading for the first time and old messages are being pulled from a local data store so you have something to see right away. Here’s a Twitter thread that drives that home.
Learning something for the sake of learning something is awesome. Do that.
Building a project for clients and real human being users requires more careful consideration.
A blog, for example, probably has none of the problems and fits none of the scenarios that would make React a good fit. And because it’s not a good fit, it’s probably a bad fit, because it introduces complicated technology and dependencies for something that doesn’t call for it.
And yet, gray area. If that blog is a SPA (“Single Page App”, e.g. no browser refreshing) that is built from data from a headless CMS and had fancy server-side rendering… well maybe that is React territory again.
The web app CMS that makes that blog? Maybe a good choice for React, because of all the state.
That’s cool and all, but again, just because you can doesn’t mean you should. Not all projects call for this, and in fact, most probably don’t.
(There are decent emojis for YES and NO, but MAYBE is tougher!)
You’re learning. Awesome. Everybody is. Keep learning. The more you know the more informed decisions you can make about what tech to use.
But sometimes you gotta build with what you know, so I ain’t gonna ding ya for that.
Not everybody has a direct say in what technology is used on any given project. Hopefully, over time, you have influence in that, but that takes time. Eden says she spent 2 years with Ember because that’s where the jobs were. No harm in that. Everybody’s gotta get paid, and Ember might have been a perfect fit for those projects.