DEV Community: Kagol

Build a grayscale release environment from scratch

Kagol — Wed, 30 Jun 2021 14:38:39 +0000

Guide

Grayscale release, also known as canary release.

The term "canary" stems from the tradition of coal miners bringing caged canaries into mines. Miners use canaries to detect the concentration of carbon monoxide in the mine. The canaries would be poisoned by high concentration of carbon monoxide, in this case miners should evacute immediately. - DevOps Practice Guide

When we use "grayscale" or "canary" in software development. It refers to a small number of users' test before official release. So the problems can be detected earlier to prevent them from affecting most users.

Pipeline with grayscale release module is a very important tool and an efficient practice in DevOps, but I knew little about this when I was a student. After onboarding, I discovered the power of pipelines.

When faced with something new, it's an interesting path for us to get through all the key steps logically, and then complete a demo.

The article mainly focus on zero-to-one construction process practice rather then theoretical content, suitable for beginner front-end developers interested in engineering.

01 Server

Get a server

As mentioned above, the grayscale release requires a small number of users' test before official release.Therefore, we need to make sure that two groups of users can be divided to use different functions at the same time. So we need to prepare two servers, each with different code versions.

If you already have a server, you can emulate two servers by deploying services on different ports. If not, you can follow procedure below to purchase two cloud servers. The demo in this document will cost about 5 dollars on demand.

You can get a HUAWEI cloud server according to this: https://github.com/TerminatorSd/canaryUI/blob/master/HuaWeiCloudServer.md (written in Chinese)

Install tools

Git

First, make sure that git has been installed on your server. If not, run the following command to install it. After installation, generate an ssh public key and save it to your github, which is required for pulling code.

yum install git

Nginx

It is easy to install Nginx on Linux.

sudo yum install nginx

Run the command "nginx -t" on the terminal to check whether the installation is successful. If ok, it displays the status and location of the Nginx configuration file.

Then, run the command "nginx" or "nginx -s reload" to start Nginx. If the following Nginx processes are displayed, it indicates that Nginx is started successfully.

Open a browser and visit the public IP address of your server. If you can see a page like this, Nginx is working properly.

Jenkins

You may have many questions about Jenkins at first. Like what is Jenkins? What can Jenkins do? Why should I use Jenkins, etc. It's hard to say what Jenkins is, so just have a quick look at what Jenkins can do. Simply speaking, Jenkins can perform any operation on any server as you can. As long as you create a task on Jenkins in advance, specifing the task content and triggering time.
(1) Installation
Install the stable version: http://pkg.jenkins-ci.org/redhat-stable/

wget http://pkg.jenkins-ci.org/redhat-stable/jenkins-2.204.5-1.1.noarch.rpm
rpm -ivh jenkins-2.7.3-1.1.noarch.rpm

If the port used by Jenkins conflicts with other programs, edit the following file to modify the port:

// line 56 JENKINS_PORT
vi /etc/sysconfig/jenkins

(2) Start Jenkins

service jenkins start/stop/restart
// location of password
/var/lib/jenkins/secrets/initialAdminPassword

(3) Visit Jenkins
Access port 8080 of the server, enter the password obtained from the previous step, and click Continue.

Create an account and do login.

The Jenkins Ready page indicates this part has complete.

02 Code

Two copies of the code

We need to prepare two different pieces of code to verify whether the grayscale operation works. Here we choose Angular-CLI to create a project.

// install angular-cli
npm install -g @angular/cli
// create a new project, press enter all the way
ng new canaryDemo
cd canaryDemo
// after running this command, access http://localhost:4200 to view the page information
ng serve

Access port 4200 of localhost to view the page. The content will be refreshed in real time when we change the title of src/index.html in the root directory to A-CanaryDemo. In this example, we use title to distinguish the code to be deployed for different services during grayscale release.

Then, generate two packages. The titles of the two packages are A-CanaryDemo and B-CanaryDemo respectively. The two folders will be used as the old and new codes for grayscale release later.

ng build --prod

Config Nginx

At this point, the Nginx page is displayed when we access the IP address of the server. Now we want to access our own page, so we need to send the A-CanaryDemo package to certain location on the two servers. Here we put it in /var/canaryDemo.

// xxx stands for the ip of server
scp -r ./dist/A-CanaryDemo root@xx.xx.xx.xx:/var/canaryDemo

Go to the /var location on the server to see if the file already exists. If ok, modify the Nginx configuration to forward the request for accessing the server IP address to the uploaded page. As mentioned above, you can run the nginx -t command to view the location of the Nginx configuration file. In this step, you need to edit the file.

vi /etc/nginx/nginx.conf

Add the following information to lines 47 to 50. The traffic destined for the server IP address is forwarded to the index.html file in /var/canaryDemo.

Save the modification and exit. Reload Nginx.

nginx -s reload

When you access the IP address of the server, you can see that the page has changed to the one we have just modified locally and the title is A-CanaryDemo. After the operations on both servers are complete, the page whose title is A-CanaryDemo can be accessed on both servers. Just like two machines that are already providing stable services in the production environment.

03 Defining a Grayscale Policy

In this part, we need to define a grayscale policy, describing the traffic will be routed to grayscale side or normal side.
For simplicity, a cookie named canary is used to distinguish between them. If the value of this cookie is devui, the grayscale edge machine is accessed; otherwise, the normal edge machine is accessed. The Nginx configuration result is as follows. In this example, 11.11.11.11 and 22.22.22.22 are the IP addresses of the two servers.

# Canary Deployment
map $COOKIE_canary $group {
# canary account
~*devui$ server_canary;
default server_default;
}

upstream server_canary {
# IP addresses of the two hosts. The port number of the first host is set to 8000 to prevent an infinite loop in Nginx forwarding.
server 11.11.11.11:8000 weight=1 max_fails=1 fail_timeout=30s;
server 22.22.22.22 weight=1 max_fails=1 fail_timeout=30s;
}

upstream server_default {
server 11.11.11.11:8000 weight=2 max_fails=1 fail_timeout=30s;
server 22.22.22.22 weight=2 max_fails=1 fail_timeout=30s;
}

# Correspondingly, configure a forwarding rule for port 8000, which is disabled by default, you need to add port 8000 to the ECS console security group
server {
listen 8000;
server_name _;
root /var/canaryDemo;

# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;

location / {
root /var/canaryDemo;
index index.html;
}
}

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
# root /usr/share/nginx/html;
root /var/canaryDemo;

# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;

location / {
proxy_pass http://$group;
# root /var/canaryDemo;
# index index.html;
}

error_page 404 /404.html;
location = /40x.html {
}

