JS: Frontend architecture
2026-02-21 02:50 Diff
https://hexlet.io/courses/js-frontend-architecture/lessons/rendering/theory_unit

State-based appearance updates are usually put in a separate layer called a view. In the simplest case, a view is a function that takes the state as input, analyzes it, and makes the necessary changes in the DOM.

An example of how render() can be arranged internally:

This approach can have performance issues because you need to constantly search the DOM for elements. To avoid this, you can turn a view into an object and only save the parts that you need once, during initialization.

As the application grows, so does the number of handlers. Each of them can only change part of the page. What should we do in such a case? Should you create a renderer for each situation or define all the possible changes in one render function?

The easiest solution would be to bind such functions to state elements. Suppose we have a page to manage a list of lessons in a course. In the state it looks like this:

The renderLessons() function is good for rendering this list, and it will be called in all the handlers that modify the list, either by deleting or adding items.

And the best part. What happens inside this function? It seems that inside the rendering function, you have to determine what happened and then change the necessary part of the DOM, for example, by removing some element that no longer exists. In reality, this is a very costly approach, it's difficult to program because you end up with a great many conditional constructs. It's easier to carry out the rendering again in any situation. Then the code will remain as simple as possible.

This approach has a serious disadvantage – performance. But make sure to keep two important points in mind. First, performance isn't always a problem. For example, if you need to implement autocomplete, this is exactly what you need to do. It will always work quickly. Second, this is precisely the problem that modern frontend frameworks solve. They themselves know how to update the DOM most efficiently.

Our application is now divided into three independent parts: state (application data), handlers, and rendering. This way of working with looks redundant with trivial applications (with only a few handlers), but if you have at least 10 handlers, you'll find that the application is quite convenient to work with. You can see the data flow, i.e., the movement of data from one part of the application to another, and from the handler to rendering in the DOM. You can always keep track of what has changed and how some parts of the application depend on others. It also reduces duplication. For example, state changes can come from different parts of the application, but the rendering logic remains the same. When the state needs to be changed, all you need to do is define a new way of changing an already existing state, and rendering will do the rest.

In addition to being divided into three parts, how they interact with each other is equally important:

  • The state doesn't know anything about the rest of the system – it's a core.
  • The rendering process itself naturally uses the state for rendering, and it adds new handlers to the DOM.
  • Handlers know about the state because they update it and initiate rendering.

This method of separation still has one important disadvantage, which we'll deal with in the lesson on MVC.