Why You Should Separate Your View Data from Your UI
Modern front-end development combines modular, reusable components and engaging user experiences. DRY, or do not repeat yourself, captures this goal as developers are challenged to make components modular. While there is a lot of emphasis on making components easy to change and manage, there is not as much focus on breaking UI data into its own concerns. I believe that good front-end development should separate view data from the UI.
What is the Current Approach for Front End Design?
Today’s front-end development sees a mixture of concerns. What I mean by this is having components that handle many things at once. A common pattern for framework-based apps is combining stateful and stateless components. The difference between these components is that one is purely UI (stateless components), while the other handles state data and updates from user interactions (stateful components).
Stateless components are easy to work with because you know the effects of your changes are superficial. They change what the user sees, but do not change how the app works. Stateful components are more difficult to work with as you must know how the state changes the look and feel of your components.
In our case, data is not necessarily state. It is likely a hardcoded data structure in a UI file that is read into the current component, or iterated over in a special component container. In both cases, the static data is directly tied to the component:
No developer will create by hand 20 child components with data. However, they may create a ContainerX component in which to store the hard-coded data and the list of iterated child components:
In this case, you have separated the data from each child component, but are still making non-DRY containers for each use case of your data. This is not great as you may soon have many copies of a container component like Container Y, Container Z… so on.
Our next approach is to move the hardcoded data into a parent page component and then feed the data into a generic container component:
This is better, but still not great. Our issue here is the page should not hold the data, and will quickly become cluttered if we take this approach for many containers on a page. There must be a better way to handle data in our front end.
The Benefits of Separating Data from UI Components
We can better build this UI by abstracting hardcoded data from our UI components. I usually create a data directory for each of my data structures or concerns inside the src directory of a React project.
Instead of storing hardcoded data structures in the child components, container components, or page components, I store all data in separate data files. I can require these variables and pass them into the appropriate page component to share with child components. This approach looks like this:
There are many benefits of this. One of the most important is separating where developers’ attention is needed. If the business team wants you to update the copy based on the current year or new SaaS product functions, you know you need to update a file in the data directory.
If the user wants you to update how a user interacts with a feature, you go to the components or other UI component directory. The separation of data versus functionality concerns makes development clearer and quicker.
Along with this, your code will be cleaner and easier to work with. You can avoid writing components that are hundreds of lines long by removing massive hardcoded data structures. You also avoid writing data-specific copies of shareable components as the data drives building pages over the components. Separating data from your UI components makes front-end development a better experience.
