Loose coupling of UI layer in web development

This time I will bring you the loose coupling of the UI layer in web development. What are the precautions when using loose coupling of the UI layer in web development? Here are practical cases, let's take a look.

In web development, the UI is defined by three layers that are isolated and interact with each other.

HTML is used to define the data and semantics of the page

CSS is used to add styles to the page and create visual features

JS is used to add behavior to the page to make it more Interactivity

Allow me to say a few words about loose coupling. When you can modify one component without changing other components, you have loose coupling. For large multi-person systems, where many people are involved in maintaining the code, loose coupling is critical to code maintainability. You absolutely want developers to not break other people's code when they modify one part of the code. When the content of each component of a large system is limited, loose coupling is achieved. Essentially, each component needs to be kept thin enough to ensure loose coupling. The less known about the components, the better it is to form the overall system.

One thing to note: components working together cannot achieve "no coupling". In all systems, components share some information to do their jobs. It's easy to understand that our goal is to ensure that changes to one component do not regularly affect other parts.

If a Web UI is loosely coupled, it is easy to debug. Problems related to text or structure can be located by searching HTML. When a style-related problem occurs, you know the problem is in the CSS. Finally, for those behavioral issues, your ability to go directly to JS to find the problem is a core part of the maintainability of web interfaces.

In the WebPage era, we advocate the three-layer separation of HTML/CSS/JS. For example, it is forbidden to use the inline attribute of the DOM to bind the listener, onclick=handler>test< /button>Writing like this will get you sprayed. However, in the WebApp era, the MVVM and MVC frameworks represented by React (strictly speaking, React is just a framework focusing on the View layer), they all recommend that you write HTML, CSS and JS together, and you can often see to the code that binds the event listener inline.

You can’t help but wonder, are we going backwards?

History sometimes goes round and round. At first glance, I thought I was going back. In fact, the spiral has turned around and stood at a new starting point. ——Yu Bo "Evolution of Web R&D Model"

In the traditional WebPage era, the level of component support is not high, both at the language level and the framework level. Think about it, there is no JS that does not natively support modules (before ES6) era) and jQuery, so in order to avoid increasing maintenance costs, the best practice of three-layer separation is recommended. With the rise of ES6 and the front-end MV* framework, the entire front-end development model has changed. You will find that the front-end is not only writing pages, but also writing more WebApps. The scale and complexity of the applications are different from those in the WebPage era.

React is a very typical representative. It proposes to use JSX to write HTML, directly writing the page structure and page logic together. If this was placed in the WebPage era, I believe it would be directly regarded as a typical anti-pattern teaching material; but in the WebApp era, it is accepted and used by most people. Including CSS in JS proposed by the React team, they also want to write CSS in JS so that front-end development is completely dominated by JS and componentization is more thorough (I have not done in-depth research and understanding of CSS in JS, and there is no actual large-scale Practical experience in the project, so now I still maintain a wait-and-see attitude and continue to use the previous SASS and LESS for CSS development).

Although the development models of the two Web eras have undergone tremendous changes, there are still some general principles you need to follow regarding the three-layer loose coupling design:

Extract JS from CSS. Early IE8 and earlier browsers allowed writing JS in CSS (without writing examples, this is an anti-pattern, it’s better if you can’t remember it). This will cause performance problems, and what’s even more frightening is that it will be difficult to maintain in the future. . But I believe that none of you here will have access to this kind of code, which is fine.

Extract CSS from JS. It's not that you can't modify CSS in JS. It doesn't mean that you are not allowed to change the style directly. Instead, you can modify the style indirectly by modifying the class. See the following example:

// 不好的写法element.style.color = 'red';
element.style.left = '10px';
element.style.top = '100px';
element.style.visibility = 'visible';// 好的写法.reveal {  color: red;
  left: 10px;
  top: 100px;
  visibility: visible;
}
element.classList.add('.reveal');

Copy after login

Because the CSS className can become a communication bridge between CSS and JS. During the lifecycle of the page, JS can add and delete the className of the element at will. The style defined by className is in the CSS code. At any time, styles in CSS can be modified without having to update JS. JS should not manipulate styles directly in order to maintain loose coupling with CSS.

There is one situation where using the style attribute is acceptable: when you need to reposition an element on the page relative to another element or to the entire page. This calculation cannot be done in CSS, so you can use style.top, style.left, style.bottom and style.rght to correctly position the element. Define the default attributes of this element in CSS, and modify these default values ​​in Javascript.

In view of the current situation that HTML and JS have been written together on the front end, I will not talk about the practice of separating the two in the original book. But, having said all this nonsense, remember this: Predictability leads to faster testing and development, and knowing (rather than guessing) where to start debugging bugs will make the problem Solve faster and the overall quality of your code is higher.

I believe you have mastered the method after reading the case in this article. For more exciting information, please pay attention to other related articles on the php Chinese website!

Recommended reading:

How to use JS to pass by reference and pass by value

How to make a node.js interface

The above is the detailed content of Loose coupling of UI layer in web development. For more information, please follow other related articles on the PHP Chinese website!