Separating Separation of Concerns

My name's Jacob. I live here, I work here, and my concern today is to tell you that my concern is what I'm attempting to do, and that how I accomplish that will necessarily mirror my understanding of my concern.

An excellent first example is to talk about a to do app. If I choose to conceive of my to do app as managing a list of non-interconnected tasks, then I'm probably going to write code that maps from an array of non-interconnected tasks to an array of elements, and I'm going to slot that in the DOM, and that's going to be my primary functionality, but that's not going to be the entire app. I'm probably at least going to have a heading and I'm going to have a div around that and maybe a footer and maybe some analytics and maybe some trackers. And I'm going to represent all of that as a tree structure, and to instantiate that tree structure, I'm going to use the DOM because the web is good.

And what we run into immediately is that our headings aren't just like presentational semantic. They don't simply have that concern. By enframing the functionality they enable the functionality. We wouldn't be able to interact with this app if we didn't know what it was and how to do it. So these sort of crosscutting concerns, it's useful to co-locate them instead of separating them out into HTML, CSS, JavaScript files. And that was what React meant when they talked about separation of concerns rather than separation of technologies.

Another set of concerns that we have co-located in all of our components are our concerns of functionality and our concerns of efficiency. And these were the two primary concerns that Dijkstra was talking about when he introduced the term separation of concerns in his seminal paper on the role of scientific thought. The most germane passage is as follows. A program must be correct and we can study it from that viewpoint only. We also know that it should be efficient. We can study its efficiency on another day, but nothing is gained by tackling these various aspects simultaneously. It is what I sometimes call the separation of concerns which is yet the only available technique for effective ordering of one's thoughts. And when we talk about efficiency in React land and in industry more generally is as if it were the precise inverse of abstraction. Because React is more abstract than JS, it follows that we can expect that React will be significantly slower than JS, but this isn't actually the case. If we look at a piece of JS, say 3JS, and we look at React 3 fiber, we see that React 3 fiber is actually faster than vanilla 3. And what this tells us is that we may be misconceiving of React. We may be thinking of React as being 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 rerender 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 now signals pulling it all the way out of React. I think this kind of 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 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, 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, that our app is almost always going to be fast enough to deal with what we want to do.