error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}

In this case, both grayscale traffic and normal traffic are randomly assigned to machines on sides of A and B. After this, we need to create a Jenkins task to modify the Nginx file to implement grayscale release.

04 Grayscale Release

Step Analysis

Before creating a Jenkins task for grayscale release, let's sort out which tasks are required to achieve grayscale release and what each task is responsible for. Grayscale release generally follows this steps. (Assume that we have two servers AB that provide services for the production environment, which we call AB Edge):
(1) Deploy new code to side A.
(2) A small portion of traffic that meets the grayscale policy is switched to side A, and most of the remaining traffic is still forwarded to side B.
(3) Manually verify whether the function of side A is ok.
(4) After the verification, most traffic is transferred to side A and grayscale traffic is transferred to side B.
(5) Manually verify whether the function of side B is ok.
(6) After the verification, the traffic is evenly distributed to side A and side B as usual.

Tasks Analysis

Based on the preceding analysis, we obtain the six steps of grayscale release, where (3) and (5) require manual verification. Therefore, we use the two tasks as the partition point to create three Jenkins tasks (Jenkins tasks are established on the A-side machine) as follows:
(1) Canary_A. This task includes two parts. Update the code of side A and modify the traffic distribution policy so that grayscale traffic reaches A and other traffic reaches B.
(2) Canary_AB . The code of side B is updated. The grayscale traffic reaches B and other traffic reaches A.
(3) Canary_B: All traffic is evenly distributed to A and B.

Create Tasks

Create three Jenkins tasks of the FreeStyle type. Remember to use English names. It is difficult to create folders later with Chinese. Do not need to enter the task details, just save it. Then, we will config the detailed information about each task.

Config tasks

Click to enter each task and excute an empty build (Otherwise, the modified build task may fail to be started.) , and then we will config each task in detail.

Front-end projects need to be built and packaged. However, the low-cost 1-core 2 GB ECSs are unable to complete this step. Therefore, the generated production package is managed by Git. Each code update synchronizes the latest production package to GitHub. The Jenkins task pulls down the production package and places it in a specified location to complete deployment.

Now, config grayscale test A. As described above, we need to associate the task with the remote github repository. The github repository to be associated needs to be manually created to store the packaged B-CanaryDemo whic is named dist.

Run the build task command once. (The git fetch step is unstable and sometimes takes a long time) . Click into this build to view the Console Output. You can find that the Jenkins task is executed at /var/lib/jenkins/workspace/Canary_A on the server.

Continue to edit the grayscale test task A and add the build shell, including the command to be executed each time the task is executed.
(1) Pull the latest code first.
(2) Copy the dist directory in the root directory to the location where the code is deployed. In this article, the specified location is /var/canaryDemo.
(3) Modify the Nginx configuration so that grayscale traffic reach side A.
In step (3), the way of modifying the grayscale traffic is to selectively comment out content in the Nginx configuration file. A grayscale test A can be implemented as follows:

upstream server_canary {
# grayscale traffic reach side A
server 11.11.11.11:8080 weight=1 max_fails=1 fail_timeout=30s;
# server 22.22.22.22 weight=1 max_fails=1 fail_timeout=30s;
}

upstream server_default {
# normal traffic reach side B. To distinguish the configuration of this section from the server_canary configuration, set the weight to 2
# server 11.11.11.11:8080 weight=2 max_fails=1 fail_timeout=30s;
server 22.22.22.22 weight=2 max_fails=1 fail_timeout=30s;
}

User jenkins does not have sufficient permissions to execute commands. You can log in to the system as user root and change the ownership of the /var directory to user jenkins. Also remember to add the write permission on the /etc/nginx/ngix.conf file. The resulting shell command is as follows:

git pull
rm -rf /var/canaryDemo
scp -r dist /var/canaryDemo
sed -i 's/server 22.22.22.22 weight=1/# server 22.22.22.22 weight=1/' /etc/nginx/nginx.conf
sed -i 's/server 11.11.11.11:8000 weight=2/# server 11.11.11.11:8000 weight=2/' /etc/nginx/nginx.conf
nginx -s reload

Then, the grayscale test task A and grayscale test task B are configured in sequence.
The task of grayscale test B is to pull the latest code to side A. (Because our Jenkins tasks are based on side A) Copy the code in dist to the specified access location of Nginx on side B, and modify the Nginx configuration on side A so that grayscale traffic reaches side B.

git pull
rm -rf canaryDemo
mv dist canaryDemo
scp -r canaryDemo root@xx.xx.xx.xx:/var
sed -i 's/# server 22.22.22.22 weight=1/server 22.22.22.22 weight=1/' /etc/nginx/nginx.conf
sed -i 's/# server 11.11.11.11:8000 weight=2/server 11.11.11.11:8000 weight=2/' /etc/nginx/nginx.conf
sed -i 's/server 22.22.22.22 weight=2/# server 22.22.22.22 weight=2/' /etc/nginx/nginx.conf
sed -i 's/server 11.11.11.11:8000 weight=1/# server 11.11.11.11:8000 weight=1/' /etc/nginx/nginx.conf
nginx -s reload
The task in this step involves sending code from the A-side server to the B-side server, which generally requires the password of the B-side server. To implement password-free sending, you need to add the content in ~/.ssh/id_rsa.pub on server A to ~/.ssh/authorized_keys on server B.
When B goes online, the Nginx configuration on side A is uncommented so that all traffic is evenly distributed to side A and side B.
sed -i 's/# server 22.22.22.22 weight=2/server 22.22.22.22 weight=2/' /etc/nginx/nginx.conf
sed -i 's/# server 11.11.11.11:8000 weight=1/server 11.11.11.11:8000 weight=1/' /etc/nginx/nginx.conf
nginx -s reload

At this point, we have built a grayscale release environment from zero to one. After the code is updated, you can manually execute Jenkins tasks to implement grayscale deployment and manual tests to ensure smooth rollout of new functions.

Conclusion

The article introduces the necessary process of building a grayscale release environment from four aspects: server preparation, code preparation, grayscale policy formulation and implementation. The core of grayscale release is to distribute traffic by modifying Nginx config files. The content is quite simple, but the whole process from zero to one is rather cumbersome.

In addition, this demo is only the simplest one. In the real DevOps development process, other operations such as compilation and build, code check, security scanning, and automated test cases need to be integrated.

DevUI Admin V1.0 Released!!!🎉🎉🥳

Kagol — Fri, 30 Apr 2021 03:38:03 +0000

At the end of April, DevUI Admin, with widely expectation, comes to the first open source version(1.0.0) of Angular.

