We all know that separating concerns is different from separating technologies. That's what react's all about. But what is a concern? What is it to separate them? Why should I be concerned about concerns, or separation?
Separating Separation of Concerns
And what this tells us is that we may be misconceiving of react. We may be thinking of react as being, say, an entire framework, when it may be something closer to a library that has a particular concern of dealing with, in this case, scheduling.
And one of the downfalls of this mode of conceiving of it is that when we structure our apps incorrectly, we can't take advantage of react. One of the biggest problems in react is that our components re-render too often. Too often, in quotation marks. And to deal with this, we pull our state out of those components. For example, Redux at arm's length and pulling it all the way out of react.
And I think this misses the point. And I think the core react team might agree with us. Because they actually put together a state management library right when they made react. This state management library is called react. And every time you NPMI react, you're also NPMI-ing react.
So, let's see what this react does. If I look at my component, I'll notice that there are actually two, more than two, but at least two concerns that are all jumbled up inside of it. If I'm a list, I don't care about every single letter that enters this input. That's not what I'm concerned with. And having it in this input means that this input is going to re-render with every single letter that comes in.
It seems reasonable of react, and this was the whole point of react, for it to re-render whenever state changes. That's how it reacts. That's what it's reacting to. It's state change operations. The whole sort of message of early react was that UI is a function of state. And that's what the component form is. We're taking all of the state and we're bundling it together with the UI. We're saying that the two are inseparable.``` And so, what react is doing is it's taking advantage of this. It's taking advantage of this implicit connection between the components and the tree of components to say that we don't need to explicitly talk about the connection between pieces of state. The component tree is that connection between the pieces of state. And so, as long as we properly separate our concerns, as long as we properly separate our states, and as long as we properly separate our components, not only will we get a more efficient app, but we'll also get an app that's a lot easier to read. We'll get components that are smaller, faster, lighter, and more readable. And that's what I find staggeringly beautiful about react. Is that if we properly think about our concerns, which we ought to be doing anyways, then our app is almost always going to be fast enough to deal with what we want to do. And if it isn't, then I guess you should use svelte. ```