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?
This talk has been presented at React Advanced Conference 2022, check out the latest edition of this React Conference.
The primary functionality of a basic to-do app, as described by Jacob, involves managing a list of non-interconnected tasks and displaying them in the DOM as an array of elements.
Jacob suggests co-locating crosscutting concerns such as functionality and presentation within components rather than separating them into different technologies like HTML, CSS, and JavaScript. This approach aligns with React's philosophy of separation of concerns rather than separation of technologies.
In his seminal paper, Dijkstra introduced 'separation of concerns' to describe the methodology of addressing different aspects of a program at different times, such as correctness and efficiency, to effectively organize one's thoughts and enhance problem-solving.
Jacob indicates that despite React being more abstract than plain JavaScript, it does not necessarily perform slower. In fact, React can be faster, as demonstrated by comparisons like React 3 fiber versus vanilla 3JS.
Jacob highlights a common misconception that React is an entire framework, whereas it might be more accurately described as a library focused on specific concerns like scheduling.
According to Jacob, one of the primary performance issues in React applications arises from components re-rendering too often, which can be mitigated by managing state more effectively outside of the components.
Proper separation of concerns in React—such as separating states and components—leads to more efficient, readable, and maintainable applications. This approach leverages React's structure to optimize both performance and developer experience.
My concern is to accomplish my understanding of my concern. A to do app can have more than just managing tasks. Crosscutting concerns should be co-located. Separation of concerns is an effective technique for ordering thoughts. React is not slower than JS. React may be closer to a library with a concern of scheduling. Rerendering components too often is a problem in React.
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.
React is a state management library that is bundled with React itself. It helps in separating concerns and states, resulting in a more efficient and readable app. By leveraging the implicit connection between components and the component tree, we can avoid explicitly talking about the connection between pieces of state. Proper separation of concerns, states, and components leads to smaller, faster, lighter, and more readable components.
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.
Comments