DevUI Admin is an enterprise-level middle and back-end frontend/design solution. Based on DevUI Design, we build a back-end management template based on our own design specifications and basic components.

After several months of incubation, DevUI Admin provides you a solution for building a front-end system that can be used in middle and back end:

Responsive: adapts to different screen sizes to provide users a more comfortable interface and user experience.
Personalized Theme: supports dynamic switching between multiple theme styles and personalized settings.
Layout Switching: the page layout is configurable and flexible.
Internationalization: implements the internationalization to meet the requirements of multi-language.
Mock data: local data debugging and a separation between front-end and back-end;
Page templates: Based on DevUI practice and experience, typical business scenarios are extracted and various page templates are provided.

You can learn more at devui.design or follow DevUI Admin on GitHub.

Preview page: https://devui.design/admin/
Homepage: https://devui.design/admin-page/home
GitHub: https://github.com/DevCloudFE/ng-devui-admin
DevUI Design: https://devui.design/home

Responsive

DevUI Admin provides a grid-based responsive solution. After initializing an Admin project, you will obtain the page responsive capability. More importantly, we also provide da-grid as a common component that you can use for responsive page building.

Personalized Theme

Based on basic ng-devui capabilities, the DevUI Admin provides multiple themes for users to select. In addition to global color matching, font size and fillet size can be configured too. Users can select a theme based on their personal preferences.

Switch the layout.

DevUI Admin supports multiple layouts. You can customize layout settings by simply modifying your layout config. More importantly, we provide da-layout as a component that you can also use to extend more layout configurations.

Internationalization

DevUI Admin uses @ngx-translate/core to implement the internationalization. Internationalization-related words support modular management. You can select the corresponding internationalization configuration after initializing your Admin project.

Mock data

Mock data is very important to separate front-end and back-end, so that front-end projects are not affected by back-end interfaces. In DevUI Admin, we have provided you with the method of Mock data. You can select the data Mock support by default when initializing your Admin project.

Page Template

In the DevUI Admin GitHub code repository, we provide you with multiple page templates by default.

- Dashboard
  - Analysis Page
  - Monitoring page
  - Workbench
- Form page
  - Base Form
  - Form Layout
  - Advanced Forms
- List Page
  - Base List
  - Card list
  - Edit List
  - Advanced List
  - Tree List
- Exception page
  - 403
  - 404
  - 500
- Personal page
  - Personal Center
  - Personal settings

You can take a look to it after pulling the code from github.

Cli Support

Currently, the DevUI Admin can use the Angular CLI to initialize an admin project. You can use the Angular CLI to quickly create and configure your admin project.

# Initialize the project.
$ ng new your-project && cd your-project
$ ng add ng-devui-admin

Follow-up

In the future, we will keep envolving, focusing on performance and usability, optimizing the experience of DevUI Admin, and reducing developer costs. We look forward to receiving your comments and suggestions (Issue List). We also look forward to your participation and cooperation.

Flame Pie Under a Waterfall: Three Steps to Quickly Locate Performance Problems on Your Website

Kagol — Thu, 15 Apr 2021 11:00:47 +0000

The introduction

Performance is an issue.

When every project grows to a certain scale, it is almost inevitable to encounter performance problems. When encountering performance problems, we are:

With a dumb face, I know it’s stuck and slow, I don’t know why.

Or:

Can quickly insight into performance bottlenecks and find effective optimization solutions.

It depends on our understanding of performance and whether we have a good set of tools and methods.

Next, I will share with you the three-step method that I often use when locating business performance problems. In order to facilitate memory, I will summarize it in one sentence:

Flame pie under a waterfall.

Not much to say, just drink a mouthful of water!

Introduction to the Performance panel

Before introducing the three-step method, let's briefly understand the Performance panel of Chrome Developer Tools and the basic composition of the performance analysis report.

Generate performance analysis report

Take the juejin personal homepage of the DevUI team as an example, use the Chrome browser to access: https://juejin.cn/user/712139267650141

Then press F12 to open Chrome's developer tools and select the Performance panel.

At this time we will see a simple guide:

There are two buttons in the guide. The upper button is for manual recording, and the lower is for automatic recording. We click on the fool-like automatic recording, and the automatic recording will automatically refresh the page. After the page is loaded, a performance analysis report of the page is generated. Manual intervention is very convenient.

The report will be generated after a few seconds. At a glance, it is colorful. I don't know where to start?

Composition of performance report

We do a simple panel classification of the generated performance analysis report, and it looks very clear.

Toolbar

At the top of the performance report is a toolbar (or control panel) with a bunch of buttons. The first three that I use more often are the first three. The first two have been introduced in the guidelines, and the third is for use. To clear the report.

There are also two hidden functions that are also very useful. One is to simulate a slow network speed, and the other is to simulate a slow CPU, which may be used for performance optimization of mobile applications.

Overview panel

Below the toolbar is an overview panel that displays the FPS (Frames Per Second) during the entire page loading process, which is used to evaluate the smoothness of the page. A large red area indicates that the page may be stuck.

Below the FPS is the time spent by the CPU to process each task, and further down is the time consumed by the network request. At the bottom of the overview panel is a screenshot of each frame.

Thread panel

Below the overview panel is the thread panel. The network request waterfall chart is expanded by default, and the details of other threads are collapsed.

Each thread panel is valuable for performance analysis, and the waterfall chart and flame chart are the most commonly used ones. I will focus on these two charts later. How to use these two charts to analyze the performance bottleneck of the website.

Memory panel

Next is the memory panel. The memory panel needs to be opened manually in the control panel. It is a categorized line graph of memory occupancy.

Each polyline is the memory usage of a task over time:

JS stack
Documentation
HTML node
Event monitoring
GPU memory

Details panel

At the bottom is the details panel. The first thing you see is a pie chart. This pie chart shows the proportion of various types of tasks. This is very useful. Can you see at a glance what type of task is the performance bottleneck.

Is it resource loading or script execution? Is it page rendering or image drawing? Or is the idle time too long?

Step 1: Look at the pie chart

When I introduced the composition of the Performance panel just now, I mentioned 3 very useful performance analysis tools, namely the detailed pie chart, the request waterfall chart, and the main thread flame chart.

I sum up these three pictures into one sentence:

Flame pie under a waterfall.

This sentence is also a trick that I have tried and tested in performance analysis and optimization myself.

The pie chart in the details panel is used to display the time-consuming proportions of various types of tasks.

There are mainly the following tasks:

Blue is resource loading
Yellow is script execution
Purple is page rendering
Green is the drawing
White is free time

Let's take the example just now.

It can be seen from the pie chart that script execution and idleness accounted for the most.

