About template engine 1, template engine

About template engine 1, template engine

 

The front-end template engine requires transparency during development.

Transparency means that after I build a development environment, I can refresh the browser with the handwritten code to see the latest results without executing any additional commands or waiting for any process.

Therefore, the template engine that relies on the compilation process is not suitable for front-end use. Compilation can only be a feature of the template engine, rather than a prerequisite for use.

More strictly speaking, using FileWatch and other methods for file change detection and automatic compilation is not under my consideration, because this will lead to additional waiting,

As a result, the front-end template engine should haveIt can be parsed and used in a pure frontend environment..

The front-end template engine must have good runtime debugging capabilities

Due to the uncertainty of user behavior, the uncertainty of the execution environment, and the impact of various third-party scripts, it is difficult for the front-end to completely handle and track errors, this also leads to a situation where the front-end must be directly online for troubleshooting.

When the problem occurs at the template engine layer, the template engine must provide good debugging capabilities.

Generally, the debugging capability of the compiled functions is weaker than that of the template fragments written manually, because the automatically generated functions are basically not readable and resumable tracing.

Therefore, A template engine for front-end use should have the mode of "retrieving HTML from the compiled function" and returning "parsing the original template and then executing the function to obtain HTML" under specific circumstances, that is, switch between the two modes should be supported.

Alternatively, a powerful front-end template engine can directly Map functions generated by compilation to original template fragments using Source Map or other custom means, however, no template engine has implemented this function.

The front-end template engine must be user-friendly for file merging.

Before the popularization of HTTP/2, file merging is still an important method in front-end performance optimization. templates, as part of files, still need to be merged.

In the template engine that provides the compilation function, we can use the compilation method to convert the Template into JavaScript source code, and then merge the files based on JavaScript.

However, if we want to retain the original template fragment for reasons such as the preceding debugging capability, the template engine itself needs to support merging template fragments into a file.

Most engines that only support parsing a piece of input string as a template do not have this capability. They naturally cannot split an entire string into multiple template fragments, therefore, file merging at the template fragment level is not supported.

The best way to support file merging is to make the template syntax based on "fragments ".

The front-end template engine takes XSS Protection

In terms of security, the front-end has strict requirements on XSS control.

The most suitable method for front-end XSS protection is to use the "Default escape" whitelist policy.

Based on this, a reasonable template engine isRequiredSupports default escape, that is, all data output is processed by the escape logic by default, and the key symbol is converted into the corresponding HTML Entity symbol to prevent the XSS intrusion path from the root cause.

Of course, not all content must be escaped. In the system, there is inevitably a need for rich text input by users. Therefore, it is necessary to support specific syntaxes to generate outputs without escape, however, note that no escape output is a special case. By default, it must be an escape output.

The front-end template engine must support fragment reuse.

This is not a requirement of the front-end template engine. In fact, any template engine should support fragment reuse. the backend such as Velocity and Smarty all have this function.
The so-called segment multiplexing should have the following layers of applications:

There are a lot of template engines that meet 1st and 2nd points, but the front-end template engines that meet 3rd points are rare. Razor and Smarty on the back end all have this function.

The front-end template engine must support data output processing.

The so-called data output processing refers to the extra conversion of a data during the output, the most common such as string trim operations, more technical such as markdown conversion.

It is true that data conversion can be completed through JavaScript logic before data is handed over to the template engine, but this will lead to a lot of ugly and redundant code, the reusability of the logic itself will also have a negative impact.

Generally, the template engine performs additional processing on data in the form of filters, similar to the pipeline logic in bash. The implementation and registration of filters will also have different designs. For example, mustache registers the fitler factory, while other template engines directly register the filter itself. Different designs have different considerations, it's hard to say who is good or bad

However, after the template engine supports data output processing, we will have a new tangle In the encoding process, that is, what data processing should be implemented by the filter of the template engine, which should be implemented by the logic before being handed over to the template engine. This topic is a long topic. If this topic is irrelevant, just skip it.

