UI State — JS: Frontend architecture

Changing the state in a frontend application doesn't always mean changing the data that the application works with. Data may have a state that affects only its appearance. It's possible for there to be no such state in the database on the server.

Imagine an ordinary accordion. This is a way of displaying data through which you can individually hide or show elements in a list. In order for this kind of accordion to work, you need a state defining how each element is displayed: collapsed/open. This state is called the UI-state (user interface state). Where should this state be stored?

You could place it inside the data itself:

// List of companies. The visibility flag is responsible for what's displayed in the accordion.
const state = {
  companies: [
    { id: 1, name: 'Hexlet', description: 'online courses', visibility: 'hidden' },
    { id: 2, name: 'Google', description: 'search engine', visibility: 'shown' },
    { id: 3, name: 'Facebook', description: 'social network', visibility: 'hidden' },
  ],
};

Somewhere further down in the display layer is the output of this data, taking into account the flag. Technically, the problem is solved, but this storage method has significant drawbacks.

Let's start with the main point. Data on the frontend doesn't come from nowhere. Application data is stored on the server, comes from the server, and goes to the server. The server doesn't know anything about the appearance and nor should it, it's nothing to do with the data. And here is where a serious problem arises. If the UI state is stored inside the data, then there are two things you need to do all the time:

1. Introduce additional processing for all incoming data from the server, adding a UI-state there.
2. Introduce additional processing for all data going to the server, removing all UI states from it.

And there's usually more than one of these kinds of display elements. This includes modal window visibility, sorting, hiding/showing in all possible ways, different modes (editing), confirmations, and all sorts of other things. All of this will not only have to be stored within the data, but you'll also always have to constantly remember that additional processing is needed.

But that's not all. The data set is not handled uniformly, either. There may be a case where one data set is displayed in different places on the page, or is only partially displayed. This means that the UI state may be different for different elements, or some elements may not have it at all. What should we do in such a case? Should we ignore the differences and add the same data set to all of them, or should we complicate the logic and make it selective?

These problems mean that the UI state is stored separately from the data itself. And the data set will be different for each situation. For example, for an accordion, the state may look like this:

const state = {
  companies: [...],
  uiState: {
    accordion: [
      { companyId: 1, visibility: 'hidden' },
      { companyId: 2, visibility: 'shown' },
      { companyId: 3, visibility: 'hidden' },
    ],
  },
};

There are a few things we need to note:

1. companyId is needed to link to the data. The data itself isn't duplicated. We'll learn more about data structure in a future lesson.
2. UI states can be generated both during the application's operation and at the initialization stage when the application is launched. It depends on when which element appears.