The script execution time is long, we can probably guess that there may be a long task (Long task);

And the idle ratio may be too long to wait for the server's response time.

The pie chart can quickly form a basic judgment, and the specific reasons need to analyze the waterfall chart and the flame chart.

Step 2: Look at the waterfall chart

Let's take a look at the request waterfall chart. Both the waterfall chart and the flame chart are part of the thread panel. The horizontal axis of the waterfall chart is the time axis. There are many colorful color blocks on the waterfall chart. These color blocks are the request blocks. Each color represents One type of resource:

Blue is the HTML file
Purple is the CSS file
Yellow is the JavaScript file
Green is the picture
Gray is the background interface

We mainly focus on those long color blocks. Long color blocks mean time-consuming and may be a performance bottleneck.

Let's look at the waterfall chart on the juejin' personal homepage.

Summarize the characteristics of the waterfall chart

Let's observe the characteristics of this picture first, and the ability to observe graphics. I believe you have already cultivated it in elementary school. Generally, we can summarize the following more obvious characteristics:

Feature 1: The big waterfall is divided into three small waterfalls
Feature 2: The small waterfall on the far left is mostly yellow blocks, the small waterfall in the middle is mostly gray blocks, and the small waterfall on the far right is mostly green blocks.
Feature 3: There is a gap between the first two waterfalls, and there is no color block in the middle
Feature 4: The last two waterfalls are connected together by a "tail" of a gray block
Feature 5: There is an extra-long gray color block on the top

We can summarize many similar characteristics, but what do these characteristics indicate? Can you help us locate performance bottlenecks?

Answering these questions requires us to have a lot of understanding of the waterfall chart and the principle of the browser. Let's analyze it step by step.

Analyze the meaning of the waterfall chart

We analyze in the order from left to right and top to bottom. There are two color blocks on the far left, a gray color block and a blue color block. We click on these two color blocks respectively, and look at their details in the details panel. Detailed information.

Look at the gray color block first

We have noticed that the initiator of this request is a Chrome plug-in: chrome://new-tab-page/omnibox.mojom-lite.js

So we don’t pay attention, and then look at the blue color block

As we have already introduced, the blue color blocks represent HTML files. We can also verify this from the Mime Type of the details as text/html.

We scroll the mouse wheel to enlarge the waterfall chart and see the details of the blue request block

The composition of the request block

By looking at the detailed map, we have new discoveries:

Each request block consists of four parts:

Left line: represents the time before the request is sent (Before Request Sent)
Light-colored block: represents the request has been sent (Request Sent), until the server returns the first byte to the browser (TTFB, Time to First Byte)
Dark block: all the content returned by the server is downloaded to the browser (Content Download)
Right line: Waiting for main thread

This HTML file is the starting point for the rendering of the entire web page. After successfully requesting and downloading this file, there will be the next story.

The light-colored part of this request block accounts for a relatively large proportion. According to the previous introduction, the light-colored part represents the response speed of the server. The browser has sent the request early, but the server responded late (the first word Section arrives in the browser).

In the middle, the network may be slow, or the server processing speed may be slow, which requires specific investigation. After all, this HTML file is not too big, only 111KBb, but it took 179ms.

Compared with another file, layouts.default.js, which is 124KB larger than it, the request time is more than half shorter than it, only 74ms. (Later it was found that this data is unstable, this HTML file should not constitute a performance bottleneck)

In addition, all subsequent requests depend on this HTML, and other requests will not happen without it. It is a blocking request and performance must be guaranteed.

Discover possible performance bottlenecks

Let's continue to look at the request block on the right. The long gray block at the top is still a request for the Chrome plug-in. Let's ignore it. Look at the pile of yellow request blocks below. These are JavaScript files.

After the HTML file is downloaded, it will start to parse the HTML tags line by line. When encountering the <script> tag with the src attribute and who is set, it will download the JavaScript script file specified by src.

It can be seen from the waterfall chart that a total of 8 JavaScript files have been downloaded in parallel, and their domain names are all the same: sf1-scmcdn2-tos.pstatp.com

Doesn't it mean that the maximum number of concurrent requests for the same domain name in Chrome is 6?

Not only JavaScript files, but there are also 3 image resources with the same domain name below, which are also requested in parallel, which means that 11 requests are initiated almost simultaneously.

This means:

The static resource server of juejin has been upgraded to HTTP/2.

HTTP/2 multiplexing can realize a TCP connection to transmit multiple resources at the same time.

We went to the Network panel to see the details of these JavaScript requests, and it was exactly the same as we guessed. We must give the juejin a thumbs up for this👍.

Send a comparison chart between a certain 86 website and the juejin, let’s get a feel for it

An 86 website:

juejin:

Although the former is more like a waterfall, I like the silky experience of the latter.

Let's take a closer look at these 8 requests. I believe that you must have discovered a phenomenon in detail:

What they have in common, except for the domain name just mentioned, the left and right lines of these request blocks are very short
There are three very long request blocks, 1/5/8 respectively, which require special attention

It is a good phenomenon that the left and right lines of the request block are very short, indicating that there is no waiting time, and all the time is spent on transmitting data.

We click on the 1/5/8 request block to see their details

Request block	Details
1	Size: 4KB Time consuming: 635ms
5	Size: 90KB Time consuming: 635ms
8	Size: 3.9MB Time consuming: 633ms

This is very strange. 1/5 of the resource size and 8 are not in the same order of magnitude, but it takes more time than 8.

In order to determine whether this was accidental or inevitable, I recorded the performance report of this juejin personal homepage twice.

This time it is basically the same as expected. 8 takes longer than the others. This JavaScript file is 3.9MB, which is too big and may be a performance bottleneck.

Others

Let us continue to analyze, there are three color blocks under the yellow JavaScript color block:

Purple: CSS style file
Green: Picture file
Gray: font file (189KB in size)

These files are not large in size, and after generating performance reports many times, it is found that these requests are not as long as the eighth JavaScript file, so it is preliminary judged that these requests do not constitute a performance bottleneck.

Then look at the middle waterfall. After generating performance reports several times, I found that the middle waterfall does not have any particularly time-consuming requests, but no matter how many reports are generated, one thing is certain, that is

There is always a gap between these three waterfalls

What do these blanks show?

After reading the flame map, I believe you will suddenly be enlightened.

Step 3: Look at the flame graph

Before looking at the official flame diagram, let’s take a look at the effect of a waterfall diagram and a flame diagram together.

After reading this comparison picture of waterfall and flame, you must have seen a phenomenon

If there are blank places in the waterfall chart, the flame chart will have colors;
Where the waterfall chart has colors, the flame chart is blank.

