The Single Source of Truth concept and its implementations in React

Now, the homepage makes another /me call, but the sidebars don't. As a result, the CreatePostComponent is going to have the updated name, but the sidebars won't. Assuming you are a good developer who uses their eyes and not just their instincts, you would notice this right away and find a way to fix it.

To address this, you would need to implement a state lifting process after the PUT /me request that goes to the parent and then to the various children, resulting in an additional 4 /me calls. This approach is not only inconvenient but also error-prone and repetitive.

The SSOT concept in React

In React, we usually achieve this through one or more of these practices.

State Management Libraries (e.g., Redux):

State management libraries like Redux simplify the implementation of SSOT by creating a global state that holds all the data your application needs.

Using Redux has its pros and cons. Once it's set up, Redux is very convenient, but it's not a "plug and play" library. It involves several new concepts (reducers, slices, hooks) and a setup process, which may or may not be lengthy. Additional time may be needed if you're using RTK with TypeScript.

If your app is already in development, chances are you might want to refactor your entire app, and that takes time, resources, and possibly a learning process for some of the developers.

However, this is one of the best solutions for implementing SSOT in React. If done correctly, it eliminates code duplication and centralizes all states so that all parts of the UI are updated correctly.

Context API:

Similar to Redux, although not as powerful, React's built-in Context API allows you to create a global context that can be accessed by nested components. This is useful for sharing state across components without resorting to other, less clean practices like prop drilling and state lifting. It's often used for smaller things, like dark mode or language selection when setting up Redux may be overkill.

Using the Context API can be perfect for smaller features, but as the feature scales, it may start to pose problems. It's important to know that the Context API re-renders all components in which it's used every time the data changes. This means the state gets reset as well. So, if you're using the Context API to show dismissible error alerts, whenever an error gets added or removed from the list, all the components where you're using the Context (most of them, because you're going to need to be able to dispatch an error from pretty much everywhere) will cause your state to reset, potentially affecting form content, inputs, and selected options.

Component Hierarchy and Presentational Components:

The architecture you choose for your components also plays a major role in implementing SSOT. By thinking ahead, you can design your component hierarchy using 'container' or 'presentational' components. These components are responsible for fetching and distributing data among the components that need it.

In other words, a presentational (or container) component wraps all the sub-components needed for a

certain app view and takes care of the HTTP request and data distribution using props.

Here is an example of how our example structure could be improved using presentation components:

// Folder structure:
├── /pages
│   ├── HomeComponent <--- GET /me
├── /layout
│   ├── sidebars
│   │   ├── RightSidebarComponent <--- takes account data as a prop
│   │   ├── LeftSidebarComponent <--- takes account data as a prop
├── /components
│   ├── PopoverComponent <--- takes account data as a prop
│   ├── CreatePostComponent <--- takes account data as a prop

// HomeComponent
const HomeComponent = () => {
  const [me, setMe] = useState(null)
  // GET /me logic
  return <>
    <LeftSidebarComponent me={me}/>
    <main>
      <CreatePostComponent me={me}/>
    </main>
    <RightSidebarComponent me={me}/>
  </>
}

Now, you can see that the number of calls needed to populate the /me data has been reduced from 4 to 1.

As for many of the things we are discussing in this article, this approach has its own flaws. From a routing perspective, this means the sidebars will get re-rendered more times than they should. Just like anything in programming, the approach you choose depends on the situation.

State Lifting and Prop Drilling:

This is by far the most disliked thing by all React developers. State lifting can be challenging at all levels of coding. If you're a beginner, it might be hard to understand. As you grow as a developer, you might grasp state lifting, but it can still be a pain to debug. You have to follow the data around, open 12 files in your editor, console.log every step, and it can get really complicated.

However, it is a solution if none of the above options is a good fit. If Redux is not available or not worth it, and the Context API is causing more harm than good, you might consider state lifting your way to the top component.

Nevertheless, if you can avoid it, it's better to do so.

How to choose the correct solution for you

Choosing the right way to implement SSOT can be tricky. It depends on how far along you are in the development process, whether you have the time and resources to make significant changes, and if you have the decision-making authority.

In general, as a freelancer, I usually go the Redux route for anything that isn't related to dark mode, which I typically handle with Context.

However, if I already have Redux set up, I don't bother adding Context and manage dark mode through Redux as well.

In any case, you should always consider the SSOT concept while programming your web apps. It might not lead to a revolution in your codebase, but it will certainly improve your code, make it cleaner, and enhance your page's speed.

Happy coding!