Register to get access to free programming courses with interactive exercises

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.

Hexlet Experts

Are there any more questions? Ask them in the Discussion section.

The Hexlet support team or other students will answer you.

About Hexlet learning process

For full access to the course you need a professional subscription.

A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.

Get access
130
courses
1000
exercises
2000+
hours of theory
3200
tests

Sign up

Programming courses for beginners and experienced developers. Start training for free

  • 130 courses, 2000+ hours of theory
  • 1000 practical tasks in a browser
  • 360 000 students
By sending this form, you agree to our Personal Policy and Service Conditions

Our graduates work in companies:

<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.bookmate">Bookmate</span>
<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.healthsamurai">Healthsamurai</span>
<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.dualboot">Dualboot</span>
<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.abbyy">Abbyy</span>
Suggested learning programs

From a novice to a developer. Get a job or your money back!

Frontend Developer icon
Profession
beginner
Development of front-end components for web applications
start anytime 10 months

Use Hexlet to the fullest extent!

  • Ask questions about the lesson
  • Test your knowledge in quizzes
  • Practice in your browser
  • Track your progress

Sign up or sign in

By sending this form, you agree to our Personal Policy and Service Conditions
Toto Image

Ask questions if you want to discuss a theory or an exercise. Hexlet Support Team and experienced community members can help find answers and solve a problem.