But Why?

To answer this question, you need to understand the principle of the browser's main thread to perform tasks, and what the flame graph does. Don't worry, let's analyze it step by step.

What is the flame graph

The flame graph is also part of the thread panel, which represents the task flow of the browser's main thread:

As the page loads and time goes by, what does the main thread do in turn

The horizontal axis of the flame graph is time, and the vertical axis is each macro task.

There are several micro tasks under each macro task, and there may be many sub tasks under each micro task, and so on.

Because some tasks have a deep nesting level and some have a shallow nesting level, they appear to be inverted flames.

The color of each type of task is different (no need to remember, just have a general impression):

Parse HTML Parse HTML: blue
Parse Stylesheet: Blue
Evaluate Script: yellow
Recalculate Style: dark purple
Paint: dark green
Perform microtasks Microtasks: yellow
Ajax request XHR Load: yellow
Function Call: Yellow
Trigger the timer Timer Fired: yellow

Let’s take a look at the flame map of the juejin’ personal homepage.

Summarize the characteristics of the flame graph

Then use the skills of look at pictures and find patterns that we learned in elementary school to find out the characteristics of this picture, and at a glance, we can summarize at least the following characteristics:

Feature 1: Generally speaking, there are blanks on both sides, with three big flames in the middle
Feature 2: The two big flames on both sides correspond to the two blanks in the waterfall chart (this explains why there are blanks between the three small waterfalls in the waterfall chart)
Feature 3: Some macro tasks are particularly long, and the background color is a red hatching line (not gray), and there is a small red triangle in the upper right corner

Spend more time, maybe we can find more, but these are the most obvious.

In order to answer these questions, we need to observe the flame diagram at close range.

Analyze the meaning of the flame graph

Since the flame graph represents what the main thread is doing at each point in time, the blank naturally means that the main thread is not doing work, so what is it doing?

It's waiting

What are you waiting for?

Wait for the server to return some necessary resources and data

and so

The blank space of the flame graph is that the browser is waiting for the server to return data

Looking for long tasks

Among all the tasks performed by the main thread, we especially need to pay attention to those long tasks that take a long time (Long tasks). The characteristics of these long tasks have been mentioned earlier:

The background color is a red shaded line
There is a small red triangle in the upper right corner

Three long tasks were found in 1s

Analyze long tasks

The next step is to analyze long tasks and find specific modules/components/methods that take a long time.

Let's zoom in on the largest flame on the far right to see what secrets are inside.

After zooming in, we quickly discovered that this long task that took 591ms, 90% of the time was spent on a method called init, this method was executed a total of 6 times, of which 3/4/6 time-consuming Especially long

The nth init method	Details
3	Time consuming: 197ms
4	Time consuming: 93ms
6	Time consuming: 111ms

What exactly does this init method do?

It may be hung in the Vue component. Could it be that some of the components are particularly large and the logic inside is too complicated. Here we need the front-end of juejin to give the answer.

Look at the second largest flame on the left, and scroll the mouse wheel to enlarge it

We found that one of the forEach loops was particularly time-consuming. This loop seemed to be calculating something and took 150ms in total.

This still needs to look at the specific source code to find the root cause of the problem.

Cases of finding performance bottlenecks through flame graphs

Finally, I will share with you a performance problem of a dependent library that I found in the XBoard Kanban project through the flame graph.

Follow the same idea:

Find long tasks
Enlarge the flame map of the long mission
Look down layer by layer until you find a time-consuming method with a name (most of the code on the live network is compressed and confused, and the name is not visible, the development environment will be more convenient to locate the method with performance problems)
Click this method in the flame chart, see the link after Function in the details panel, click this link to jump directly to the specified method in the corresponding file
Search the method name in the source code and find it
Find a solution

At the time, there were a lot of long tasks on the XBoard board page, I found TOP3 among them

Then I zoomed in on the first long task, and I quickly gained a reward. I found that there is a method called drawQrCode that takes a long time, and it took 192ms in total.

Then, by looking at the details, I found that this is a method of relying on a library. The dependent library defines a drawQrCode to draw a QR code. This QR code is actually not on the Kanban page, but needs to be hovered to a button by the mouse. Just load it out.

So the solution at that time was to delay the execution of the drawQrCode method, namely:

When the home page is loaded, the drawQrCode method is not executed, and only executed when the mouse is moved to the corresponding button.

The relationship between waterfall graph and flame graph

The waterfall chart and the flame chart are mutually complementary and mutually verifying.

The waterfall chart represents that the browser initiates a request to the server, and then the browser executes the corresponding logic and page rendering through the script according to the data returned by the server.

When the waterfall chart has a request block, it means that the browser is requesting data from the server. If the browser must rely on this data to do the next page rendering, it is likely that the browser will have nothing to do before the server returns the data, and then the flame chart If there is a blank on the pie chart, Idle will also appear on the pie chart.

When the browser gets the data returned by the server, the main thread is processing the data and rendering the page, so it is very likely that it will not be able to send a request to the server, and the waterfall chart will appear blank at this time.

and so

It is found that the waterfall chart is blank, and there may be a long task. It is necessary to find a specific time-consuming method and optimize it

It is found that the flame graph is blank. It is likely that some background interfaces are slow or there are very large static resources. You need to locate the reason for the slowness and find a way to optimize it.

Summary

This article first briefly introduces how to generate a website performance analysis report, as well as the general composition of this report;

Then I will share with you the three-step method I often use when locating business performance problems: using flame scones under the waterfall;

From the pie chart, we can have a general understanding of the performance of the website. From the waterfall chart, we can quickly find slow interfaces and large resources. From the flame chart, we can get a detailed insight into which module/component/method is possible. Become a performance bottleneck.

Finally, I recommend Google's official performance evaluation guide: https://developers.google.com/web/tools/chrome-devtools/evaluate-performance

About DevUI team

DevUI is a team with both design and engineering perspectives, serving for the DevCloud platform of Huawei Cloud and several internal middle and background systems of Huawei, serving designers and front-end engineers.

Official website: devui.design

Ng component library: ng-devui (Welcome to star🌟)

How does Quill convert Delta to DOM? 3/10

Kagol — Sun, 11 Apr 2021 23:53:21 +0000

The introduction

In the last post, we showed how Quill uses Delta to describe editor content and its variations. We learned that Delta is just a normal JSON structure with only three actions and one attribute, but it is extremely expressive.

So how does Quill apply Delta data and render it into the editor?

How to use setContents

There is an API in Quill called setContents that renders Delta data into the editor. This post will focus on how this API is implemented.