The front-end template engine must support dynamic data.

In the development process, a lot of data is not static. For example, EmberJS provides the concept of Computed Property, and Angular also has something similar, backbone can be implemented in disguise by overwriting the get method of the Model.

Although ES5 directly provides getter support at the language level, we still do not use this language feature in most frontend development scenarios, instead, it will choose to encapsulate dynamic data into get and other methods of an object.

The template engine should also pay attention to this point when converting data into HTML fragments, providing good support for these dynamic computing data.

To be more clear, the template engine should not only accept Plain objects as input, but should be more open to accept dynamic data similar to get methods.

A reasonable logic is that if an object has a get method (the template engine determines this interface), the data is obtained through this method, in other cases, the input Object is a pure Object (Plain Object) and the standard attribute is used to obtain the logic.

The front-end template engine should be closely integrated with the asynchronous Process

A common example is that we have an AMD module that stores global constants, which must be used by the template engine. Of course, we can allow JavaScript to obtain this module asynchronously before using the template engine, and then pass constants as data to the template engine. However, this is a method of coupling between business and views, out of obsessive-compulsive disorder, I don't think this is a beautiful design, so we hope

• The template output itself is an Asynchronous Method, instead of directly returning strings as it is now
• The analysis template is dependent on asynchronous operations, and the splicing logic of the entire string is interrupted into multiple asynchronous operations.
• Asynchronization requires waiting, and the waiting is unknown. In terms of performance, whether Stream output needs to be considered, in order to provide
• Whether to provide built-in fixed asynchronous logic or support any custom asynchronous Logic Based on Promise to balance complexity and Practicality

So far, I have not completely clarified the methods and interfaces for combining templates and Asynchronization. I cannot continue to discuss this topic in depth.

The front-end template engine must support different development modes

Since the development of the frontend, there are many different development modes, such:

• Use DOMContentLoaded and other events to add logic for the most common HTML page. Partial page refresh under a specific interaction
• Single-page development using traditional MVC Models
• Use MVVM to bind data to the view for development with data as the core
• Development of Data comparison with Diff to DOM update based on Immutable Data (the introduction of Virtual DOM may exist)

It is a great challenge for a template engine to support so many different models, especially the support for Bidirectional binding. So far, almost all development frameworks supporting two-way binding have built-in dedicated template engines, because two-way binding has two major requirements on templates:

• The metadata of "which data is dependent on this template" can be extracted from the template.
• The data change engine can know which part of the template is used instead of refreshing the entire template.

The general template engine rarely provides these two features, so it is impossible to fully support different front-end development modes.
From the implementation of the template engine itself, one method is to directly expose the AST-like structure after template parsing for other frameworks to handle it reasonably, at the same time, the partial template refresh function is provided (which can also be considered together with the template fragments mentioned above). However, most of the template engines provide performance considerations, it will not parse the syntax structure similar to AST.

The front-end template engine must be isolated between instances.

In large front-end projects, especially single-page projects, there will be templates with completely unknown numbers at the same time. If these fragments are named for reuse, it is easy to cause name conflicts.

For logic at the same level (for example, code at the business layer or code at the control layer), name conflicts can be solved through some development conventions. However, due to encapsulation requirements between different layers, the external should not know the names of some internally used fragments. If there is a name that conflicts with other layers unfortunately, this will make the situation more troublesome. Such problems are not even easy to track, which may lead to a large amount of energy and time waste.

Therefore, a good template engine should be multi-instance, and different instances should be isolated from each other, without such unexpected conflicts.

After studying this topic in depth, we will find that simple isolation is not enough. In addition to non-conflicting requirements between different layers, there is also a need for segment reuse, we also need to enable fixed fragment sharing between different template instances, therefore, the relationship between each instance of the template engine is a combination of dependencies, but it has the basic encapsulation and isolation status.