Separating Separation of Concerns

Rate this content

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?

7 min
24 Oct, 2022


Sign in or register to post your comment.

AI Generated Video Summary

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. React is a state management library that helps in separating concerns and states, resulting in a more efficient and readable app. Proper separation of concerns, states, and components leads to smaller, faster, lighter, and more readable components.

1. Concerns in React and Separation of Concerns

Short description:

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.

2. React State Management and Separation of Concerns

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.

React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.
In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Summit Remote Edition 2020React Summit Remote Edition 2020
32 min
AHA Programming
Are you the kind of programmer who prefers to never see the same code in two places, or do you make liberal use of copy/paste? Many developers swear the Don't Repeat Yourself (DRY) philosophy while others prefer to Write Everything Twice (WET). But which of these produces more maintainable codebases? I've seen both of these approaches lay waste to codebases and I have a new ideology I would like to propose to you: Avoid Hasty Abstractions (AHA). In this keynote, we'll talk about abstraction and how you can improve a codebase applying and creating abstractions more thoughtfully as well as how to get yourself out of a mess of over or under-abstraction.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.

React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.

React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:
- Create Remix Routes
- Style Remix applications
- Load data in Remix loaders
- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.
Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.
Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem
IDE of choice (Inellij or VSC) installed
Nodejs + NPM

JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
- Good understanding of JavaScript or TypeScript
- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications
Preinstall Node.js, npm
- We prefer to use VSCode, but also cloud IDEs such as
(other IDEs are also ok)