Take the Delta data from the previous post as an example:

const delta = { "ops": [
    { "insert": "Hello " },
    { "insert": "World", "attributes": { "bold": true } },
    { "insert": "\n" } ]
}

Once we have created an instance of Quill using new Quill(), we can call its API.

const quill = new Quill('#editor', {
  theme: 'snow'
});

Let's try calling the setContents method, passing in the Delta data we just had:

quill.setContents(delta);

The expected formatted text appears in the editor:

Deep into setContents

By looking at the source of setContents, we call the modify method, passing in a function:

setContents(delta, source = Emitter.sources.API) {
  return modify.call( this, () => {
    delta = new Delta(delta);
    const length = this.getLength();
    const deleted = this.editor.deleteText(0, length);
    const applied = this.editor.applyDelta(delta);
    ... // The non-core code is omitted for ease of reading
    return deleted.compose(applied);
  }, source, );
}

The call method is used to call modify to change its internal this pointer, which refers to the current Quill instance. Since the modify method is not defined in the Quill class, it needs to be done.

Let's look at the anonymous function passed in the modify method instead of the modify method.

This function does three main things:

Delete all the original content in the editor
Apply the incoming Delta data and render it to the editor
Returns the Delta data after combining 1 and 2

Let's focus on step 2, which involves the applyDelta method of the Editor class.

How the applyDelta method works

As you might guess by its name, the purpose of this method is to apply and render the incoming Delta data into the editor.
The implementation, as we can probably guess, is that the ops array in the loop Delta is applied to the editor one by one.
Its source code is 54 lines long and looks something like this:

applyDelta(delta) {
  let consumeNextNewline = false;
  this.scroll.update();
  let scrollLength = this.scroll.length();
  this.scroll.batchStart();
  const normalizedDelta = normalizeDelta(delta);

  normalizedDelta.reduce((index, op) => {
    const length = op.retain || op.delete || op.insert.length || 1;
    let attributes = op.attributes || {};
    // 1.Insert text
    if (op.insert != null) {
      if (typeof op.insert === 'string') {
        // Plain text content
        let text = op.insert;
        ... // For ease of reading, omit non-core code
        this.scroll.insertAt(index, text);
        ... // For ease of reading, omit non-core code
      } else if (typeof op.insert === 'object') {
        // Rich text content
        const key = Object.keys(op.insert)[0];
        // There should only be one key
        if (key == null) return index;
        this.scroll.insertAt(index, key, op.insert[key]);
      }
      scrollLength += length;
    }
    // 2.Formatting the text
    Object.keys(attributes).forEach(name => {
      this.scroll.formatAt(index, length, name, attributes[name]);
    });
    return index + length;
  }, 0);
  ... // For ease of reading, omit non-core code
  this.scroll.batchEnd();
  this.scroll.optimize();
  return this.update(normalizedDelta);
}

As we guessed, this method is to use the Delta reduce method to iterate over the incoming Delta data, separating the logic of content insertion and content deletion. The iteration of content insertion mainly does two things:

To insert plain text or rich text content: insertAt
Formats the text: formatAt

At this point, we have parsed the logic to apply and render the Delta data to the editor.

Summary

Here's a summary:

There's no logic in the setContents method itself, it just calls the modify method, right
The applyDelta method on the Editor object is called in the anonymous function passed to the modify method
The applyDelta method iterates over the incoming Delta data and in turn inserts/formats/deletes the editor content described by the Delta data

About DevUI team

Official website: devui.design

Ng component library: ng-devui (Welcome to star🌟)

by Kagol

How does Quill describe editor content? 2/10

Kagol — Tue, 06 Apr 2021 23:25:07 +0000

The introduction

In the last post, we introduced how the Quill module works. This time, let's talk about the data model of Quill and see how Quill describes the content in the editor.

You will be surprised by the simplicity and expressive power of the data structure of the Delta.

Quill profile

Quill is an API-driven, easily extensible, and cross-platform modern Web rich text editor. At present, the number of Star on GitHub has exceeded 25K.

Quill is also very easy to use, creating a basic editor in just a few lines of code:

<script>
  var quill = new Quill('#editor', {
    theme: 'snow'
  });
</script>

How does Quill describe formatted text?

Let's start with the simplest case: formatted text.

When we insert some formatted content into the editor, the traditional approach is to insert the corresponding DOM directly into the editor, and compare the DOM tree to record the changes.

There are a number of inconveniences associated with working directly with the DOM, such as the difficulty of knowing exactly what format certain characters or content are in in the editor, especially for custom rich text formats.

Quill puts a layer of abstraction on top of the DOM, using a very neat data structure to describe the contents of the editor and its changes: Delta.

Delta is a subset of JSON that contains only one ops attribute, whose value is an array of objects, each of which represents an operation on the editor (based on the initial state of the editor being null).

For example, there is "Hello World" in the editor:

Described by Delta as follows:

{
  "ops": [
    { "insert": "Hello " },
    { "insert": "World", "attributes": { "bold": true } },
    { "insert": "\n" }
  ]
}

The meaning is obvious: insert "Hello "in the empty editor, insert a bold "World" after the previous operation, and finally insert a newline "\n".

How does Quill describe changes in content?

Delta is very concise, but very expressive.

It has only three actions and one attribute, which is enough to describe any rich text content and any variation in content.

3 actions:

insert
retain
delete

1 attribute:

attributes

For example, if we change the bold "World" to the red text "World", this action is described by Delta:

{
  "ops": [
    { "retain": 6 },
    { "retain": 5, "attributes": { "color": "#ff0000" } }
  ]
}

It means: keep the first six characters of the editor, that is, leave "Hello " intact and the next five characters "World", and set "World" to the font color "#FF0000".

If you wanted to delete the word "World", I'm sure you can guess how to use Delta, and yes you can:

{
  "ops": [
    { "retain": 6 },
    { "delete": 5 }
  ]
}

How does Quill describe rich text content?

The most common type of rich text is an image. How does Quill use Delta to describe an image?

In addition to a string format that describes ordinary characters, the insert attribute can also be an object format that describes rich text content, such as an image:

{
  "ops": [
    { "insert": { "image": "https://quilljs.com/assets/images/logo.svg" } },
    { "insert": "\n" }
  ]
}

Take the formula:

{
  "ops": [
    { "insert": { "formula": "e=mc^2" } },
    { "insert": "\n" }
  ]
}

Quill offers great flexibility and extensibility to customize rich text content and formats such as slides, mind maps, and even 3D models.

If you're excited to create your own custom editor content, don't be anxious. In the future post, I'll take you through the inner workings of Quill and help you create your own custom content and custom modules.

Expect it!🎉🎉

About DevUI team

Official website: devui.design

Ng component library: ng-devui (Welcome to star🌟)

by Kagol

To be continued...

How Quill module works? 1/10

Kagol — Sun, 28 Mar 2021 04:36:16 +0000

The introduction

This post is based on DevUI rich text editor development practice(EditorX) and Quill source code written.

EditorX is a handy, easy-to-use, and powerful rich text editor developed by DevUI. It is based on Quill and has extensive extensions to enhance the editor's power.

Quill is an open source rich text editor for the Web that is API-driven and supports format and module customization. It currently has more than 29K stars on GitHub.

If you haven't had contact with Quill, it is recommended to go to the official website of Quill first to understand its basic concept.

By reading this post, you will learn:

What is Quill module? How to configure Quill module?
Why and how to create a custom Quill module?
How does a Quill module communicate with Quill?
Dive into Quill's modularity mechanism

A preliminary study of Quill module

Anyone who has used Quill to develop rich text applications should be familiar with Quill's modules.

For example, when we need to customize our own toolbar buttons, we will configure the toolbar module:

var quill = new Quill('#editor', {
  theme: 'snow',
  modules: {
    toolbar: [['bold', 'italic'], ['link', 'image']]
  }
});

The modules parameter is used to configure the module.

The toolbar parameter is used to configure the toolbar module and is passed in a two-dimensional array representing the grouped toolbar buttons.

The rendered editor will contain four toolbar buttons:

To see the Demo above, please anger the configuration toolbar module.

The Quill module is a normal JS class

So what is a Quill module?

Why do we need to know and use the Quill module?

A Quill module is just a normal JavaScript class with constructors, member variables, and methods.

The following is the general source structure of the toolbar module:

class Toolbar {
  constructor(quill, options) {
    // Parse the toolbar configuration of the incoming module (that is, the two-dimensional array described earlier) and render the toolbar
  }


  addHandler(format, handler) {
    this.handlers[format] = handler;
  }
  ...
}

You can see that the toolbar module is just a normal JS class. The constructor passes in the Quill instance and the options configuration, and the module class gets the Quill instance to control and manipulate the editor.

For example, a toolbar module will construct a toolbar container based on the Options configuration, fill the container with buttons/drop-down boxes, and bind the button/drop-down box handling events. The end result is a toolbar rendered above the editor body that allows you to format elements in the editor or insert new elements in the editor through the toolbar buttons/drop-down boxes.

The Quill module is very powerful, and we can use it to extend the power of the editor to do what we want.

In addition to toolbar modules, Quill also has some useful modules built in. Let's take a look at them.

Quill built-in modules

There are 6 built-in modules in Quill:

Clipboard
History
Keyboard
Syntax
Toolbar
Uploader

Clipboard, History, and Keyboard are the built-in modules required by Quill, which will be automatically opened. They can be configured but not cancelled. Among them:

The Clipboard module handles copy/paste events, matching HTML element nodes, and HTML-to-delta conversions.

The History module maintains a stack of actions that record every editor action, such as inserting/deleting content, formatting content, etc., making it easy to implement functions such as Undo/Redo.

The Keyboard module is used to configure Keyboard events to facilitate the implementation of Keyboard shortcuts.

The Syntax module is used for code Syntax highlighting. It relies on the external library highlight.js, which is turned off by default. To use Syntax highlighting, you must install highlight.js and turn it on manually.

Other modules do not do much introduction, want to know can refer to the Quill module documentation.

Quill module configuration

I just mentioned the Keyboard event module. Let's use another example to understand the configuration of the Quill module.

Keyboard module supports a number of shortcuts by default, such as:

The shortcut for bold is Ctrl+B;
The shortcut key for hyperlinks is Ctrl+K;
The undo/fallback shortcut is Ctrl+Z/Y.

However, it does not support the strikeline shortcut. If we want to customize the strikeline shortcut, let's say Ctrl+Shift+S, we can configure it like this:

modules: {
  keyboard: {
    bindings: {
      strike: {
        key: 'S',
        ctrlKey: true,
        shiftKey: true,
        handler: function(range, context) {
          const format = this.quill.getFormat(range);
          this.quill.format('strike', !format.strike);
        }
      },
    }
  },
  toolbar: [['bold', 'italic', 'strike'], ['link', 'image']]
}

To see the above Demo, please configure the keyboard module.

In the course of developing a rich text editor with Quill, we will encounter various modules and create many custom modules, all of which are configured using the Modules parameter.

Next we will try to create a custom module to deepen our understanding of Quill modules and module configuration.

Create a custom module

From the introduction of the last section, we learned that in fact, the Quill module is a normal JS class, there is nothing special, in the class initialization parameter will pass the Quill instance and the options configuration parameter of the module, then you can control and enhance the functions of the editor.

When Quill's built-in modules failed to meet our needs, we needed to create custom modules to implement the functionality we wanted.

For example, the EditorX rich text component has the ability to count the current word count in the editor. This function is implemented in a custom module. We will show you how to encapsulate this function as a separate Counter module step by step.

Create a Quill module in three steps:

Step 1: Create the module class

Create a new JS file with a normal JavaScript class inside.

class Counter {
  constructor(quill, options) {
    console.log('quill:', quill);
    console.log('options:', options);
  }
}

export default Counter;

This is an empty class with nothing but the options configuration information for the Quill instance and the module printed in the initialization method.

Step 2: Configure module parameters

modules: {
  toolbar: [
    ['bold', 'italic'],
    ['link', 'image']
  ],
  counter: true
}

Instead of passing the configuration data, we simply enabled the module and found that no information was printed.

Step 3: Register the module

To use a module, we need to register the module class by calling the quill-register method before the Quill is initialized (we'll see how this works later), and since we need to extend a module, the prefix needs to start with modules:

import Quill from 'quill';
import Counter from './counter';
Quill.register('modules/counter', Counter);

At this point we can see that the information has been printed.

Add logic to the module

At this point we add logic to the Counter module to count the words in the current editor:

constructor(quill, options) {
  this.container = quill.addContainer('ql-counter');
  quill.on(Quill.events.TEXT_CHANGE, () => {
    const text = quill.getText(); // Gets the plain text content in the editor
    const char = text.replace(/\s/g, ''); // Use regular expressions to remove white space characters
    this.container.innerHTML = `Current char count: ${char.length}`;
  });
}

In the initialization method of the Counter module, we call the addContainer method provided by Quill to add an empty container for the contents of the word count module to the editor, and then bind the content change event of the editor, so that when we enter the content in the editor, the word count can be counted in real time.

In the Text Change event, we call the Quill instance's getText method to get the plain Text content in the editor, then use a regular expression to remove the white space characters, and finally insert the word count information into the character count container.

The general effect of the presentation is as follows:

To see the above Demo, please anger the custom character statistics module.

Module loading mechanism

After we have a preliminary understanding of the Quill module, we will want to know how the Quill module works. Next, we will start from the initialization process of Quill, through the toolbar module example, in-depth discussion of the Quill module loading mechanism.

Tips: This summary involves the Quill source code analysis, welcome to leave a message to discuss if you don't understand the place.

The initialization of the Quill class

When we execute new Quill(), we execute the Quill class's constructor method, which is located in the Quill source code's core/quill.js file.

The approximate source structure of the initialization method is as follows (remove module loading irrelevant code) :

constructor(container, options = {}) {
  this.options = expandConfig(container, options); // Extend configuration data, including adding topic classes, and so on
  ...
  this.theme = new this.options.theme(this, this.options); // 1. Initialize the theme instance using the theme class in Options

  // 2.Add required modules
  this.keyboard = this.theme.addModule('keyboard');
  this.clipboard = this.theme.addModule('clipboard');
  this.history = this.theme.addModule('history');

  this.theme.init(); // 3. Initialize the theme. This method is the core of the module rendering (the actual core is the AddModule method called in it), traversing all configured module classes and rendering them into the DOM
  ... 
}

When Quill is initialized, it will use the expandConfig method to extend the options passed in and add elements such as topic classes to initialize the topic. (A default BaseTheme theme can be found without configuring the theme)

The addModule method of the theme instance is then called to mount the built-in required module into the theme instance.

Finally, the theme instance's init method is called to render all modules into the DOM. (More on how this works later)

If it is a snow theme, you will see a toolbar appear above the editor:

If it is a Bubble theme, then a toolbar float will appear when a text is selected:

Next, we take the toolbar module as an example to introduce the loading and rendering principle of Quill module in detail.

The loading of toolbar modules

Taking the Snow theme as an example, the following parameters are configured when the Quill instance is initialized:

{
  theme: 'snow',
  modules: {
    toolbar: [['bold', 'italic', 'strike'], ['link', 'image']]
  }
}

Quill in the constructor method to get to this. The theme is SnowTheme class instances, execute this.theme.init() method is invoked when its parent class theme of the init method, this method is located in the core/theme.js file.

init() {
  // Iterate through the Modules parameter in Quill Options to mount all the user-configured Modules into the theme class
  Object.keys(this.options.modules).forEach(name => {
    if (this.modules[name] == null) {
      this.addModule(name);
    }
  });
}

It iterates through all the modules in the options.modules parameter and calls the AddModule method of BaseTheme, which is located in the themes/base.js file.

addModule(name) {
  const module = super.addModule(name);
  if (name === 'toolbar') {
    this.extendToolbar(module);
  }
  return module;
}

This method will first execute the AddModule method of its parent class to initialize all the modules. If it is a toolbar module, additional processing will be done to the toolbar module after the initialization of the toolbar module, which is mainly to build the ICONS and bind the shortcut key of hyperlink.

Let's return to the addModule method of BaseTheme, this method is the core of module loading.

This is a method we saw earlier when we introduced the initialization of Quill, and called when we loaded the three built-in required modules. All modules load through this method, so it's worth exploring this method, which is located in core/theme.js.

addModule(name) {
  const ModuleClass = this.quill.constructor.import(`modules/${name}`); // To import a module class, create a custom module by registering the class with Quill. Register the class with Quill
// Initialize the module class
  this.modules[name] = new ModuleClass(
    this.quill,
    this.options.modules[name] || {},
  );
  return this.modules[name];
}

The addModule method imports the module class by calling the Quill.import method (if you have registered it through the Quill.register method).

We then initialize the class, mounting the instance into the Modules member variable of the theme class (which at this point already has an instance of the built-in required module).

In the case of a Toolbar module, the Toolbar class initialized in the addModule method is located in the modules/toolbar.js file.

class Toolbar {
  constructor(quill, options) {
    super(quill, options);

    // Parse the modules.toolbar parameters to generate the toolbar structure
    if (Array.isArray(this.options.container)) {
      const container = document.createElement('div');
      addControls(container, this.options.container);
      quill.container.parentNode.insertBefore(container, quill.container);
      this.container = container;
    } else {
      ...
    }

    this.container.classList.add('ql-toolbar');

    // Bind toolbar events
    this.controls = [];
    this.handlers = {};
    Object.keys(this.options.handlers).forEach(format => {
      this.addHandler(format, this.options.handlers[format]);
    });
    Array.from(this.container.querySelectorAll('button, select')).forEach(
      input => {
        this.attach(input);
      },
    );
    ...
  }
}

When a toolbar module is initialized, it parses the modules.toolbar parameters, calls the addControls method to generate the toolbar buttons and drop-down boxes (the basic idea is to iterate through a two-dimensional array and insert them into the toolbar as buttons or drop-down boxes), and binds events to them.

function addControls(container, groups) {
 if (!Array.isArray(groups[0])) {
  groups = [groups];
 }
 groups.forEach(controls => {
  const group = document.createElement('span');
  group.classList.add('ql-formats');
  controls.forEach(control => {
    if (typeof control === 'string') {
      addButton(group, control);
    } else {
      const format = Object.keys(control)[0];
      const value = control[format];
      if (Array.isArray(value)) {
        addSelect(group, format, value);
      } else {
        addButton(group, format, value);
      }
    }
  });
  container.appendChild(group);
 });
}

The toolbar module is then loaded and rendered into the rich text editor to facilitate editor operations.

Now a summary of the module loading process is made:

The starting point for module loading is the init method of the Theme class, which loads all the modules configured in the option.modules parameter into the member variable of the Theme class: modules, and merges them with the built-in required modules.
The addModule method imports the module class through the import method, and then creates an instance of the module through the new keyword.
When creating a module instance, the initialization method of the module is executed, and the specific logic of the module is executed.

Here is a diagram of the relationship between the module and the editor instance:

Conclusion

In this post, We introduced the configuration method of Quill module briefly through two examples, so that we have a intuitive and preliminary impression of the Quill module.

The character statistics module is then used as a simple example to show how to develop a custom Quill module that extends the functionality of the rich text editor.

Finally, through analyzing the initialization process of Quill, the loading mechanism of Quill module is gradually cut into, and the loading process of toolbar module is elaborated in detail.

About DevUI team

Official website: devui.design

Ng component library: ng-devui (Welcome to star🌟)

by Kagol