DEV Community: woai3c

Analysis of Key Technical Principles for a Visual Drag-and-Drop Component Library - 4

woai3c — Fri, 18 Apr 2025 12:52:41 +0000

This article is the fourth in the visual drag-and-drop series. Compared to the previous three articles, this one has slightly fewer features, totaling five points:

SVG components
Dynamic attribute panel
Data sources (API requests)
Component linkage
Component loading on demand

If you're not familiar with my previous articles in this series, I recommend reading these three articles first, then reading this one (otherwise, without context, it may be difficult to understand):

Here are the project and online DEMO links:

SVG Components

Currently, the custom components provided in the project all support free resizing, but they have one thing in common - they are all regular shapes. This means that to resize them, you can directly change the width and height without any other processing. But irregular shapes are different. For example, for a five-pointed star, you need to consider how to proportionally change the size when scaling. Eventually, I adopted the SVG solution to implement this (I also considered using iconfont, but it had flaws, so I abandoned it). Let's take a look at the specific implementation details.

Drawing a Five-Pointed Star with SVG

Suppose we need to draw a 100 * 100 five-pointed star, the code would be like this:

<svg 
    version="1.1" 
    baseProfile="full" 
    xmlns="http://www.w3.org/2000/svg"
>
    <polygon 
        points="50 0,62.5 37.5,100 37.5,75 62.5,87.5 100,50 75,12.5 100,25 62.5,0 37.5,37.5 37.5" 
        stroke="#000" 
        fill="rgba(255, 255, 255, 1)" 
        stroke-width="1"
    ></polygon>
</svg>

The version and namespace attributes on svg are not very important and can be ignored for now. The focus is on the polygon element, which in SVG defines "a closed shape consisting of a set of connected straight line segments." The last point connects to the first point. In other words, this polygon consists of a series of coordinate points, and points that are connected to each other are automatically connected. The points attribute of the polygon is used to represent a series of coordinate points of the polygon, with each coordinate point consisting of x and y coordinates, and each coordinate point separated by commas ,.

The image above is a five-pointed star drawn with SVG, consisting of ten coordinate points: 50 0,62.5 37.5,100 37.5,75 62.5,87.5 100,50 75,12.5 100,25 62.5,0 37.5,37.5 37.5. Since this is a 100*100 five-pointed star, we can easily calculate the proportion of each coordinate point in the star (coordinate system) based on their values. For example, the first point is p1(50,0), so its x and y coordinate ratios are 50%, 0; the second point p2(62.5,37.5), with corresponding ratios of 62.5%, 37.5%...

// Proportion collection of ten coordinate points of the five-pointed star
const points = [
    [0.5, 0],
    [0.625, 0.375],
    [1, 0.375],
    [0.75, 0.625],
    [0.875, 1],
    [0.5, 0.75],
    [0.125, 1],
    [0.25, 0.625],
    [0, 0.375],
    [0.375, 0.375],
]

Now that we know the proportions of the five-pointed star, it's easy to draw a five-pointed star of any size. We just need to proportionally provide the specific value for each coordinate point each time we resize the five-pointed star and change its dimensions.

<div class="svg-star-container">
    <svg
        version="1.1"
        baseProfile="full"
        xmlns="http://www.w3.org/2000/svg"
    >
        <polygon
            ref="star"
            :points="points"
            :stroke="element.style.borderColor"
            :fill="element.style.backgroundColor"
            stroke-width="1"
        />
    </svg>
    <v-text :prop-value="element.propValue" :element="element" />
</div>

<script>
function drawPolygon(width, height) {
    // Proportion collection of ten coordinate points of the five-pointed star
    const points = [
        [0.5, 0],
        [0.625, 0.375],
        [1, 0.375],
        [0.75, 0.625],
        [0.875, 1],
        [0.5, 0.75],
        [0.125, 1],
        [0.25, 0.625],
        [0, 0.375],
        [0.375, 0.375],
    ]

    const coordinatePoints = points.map(point => width * point[0] + ' ' + height * point[1])
    this.points = coordinatePoints.toString() // Get the points attribute data for the five-pointed star
}
</script>

Other SVG Components

Similarly, to draw other types of SVG components, we just need to know the proportions of their coordinate points. If you don't know how to draw an SVG, you can search online and first find a usable SVG code (the SVG code for this five-pointed star was found online). Then calculate the proportions of each coordinate point, convert them to decimal form, and finally input this data into the drawPolygon() function provided above. For example, the code to draw a triangle looks like this:

function drawTriangle(width, height) {
    const points = [
        [0.5, 0.05],
        [1, 0.95],
        [0, 0.95],
    ]

    const coordinatePoints = points.map(point => width * point[0] + ' ' + height * point[1])
    this.points = coordinatePoints.toString() // Get the points attribute data for the triangle
}

Dynamic Attribute Panel

Currently, all custom components share the same AttrList component for their attribute panels. The disadvantage is obvious: we need to write many if statements, because different components have different attributes. For example, the rectangle component has a content attribute, but the image does not, so one different attribute requires one if statement.

<el-form-item v-if="name === 'rectShape'" label="Content">
   <el-input />
</el-form-item>
<!-- Other attributes... -->

Fortunately, the solution to this problem is not difficult. In the first article of this series, we discussed how to dynamically render custom components:

<component :is="item.component"></component> <!-- Dynamically render components -->

Each custom component's data structure has a component attribute, which is the name registered in Vue. Therefore, the attribute panel for each custom component can be made dynamic, just like the component itself (using the component attribute):

<!-- Right attribute list -->
<section class="right">
    <el-tabs v-if="curComponent" v-model="activeName">
        <el-tab-pane label="Attributes" name="attr">
            <component :is="curComponent.component + 'Attr'" /> <!-- Dynamically render attribute panel -->
        </el-tab-pane>
        <el-tab-pane label="Animation" name="animation" style="padding-top: 20px;">
            <AnimationList />
        </el-tab-pane>
        <el-tab-pane label="Events" name="events" style="padding-top: 20px;">
            <EventList />
        </el-tab-pane>
    </el-tabs>
    <CanvasAttr v-else></CanvasAttr>
</section>

At the same time, the directory structure of custom components also needs to be adjusted. The original directory structure was:

- VText.vue
- Picture.vue
...

After adjustment, it becomes:

- VText
    - Attr.vue <!-- Component's attribute panel -->
    - Component.vue <!-- The component itself -->
- Picture
    - Attr.vue
    - Component.vue

Now each component includes both the component itself and its attribute panel. After the transformation, the image attribute panel code is also more concise:

<template>
    <div class="attr-list">
        <CommonAttr></CommonAttr> <!-- Common attributes -->
        <el-form>
            <el-form-item label="Mirror flip">
                <div style="clear: both;">
                    <el-checkbox v-model="curComponent.propValue.flip.horizontal" label="horizontal">Horizontal flip</el-checkbox>
                    <el-checkbox v-model="curComponent.propValue.flip.vertical" label="vertical">Vertical flip</el-checkbox>
                </div>
            </el-form-item>
        </el-form>
    </div>
</template>

In this way, both components and their corresponding attribute panels become dynamic. It will be very convenient to add attributes to a specific custom component in the future.

Data Sources (API Requests)

Some components need to load data dynamically, so I specifically added a Request common attribute component for requesting data. When a custom component has a request attribute, the API request related content will be rendered on the attribute panel. So far, there are two common components for the attribute panel:

-common
    - Request.vue <!-- API request -->
    - CommonAttr.vue <!-- Common styles -->

// VText custom component data structure
{
    component: 'VText',
    label: 'Text',
    propValue: 'Double-click to edit text',
    icon: 'wenben',
    request: { // API request
        method: 'GET',
        data: [],
        url: '',
        series: false, // Whether to send requests periodically
        time: 1000, // Timed update interval
        paramType: '', // string object array
        requestCount: 0, // Request count limit, 0 for unlimited
    },
    style: { // Common styles
        width: 200,
        height: 28,
        fontSize: '',
        fontWeight: 400,
        lineHeight: '',
        letterSpacing: 0,
        textAlign: '',
        color: '',
    },
}

From the GIF above, you can see that the API request method parameters can be manually modified. But how do we control assigning the returned data to a certain property of the component? This can be done by passing the entire data object obj of the component and the key of the property to be modified as parameters when making the request, and when the data returns, we can directly use obj[key] = data to modify the data.

// The second parameter is the parent object of the data to be modified, the third parameter is the key of the data to be modified, the fourth parameter is the type of data to be modified
this.cancelRequest = request(this.request, this.element, 'propValue', 'string')

Component Linkage

Component linkage: When one component triggers an event, another component receives a notification and performs a corresponding operation.

The rectangle in the GIF above monitors the hover events of the two buttons below. When the first button triggers a hover and broadcasts the event, the rectangle executes a callback to rotate and move to the right; the second button does the opposite, rotating and moving to the left.

To implement this feature, first add a new property linkage to the custom component to record all components to be linked:

{
    // Other component properties...
    linkage: {
         duration: 0, // Transition duration
         data: [ // Component linkage
             {
                 id: '', // Linked component id
                 label: '', // Linked component name
                 event: '', // Monitored event
                 style: [{ key: '', value: '' }], // Properties that need to be changed when the monitored event is triggered
             },
         ],
     }
}

The corresponding attribute panel is:

Component linkage is essentially the application of the publish/subscribe pattern. Each component iterates through all the components it monitors when rendering.

Event Monitoring

<script>
import eventBus from '@/utils/eventBus'

export default {
    props: {
        linkage: {
            type: Object,
            default: () => {},
        },
        element: {
            type: Object,
            default: () => {},
        },
    },
    created() {
        if (this.linkage?.data?.length) {
            eventBus.$on('v-click', this.onClick)
            eventBus.$on('v-hover', this.onHover)
        }
    },
    mounted() {
        const { data, duration } = this.linkage || {}
        if (data?.length) {
            this.$el.style.transition = `all ${duration}s`
        }
    },
    beforeDestroy() {
        if (this.linkage?.data?.length) {
            eventBus.$off('v-click', this.onClick)
            eventBus.$off('v-hover', this.onHover)
        }
    },
    methods: {
        changeStyle(data = []) {
            data.forEach(item => {
                item.style.forEach(e => {
                    if (e.key) {
                        this.element.style[e.key] = e.value
                    }
                })
            })
        },

        onClick(componentId) {
            const data = this.linkage.data.filter(item => item.id === componentId && item.event === 'v-click')
            this.changeStyle(data)
        },

        onHover(componentId) {
            const data = this.linkage.data.filter(item => item.id === componentId && item.event === 'v-hover')
            this.changeStyle(data)
        },
    },
}
</script>

From the code above, we can see that:

Each custom component initializes by monitoring two events: v-click and v-hover (currently there are only click and hover events)
When event callback functions are triggered, they receive a parameter - the component id that emitted the event (e.g., if multiple components triggered click events, we need to determine if it's the component we're monitoring based on the id)
Finally, modify the corresponding properties

Event Triggering

<template>
    <div @click="onClick" @mouseenter="onMouseEnter">
        <component
            :is="config.component"
            ref="component"
            class="component"
            :style="getStyle(config.style)"
            :prop-value="config.propValue"
            :element="config"
            :request="config.request"
            :linkage="config.linkage"
        />
    </div>
</template>

<script>
import eventBus from '@/utils/eventBus'

export default {
    methods: {
        onClick() {
            const events = this.config.events
            Object.keys(events).forEach(event => {
                this[event](events[event])
            })

            eventBus.$emit('v-click', this.config.id)
        },

        onMouseEnter() {
            eventBus.$emit('v-hover', this.config.id)
        },
    },
}
</script>

From the code above, we can see that when rendering components, each component's outermost layer monitors the click and mouseenter events. When these events are triggered, eventBus triggers the corresponding event (v-click or v-hover) and passes the current component id as a parameter.

Let's review the overall logic once more:

Component a monitors native events click and mouseenter
Users click or move the mouse to the component, triggering native events click or mouseenter
Event callback functions then use eventBus to trigger v-click or v-hover events
Component b, which is monitoring these two events, receives the notification and modifies the relevant properties of component b (such as the x coordinate and rotation angle of the rectangle above)

Component Loading on Demand

Currently, this project itself has not implemented on-demand loading, but I'll describe the implementation approach in text form, which should be sufficient.

Step 1: Extraction

First, we need to extract all custom components and store them separately. It's recommended to use a monorepo approach, with all components stored in one repository. Each package is a component that can be packaged separately.

- node_modules
- packages
    - v-text # One component is one package 
    - v-button
    - v-table
- package.json
- lerna.json

Step 2: Packaging

It's recommended to package each component as a single js file, such as bundle.js. After packaging, directly call the upload API to store it on the server (publishing to npm is also an option), and each component has a unique id. Each time the frontend renders a component, it requests the component resource URL from the server using this component id.

Step 3: Dynamic Loading of Components

There are two ways to dynamically load components:

import()
<script> tag

The first method is more convenient to implement:

const name = 'v-text' // Component name
const component = await import('https://xxx.xxx/bundile.js')
Vue.component(name, component)

But there are some compatibility issues. If you need to support some older browsers (like IE), you can use the <script> tag to load:

function loadjs(url) {
    return new Promise((resolve, reject) => {
        const script = document.createElement('script')
        script.src = url
        script.onload = resolve
        script.onerror = reject
    })
}

const name = 'v-text' // Component name
await loadjs('https://xxx.xxx/bundile.js')
// This way of loading components will directly mount the component to the global variable window, so window[name] gives the component
Vue.component(name, window[name])

To support both loading methods, you need to determine whether the browser supports ES6 when loading components. If it does, use the first method; if not, use the second method:

function isSupportES6() {
    try {
        new Function('const fn = () => {};')
    } catch (error) {
        return false
    }

    return true
}

Finally, the packaging also needs to be compatible with both loading methods:

import VText from './VText.vue'

if (typeof window !== 'undefined') {
    window['VText'] = VText
}

export default VText

Export the component and mount it under window at the same time.

Other Small Optimizations

Image Mirroring

Image mirroring needs to be implemented using canvas, mainly using canvas's translate() and scale() methods. Suppose we want to horizontally mirror a 100*100 image, the code would be like this:

<canvas width="100" height="100"></canvas>

<script>
    const canvas = document.querySelector('canvas')
    const ctx = canvas.getContext('2d')
    const img = document.createElement('img')
    const width = 100
    const height = 100
    img.src = 'https://avatars.githubusercontent.com/u/22117876?v=4'
    img.onload = () => ctx.drawImage(img, 0, 0, width, height)

    // Horizontal flip
    setTimeout(() => {
        // Clear image
        ctx.clearRect(0, 0, width, height)
        // Translate image
        ctx.translate(width, 0)
        // Symmetric mirroring
        ctx.scale(-1, 1)
        ctx.drawImage(img, 0, 0, width, height)
        // Restore coordinate point
        ctx.setTransform(1, 0, 0, 1, 0, 0)
    }, 2000)
</script>

The ctx.translate(width, 0) line means moving the image's x-coordinate forward by width pixels, so after translation, the image is just outside the canvas. Then using ctx.scale(-1, 1) to horizontally flip the image, you get a horizontally flipped image.

Vertical flipping follows the same principle, but with different parameters:

// Originally horizontal flip was ctx.translate(width, 0)
ctx.translate(0, height) 
// Originally horizontal flip was ctx.scale(-1, 1)
ctx.scale(1, -1)

Real-Time Component List

Each component in the canvas has a hierarchy, but the specific hierarchy of each component is not displayed in real-time. Therefore, this real-time component list feature was created.

This feature is not difficult to implement; its principle is the same as canvas rendering components, but this list only needs to render icons and names.

<div class="real-time-component-list">
    <div
        v-for="(item, index) in componentData"
        :key="index"
        class="list"
        :class="{ actived: index === curComponentIndex }"
        @click="onClick(index)"
    >
        <span class="iconfont" :class="'icon-' + getComponent(index).icon"></span>
        <span>{{ getComponent(index).label }}</span>
    </div>
</div>

But one thing to note is that in the component data array, the components at the end have higher hierarchy. So without processing the array data index, what users see is like this (assuming the order of adding components is text, button, image):

From the user's perspective, the image with the highest hierarchy is at the end of the real-time list. This doesn't match our usual understanding. So, we need to reverse() the component data. For example, the text component with index 0 has the lowest hierarchy and should be displayed at the bottom. Each time we display the real-time list, we can convert using the code below to get the reversed index, then render, making the order more comfortable:

<div class="real-time-component-list">
    <div
        v-for="(item, index) in componentData"
        :key="index"
        class="list"
        :class="{ actived: transformIndex(index) === curComponentIndex }"
        @click="onClick(transformIndex(index))"
    >
        <span class="iconfont" :class="'icon-' + getComponent(index).icon"></span>
        <span>{{ getComponent(index).label }}</span>
    </div>
</div>

<script>
function getComponent(index) {
    return componentData[componentData.length - 1 - index]
}

function transformIndex(index) {
    return componentData.length - 1 - index
}
</script>

After conversion, the image with the highest hierarchy is at the top of the real-time list. Perfect!

Conclusion

With this, the fourth article in the visual drag-and-drop series comes to an end. I didn't expect this project to be so popular, gaining recognition from many netizens in just one year. So I hope this fourth article in the series will be as helpful to everyone as before. Thank you again!

Analysis of Key Technical Principles for a Visual Drag-and-Drop Component Library - 3

woai3c — Sun, 13 Apr 2025 15:03:02 +0000

This article is the third in the visual drag-and-drop series. The previous two articles analyzed the technical principles of 17 features:

Editor
Custom components
Drag and drop
Delete components, adjust layer hierarchy
Zoom in and out
Undo, redo
Component property settings
Snap
Preview, save code
Bind events
Bind animations
Import PSD
Mobile mode
Drag rotation
Copy, paste, and cut
Data interaction
Publish

Building on this foundation, this article will analyze the technical principles of the following features:

Combining and splitting multiple components
Text component
Rectangle component
Lock component
Shortcuts
Grid lines
Another implementation method for editor snapshots

If you're not familiar with my previous two articles, I recommend reading them first before continuing with this one:

Although my visual drag-and-drop component library is just a DEMO, compared to some existing products on the market (such as processon, Modao), it implements most of the basic functions.

If you're interested in low-code platforms but aren't familiar with them, I strongly recommend reading my three articles along with the project source code. I'm sure you'll gain a lot. Here are the project and online DEMO links:

18. Combining and splitting multiple components

There are relatively more technical points for combining and splitting, with the following 4 aspects:

Selection area
Movement and rotation after combination
Scaling after combination
Restoring child component styles after splitting

Selection area

Before combining multiple components, we need to select them first. Using mouse events, we can easily display the selection area:

mousedown records the starting coordinates
mousemove calculates the movement area using the current coordinates and starting coordinates
If the mouse is pressed and moved toward the upper left, we need to set the current coordinates as the starting coordinates and then calculate the movement area

// Get the editor's displacement information
const rectInfo = this.editor.getBoundingClientRect()
this.editorX = rectInfo.x
this.editorY = rectInfo.y

const startX = e.clientX
const startY = e.clientY
this.start.x = startX - this.editorX
this.start.y = startY - this.editorY
// Show selection area
this.isShowArea = true

const move = (moveEvent) => {
    this.width = Math.abs(moveEvent.clientX - startX)
    this.height = Math.abs(moveEvent.clientY - startY)
    if (moveEvent.clientX < startX) {
        this.start.x = moveEvent.clientX - this.editorX
    }

    if (moveEvent.clientY < startY) {
        this.start.y = moveEvent.clientY - this.editorY
    }
}

When the mouseup event is triggered, we need to calculate the displacement and size information of all components in the selected area to obtain a minimum area that can contain all components in the region. The effect is shown in the following figure:

The code for this calculation process:

createGroup() {
  // Get component data in the selected area
  const areaData = this.getSelectArea()
  if (areaData.length <= 1) {
      this.hideArea()
      return
  }

  // Create a Group component based on the selected area and the displacement information of each component in the area
  // Need to traverse each component in the selected area, get their left top right bottom information for comparison
  let top = Infinity, left = Infinity
  let right = -Infinity, bottom = -Infinity
  areaData.forEach(component => {
      let style = {}
      if (component.component == 'Group') {
          component.propValue.forEach(item => {
              const rectInfo = $(`#component${item.id}`).getBoundingClientRect()
              style.left = rectInfo.left - this.editorX
              style.top = rectInfo.top - this.editorY
              style.right = rectInfo.right - this.editorX
              style.bottom = rectInfo.bottom - this.editorY

              if (style.left < left) left = style.left
              if (style.top < top) top = style.top
              if (style.right > right) right = style.right
              if (style.bottom > bottom) bottom = style.bottom
          })
      } else {
          style = getComponentRotatedStyle(component.style)
      }

      if (style.left < left) left = style.left
      if (style.top < top) top = style.top
      if (style.right > right) right = style.right
      if (style.bottom > bottom) bottom = style.bottom
  })

  this.start.x = left
  this.start.y = top
  this.width = right - left
  this.height = bottom - top

  // Set displacement and size information for the selected area and the component data within the area
  this.$store.commit('setAreaData', {
      style: {
          left,
          top,
          width: this.width,
          height: this.height,
      },
      components: areaData,
  })
},

getSelectArea() {
    const result = []
    // Area starting coordinates
    const { x, y } = this.start
    // Calculate all component data, determine if they are in the selected area
    this.componentData.forEach(component => {
        if (component.isLock) return
        const { left, top, width, height } = component.style
        if (x <= left && y <= top && (left + width <= x + this.width) && (top + height <= y + this.height)) {
            result.push(component)
        }
    })

    // Return all components in the selected area
    return result
}

Let me briefly describe the processing logic of this code:

Use the getBoundingClientRect() browser API to get information about each component in four directions relative to the browser viewport, which are left top right bottom.
Compare these four pieces of information for each component to obtain the leftmost, topmost, rightmost, and bottommost values, thereby deriving a minimum area that can contain all components in the region.
If there is already a Group component in the selected area, we need to calculate its child components rather than calculating the combined component.

Movement and rotation after combination

To facilitate moving, rotating, scaling, and other operations on multiple components together, I created a new Group combined component:

<template>
    <div class="group">
        <div>
             <template v-for="item in propValue">
                <component
                    class="component"
                    :is="item.component"
                    :style="item.groupStyle"
                    :propValue="item.propValue"
                    :key="item.id"
                    :id="'component' + item.id"
                    :element="item"
                />
            </template>
        </div>
    </div>
</template>

<script>
import { getStyle } from '@/utils/style'

export default {
    props: {
        propValue: {
            type: Array,
            default: () => [],
        },
        element: {
            type: Object,
        },
    },
    created() {
        const parentStyle = this.element.style
        this.propValue.forEach(component => {
            // component.groupStyle's top left are positions relative to the group component
            // If component.groupStyle already exists, it means it has been calculated once. No need to calculate again
            if (!Object.keys(component.groupStyle).length) {
                const style = { ...component.style }
                component.groupStyle = getStyle(style)
                component.groupStyle.left = this.toPercent((style.left - parentStyle.left) / parentStyle.width)
                component.groupStyle.top = this.toPercent((style.top - parentStyle.top) / parentStyle.height)
                component.groupStyle.width = this.toPercent(style.width / parentStyle.width)
                component.groupStyle.height = this.toPercent(style.height / parentStyle.height)
            }
        })
    },
    methods: {
        toPercent(val) {
            return val * 100 + '%'
        },
    },
}
</script>

<style lang="scss" scoped>
.group {
    & > div {
        position: relative;
        width: 100%;
        height: 100%;

        .component {
            position: absolute;
        }
    }
}
</style>

The purpose of the Group component is to put the components in the area under it, making them child components. And when creating a Group component, get the relative displacement and relative size of each child component within the Group component:

created() {
    const parentStyle = this.element.style
    this.propValue.forEach(component => {
        // component.groupStyle's top left are positions relative to the group component
        // If component.groupStyle already exists, it means it has been calculated once. No need to calculate again
        if (!Object.keys(component.groupStyle).length) {
            const style = { ...component.style }
            component.groupStyle = getStyle(style)
            component.groupStyle.left = this.toPercent((style.left - parentStyle.left) / parentStyle.width)
            component.groupStyle.top = this.toPercent((style.top - parentStyle.top) / parentStyle.height)
            component.groupStyle.width = this.toPercent(style.width / parentStyle.width)
            component.groupStyle.height = this.toPercent(style.height / parentStyle.height)
        }
    })
},
methods: {
    toPercent(val) {
        return val * 100 + '%'
    },
},

This is converting the child component's left top width height properties into relative values ending with %.

Why not use absolute values?

If we use absolute values, then when moving the Group component, in addition to calculating the properties of the Group component, we would also need to calculate each of its child components. And if the Group contains too many child components, the calculation load would be very large when moving or scaling, possibly causing page lag. If we change to relative values, we only need to calculate once when the Group is created. Then when the Group component is moved or rotated, we don't need to worry about the child components of the Group, we just calculate it itself.

Scaling after combination

Scaling after combination is a big problem, mainly due to the presence of rotation angles. First, let's look at scaling when the child components are not rotated:

From the animation, we can see that the effect is perfect. The size of each child component changes with the size of the Group component.

Now let's try adding rotation angles to the child components and see the effect:

Why does this problem occur?

The main reason is that regardless of whether a component is rotated or not, its top left properties remain unchanged. This creates a problem: although the component's top left width height properties haven't changed, they appear to have changed in appearance. Below are two identical components: one is not rotated, and the other is rotated 45 degrees.

As you can see, the top left width height properties of the rotated button are different from what we see in appearance.

Let's look at a specific example:

Above is a Group component, and the properties of its child component on the left are:

transform: rotate(-75.1967deg);
width: 51.2267%;
height: 32.2679%;
top: 33.8661%;
left: -10.6496%;

We can see that the value of width is 51.2267%, but from appearance, this child component takes up at most one-third of the width of the Group component. So this is the problem with abnormal scaling.

An unworkable solution (feel free to skip)

Initially, I thought of first calculating its top left width height properties relative to the browser viewport, then calculating the relative values of these properties on the Group component. This can be done using the getBoundingClientRect() API. As long as the proportion of each property in appearance remains unchanged, when the Group component is scaled, the rotation angle can be used, along with knowledge of rotation matrices (this is described in detail in the second article), to obtain its top left width height properties before rotation. This way, dynamic adjustment of child components can be achieved.

But there's a problem: the getBoundingClientRect() API can only get the appearance-based top left right bottom width height properties of a component. Adding an angle still leaves us with insufficient parameters, so we can't calculate the actual top left width height properties of a component.

As shown in the image above, knowing only the origin O(x,y), w, h, and the rotation angle, we cannot calculate the width and height of the button.

A workable solution

I discovered this by chance. When scaling the Group component, I found that as long as the width-to-height ratio of the Group component is maintained, the child components can be scaled proportionally. So now the problem becomes how to maintain the width-to-height ratio when scaling the Group component. I found this article online, which describes in detail how to maintain the width-to-height ratio when scaling a rotated component, complete with source code examples.

Now I'll try to briefly describe how to maintain the width-to-height ratio when scaling a rotated component (I recommend reading the original article). Below is a rectangle that has been rotated by a certain angle. Suppose we are now dragging its top-left point to stretch it.

First step, calculate the component's width-to-height ratio, and calculate the component's center point when the mouse is pressed based on the component's coordinates (regardless of how many degrees it rotates, the component's top left properties remain unchanged) and size:

// Component width-to-height ratio
const proportion = style.width / style.height

const center = {
    x: style.left + style.width / 2,
    y: style.top + style.height / 2,
}

Second step, use the current click coordinates and the component's center point to calculate the symmetric point coordinates of the current click coordinates:

// Get canvas displacement information
const editorRectInfo = document.querySelector('#editor').getBoundingClientRect()

// Current click coordinates
const curPoint = {
    x: e.clientX - editorRectInfo.left,
    y: e.clientY - editorRectInfo.top,
}

// Get coordinates of the symmetric point
const symmetricPoint = {
    x: center.x - (curPoint.x - center.x),
    y: center.y - (curPoint.y - center.y),
}

Third step, when holding the top-left corner of the component to stretch it, calculate the new component center point using the current mouse real-time coordinates and symmetric point:

const curPositon = {
    x: moveEvent.clientX - editorRectInfo.left,
    y: moveEvent.clientY - editorRectInfo.top,
}

const newCenterPoint = getCenterPoint(curPositon, symmetricPoint)

// Calculate the midpoint coordinates between two points
function getCenterPoint(p1, p2) {
    return {
        x: p1.x + ((p2.x - p1.x) / 2),
        y: p1.y + ((p2.y - p1.y) / 2),
    }
}

Since the component is in a rotated state, even if you know the xy distance moved during stretching, you cannot directly calculate the component. Otherwise, bugs will occur, such as misalignment or incorrect scaling direction. Therefore, we need to calculate it in the case where the component is not rotated.

Fourth step, based on the known rotation angle, new component center point, and current mouse real-time coordinates, we can calculate the coordinates newTopLeftPoint of the current mouse real-time coordinates currentPosition when not rotated. At the same time, we can also calculate the coordinates newBottomRightPoint of the component symmetric point sPoint when not rotated based on the known rotation angle, new component center point, and symmetric point.

The corresponding calculation formula is as follows:

/**
 * Calculate the coordinates of a point after rotation around a center
 * @param   {Object}  point  Point coordinates before rotation
 * @param   {Object}  center Rotation center
 * @param   {Number}  rotate Rotation angle
 * @return  {Object}         Coordinates after rotation
 * https://www.zhihu.com/question/67425734/answer/252724399 Rotation matrix formula
 */
export function calculateRotatedPointCoordinate(point, center, rotate) {
    /**
     * Rotation formula:
     *  Point a(x, y)
     *  Rotation center c(x, y)
     *  Rotated point n(x, y)
     *  Rotation angle θ
     * nx = cosθ * (ax - cx) - sinθ * (ay - cy) + cx
     * ny = sinθ * (ax - cx) + cosθ * (ay - cy) + cy
     */

    return {
        x: (point.x - center.x) * Math.cos(angleToRadian(rotate)) - (point.y - center.y) * Math.sin(angleToRadian(rotate)) + center.x,
        y: (point.x - center.x) * Math.sin(angleToRadian(rotate)) + (point.y - center.y) * Math.cos(angleToRadian(rotate)) + center.y,
    }
}

The above formula involves knowledge of rotation matrices in linear algebra, which is really difficult for someone who hasn't gone to university. Fortunately, I found the reasoning process for this formula from an answer on Zhihu. Here is the original text of the answer:

Through the above calculated values, we can get the component's new displacement values top left and new component size. The corresponding complete code is as follows:

function calculateLeftTop(style, curPositon, pointInfo) {
    const { symmetricPoint } = pointInfo
    const newCenterPoint = getCenterPoint(curPositon, symmetricPoint)
    const newTopLeftPoint = calculateRotatedPointCoordinate(curPositon, newCenterPoint, -style.rotate)
    const newBottomRightPoint = calculateRotatedPointCoordinate(symmetricPoint, newCenterPoint, -style.rotate)

    const newWidth = newBottomRightPoint.x - newTopLeftPoint.x
    const newHeight = newBottomRightPoint.y - newTopLeftPoint.y
    if (newWidth > 0 && newHeight > 0) {
        style.width = Math.round(newWidth)
        style.height = Math.round(newHeight)
        style.left = Math.round(newTopLeftPoint.x)
        style.top = Math.round(newTopLeftPoint.y)
    }
}

Now let's look at scaling after rotation:

Fifth step, since we now need to scale with a locked width-to-height ratio, we need to recalculate the coordinates of the top-left corner of the stretched figure.

Let's define the naming of several shapes:

Original shape: red part
New shape: blue part
Corrected shape: green part, that is, the shape corrected with the width-to-height ratio lock rule

After calculating the component's newTopLeftPoint newBottomRightPoint newWidth newHeight before rotation in the fourth step, we need to calculate the new width or height based on the width-to-height ratio proportion.

The above image is an example of needing to change the height, with the calculation process as follows:

if (newWidth / newHeight > proportion) {
    newTopLeftPoint.x += Math.abs(newWidth - newHeight * proportion)
    newWidth = newHeight * proportion
} else {
    newTopLeftPoint.y += Math.abs(newHeight - newWidth / proportion)
    newHeight = newWidth / proportion
}

Since we are now calculating the coordinates before rotation based on the coordinates before reducing width and height according to proportion, after reducing width and height, we need to rotate back according to the original center point to get the coordinates corresponding to reducing width and height and rotating back. Then use this coordinate and the symmetric point to get a new center point, and recalculate the coordinates before rotation.

The complete code after modification is as follows:

function calculateLeftTop(style, curPositon, proportion, needLockProportion, pointInfo) {
    const { symmetricPoint } = pointInfo
    let newCenterPoint = getCenterPoint(curPositon, symmetricPoint)
    let newTopLeftPoint = calculateRotatedPointCoordinate(curPositon, newCenterPoint, -style.rotate)
    let newBottomRightPoint = calculateRotatedPointCoordinate(symmetricPoint, newCenterPoint, -style.rotate)

    let newWidth = newBottomRightPoint.x - newTopLeftPoint.x
    let newHeight = newBottomRightPoint.y - newTopLeftPoint.y

    if (needLockProportion) {
        if (newWidth / newHeight > proportion) {
            newTopLeftPoint.x += Math.abs(newWidth - newHeight * proportion)
            newWidth = newHeight * proportion
        } else {
            newTopLeftPoint.y += Math.abs(newHeight - newWidth / proportion)
            newHeight = newWidth / proportion
        }

        // Since we are now calculating the coordinates before rotation based on the coordinates before reducing width and height according to proportion
        // After reducing width and height, we need to rotate back according to the original center point to get the coordinates corresponding to reducing width and height and rotating back
        // Then use this coordinate and the symmetric point to get a new center point, and recalculate the coordinates before rotation
        const rotatedTopLeftPoint = calculateRotatedPointCoordinate(newTopLeftPoint, newCenterPoint, style.rotate)
        newCenterPoint = getCenterPoint(rotatedTopLeftPoint, symmetricPoint)
        newTopLeftPoint = calculateRotatedPointCoordinate(rotatedTopLeftPoint, newCenterPoint, -style.rotate)
        newBottomRightPoint = calculateRotatedPointCoordinate(symmetricPoint, newCenterPoint, -style.rotate)

        newWidth = newBottomRightPoint.x - newTopLeftPoint.x
        newHeight = newBottomRightPoint.y - newTopLeftPoint.y
    }

    if (newWidth > 0 && newHeight > 0) {
        style.width = Math.round(newWidth)
        style.height = Math.round(newHeight)
        style.left = Math.round(newTopLeftPoint.x)
        style.top = Math.round(newTopLeftPoint.y)
    }
}

The effect of scaling while maintaining the width-to-height ratio is as follows:

When the Group component has rotated child components, it needs to maintain the width-to-height ratio when scaling. So when creating a Group component, you can check if the child components have rotation angles. If not, you don't need to maintain the width-to-height ratio when scaling.

isNeedLockProportion() {
    if (this.element.component != 'Group') return false
    const ratates = [0, 90, 180, 360]
    for (const component of this.element.propValue) {
        if (!ratates.includes(mod360(parseInt(component.style.rotate)))) {
            return true
        }
    }

    return false
}

Restoring child component styles after splitting

Combining multiple components together is just the first step. The second step is to split the Group component and restore the styles of each child component. This ensures that the child components' appearance attributes remain unchanged after splitting.

The calculation code is as follows:

// store
decompose({ curComponent, editor }) {
    const parentStyle = { ...curComponent.style }
    const components = curComponent.propValue
    const editorRect = editor.getBoundingClientRect()

    store.commit('deleteComponent')
    components.forEach(component => {
        decomposeComponent(component, editorRect, parentStyle)
        store.commit('addComponent', { component })
    })
}

// Split each child component in the combination, and calculate their new style
export default function decomposeComponent(component, editorRect, parentStyle) {
    // Child component style relative to browser viewport
    const componentRect = $(`#component${component.id}`).getBoundingClientRect()
    // Get the center point coordinates of the element
    const center = {
        x: componentRect.left - editorRect.left + componentRect.width / 2,
        y: componentRect.top - editorRect.top + componentRect.height / 2,
    }

    component.style.rotate = mod360(component.style.rotate + parentStyle.rotate)
    component.style.width = parseFloat(component.groupStyle.width) / 100 * parentStyle.width
    component.style.height = parseFloat(component.groupStyle.height) / 100 * parentStyle.height
    // Calculate the new top left coordinates of the element
    component.style.left = center.x - component.style.width / 2
    component.style.top = center.y - component.style.height / 2
    component.groupStyle = {}
}

The processing logic of this code is:

Traverse the child components of Group and restore their styles
Use the getBoundingClientRect() API to get the left top width height properties of the child component relative to the browser viewport.
Use these four properties to calculate the center point coordinates of the child component.
Since the width height properties of the child component are relative to the Group component, multiply their percentage values by Group to get specific values.
Then use the center point center(x, y) minus half the width and height of the child component to get its left top properties.

With this, the combination and splitting explanation is complete.

19. Text component

The VText text component was implemented before, but it wasn't perfect. For example, it couldn't select text. Now I've rewritten it to support the selection function.

<template>
    <div v-if="editMode == 'edit'" class="v-text" @keydown="handleKeydown" @keyup="handleKeyup">
        <!-- tabindex >= 0 makes the element focus when double-clicked -->
        <div :contenteditable="canEdit" :class="{ canEdit }" @dblclick="setEdit" :tabindex="element.id" @paste="clearStyle"
            @mousedown="handleMousedown" @blur="handleBlur" ref="text" v-html="element.propValue" @input="handleInput"
            :style="{ verticalAlign: element.style.verticalAlign }"
        ></div>
    </div>
    <div v-else class="v-text">
        <div v-html="element.propValue" :style="{ verticalAlign: element.style.verticalAlign }"></div>
    </div>
</template>

<script>
import { mapState } from 'vuex'
import { keycodes } from '@/utils/shortcutKey.js'

export default {
    props: {
        propValue: {
            type: String,
            require: true,
        },
        element: {
            type: Object,
        },
    },
    data() {
        return {
            canEdit: false,
            ctrlKey: 17,
            isCtrlDown: false,
        }
    },
    computed: {
        ...mapState([
            'editMode',
        ]),
    },
    methods: {
        handleInput(e) {
            this.$emit('input', this.element, e.target.innerHTML)
        },

        handleKeydown(e) {
            if (e.keyCode == this.ctrlKey) {
                this.isCtrlDown = true
            } else if (this.isCtrlDown && this.canEdit && keycodes.includes(e.keyCode)) {
                e.stopPropagation()
            } else if (e.keyCode == 46) { // deleteKey
                e.stopPropagation()
            }
        },

        handleKeyup(e) {
            if (e.keyCode == this.ctrlKey) {
                this.isCtrlDown = false
            }
        },

        handleMousedown(e) {
            if (this.canEdit) {
                e.stopPropagation()
            }
        },

        clearStyle(e) {
            e.preventDefault()
            const clp = e.clipboardData
            const text = clp.getData('text/plain') || ''
            if (text !== '') {
                document.execCommand('insertText', false, text)
            }

            this.$emit('input', this.element, e.target.innerHTML)
        },

        handleBlur(e) {
            this.element.propValue = e.target.innerHTML || '&nbsp;'
            this.canEdit = false
        },

        setEdit() {
            this.canEdit = true
            // Select all
            this.selectText(this.$refs.text)
        },

        selectText(element) {
            const selection = window.getSelection()
            const range = document.createRange()
            range.selectNodeContents(element)
            selection.removeAllRanges()
            selection.addRange(range)
        },
    },
}
</script>

<style lang="scss" scoped>
.v-text {
    width: 100%;
    height: 100%;
    display: table;

    div {
        display: table-cell;
        width: 100%;
        height: 100%;
        outline: none;
    }

    .canEdit {
        cursor: text;
        height: 100%;
    }
}
</style>

The redesigned VText component has the following functions:

Double-click to start editing.
Support for selecting text.
Filter out text styles when pasting.
Automatically expand the text box height when line breaking.

20. Rectangle component

The rectangle component is actually a DIV with an embedded VText text component.

<template>
    <div class="rect-shape">
        <v-text :propValue="element.propValue" :element="element" />
    </div>
</template>

<script>
export default {
    props: {
        element: {
            type: Object,
        },
    },
}
</script>

<style lang="scss" scoped>
.rect-shape {
    width: 100%;
    height: 100%;
    overflow: auto;
}
</style>

It has all the functionality of the VText text component and can be resized arbitrarily.

21. Lock component

I implemented the lock component feature mainly because I saw that processon and Modao have this feature. The specific requirements for locking a component are: it cannot be moved, scaled, rotated, copied, pasted, etc., only unlocking operations can be performed.

Its implementation principle is not difficult:

Add an isLock property to the custom component to indicate whether the component is locked.
When clicking on a component, hide the eight points and rotation icon on the component based on whether isLock is true.
To highlight that a component is locked, add an opacity property and a lock icon to it.
If a component is locked, gray out the buttons corresponding to the requirements mentioned above, making them unclickable.

Related code is as follows:

export const commonAttr = {
    animations: [],
    events: {},
    groupStyle: {}, // Used when a component becomes a child component of a Group
    isLock: false, // Whether to lock the component
}

<el-button @click="decompose" 
:disabled="!curComponent || curComponent.isLock || curComponent.component != 'Group'">Split</el-button>

<el-button @click="lock" :disabled="!curComponent || curComponent.isLock">Lock</el-button>
<el-button @click="unlock" :disabled="!curComponent || !curComponent.isLock">Unlock</el-button>

<template>
    <div class="contextmenu" v-show="menuShow" :style="{ top: menuTop + 'px', left: menuLeft + 'px' }">
        <ul @mouseup="handleMouseUp">
            <template v-if="curComponent">
                <template v-if="!curComponent.isLock">
                    <li @click="copy">Copy</li>
                    <li @click="paste">Paste</li>
                    <li @click="cut">Cut</li>
                    <li @click="deleteComponent">Delete</li>
                    <li @click="lock">Lock</li>
                    <li @click="topComponent">Bring to front</li>
                    <li @click="bottomComponent">Send to back</li>
                    <li @click="upComponent">Bring forward</li>
                    <li @click="downComponent">Send backward</li>
                </template>
                <li v-else @click="unlock">Unlock</li>
            </template>
            <li v-else @click="paste">Paste</li>
        </ul>
    </div>
</template>

22. Shortcuts

Supporting shortcuts is mainly to improve development efficiency, as clicking with the mouse is not as fast as pressing keyboard keys. Currently, the shortcuts support the following functions:

const ctrlKey = 17, 
    vKey = 86, // Paste
    cKey = 67, // Copy
    xKey = 88, // Cut

    yKey = 89, // Redo
    zKey = 90, // Undo

    gKey = 71, // Group
    bKey = 66, // Split

    lKey = 76, // Lock
    uKey = 85, // Unlock

    sKey = 83, // Save
    pKey = 80, // Preview
    dKey = 68, // Delete
    deleteKey = 46, // Delete
    eKey = 69 // Clear canvas

The implementation principle mainly uses window global monitoring of key events, and executes corresponding operations when keys that meet the conditions are triggered:

// Operations that are independent of component state
const basemap = {
    [vKey]: paste,
    [yKey]: redo,
    [zKey]: undo,
    [sKey]: save,
    [pKey]: preview,
    [eKey]: clearCanvas,
}

// Operations that can be performed when a component is locked
const lockMap = {
    ...basemap,
    [uKey]: unlock,
}

// Operations that can be performed when a component is not locked
const unlockMap = {
    ...basemap,
    [cKey]: copy,
    [xKey]: cut,
    [gKey]: compose,
    [bKey]: decompose,
    [dKey]: deleteComponent,
    [deleteKey]: deleteComponent,
    [lKey]: lock,
}

let isCtrlDown = false
// Global key event monitoring to execute corresponding commands
export function listenGlobalKeyDown() {
    window.onkeydown = (e) => {
        const { curComponent } = store.state
        if (e.keyCode == ctrlKey) {
            isCtrlDown = true
        } else if (e.keyCode == deleteKey && curComponent) {
            store.commit('deleteComponent')
            store.commit('recordSnapshot')
        } else if (isCtrlDown) {
            if (!curComponent || !curComponent.isLock) {
                e.preventDefault()
                unlockMap[e.keyCode] && unlockMap[e.keyCode]()
            } else if (curComponent && curComponent.isLock) {
                e.preventDefault()
                lockMap[e.keyCode] && lockMap[e.keyCode]()
            }
        }
    }

    window.onkeyup = (e) => {
        if (e.keyCode == ctrlKey) {
            isCtrlDown = false
        }
    }
}

To prevent conflicts with browser default shortcuts, we need to add e.preventDefault().

23. Grid lines

The grid lines feature is implemented using SVG:

<template>
    <svg class="grid" width="100%" height="100%" xmlns="http://www.w3.org/2000/svg">
        <defs>
            <pattern id="smallGrid" width="7.236328125" height="7.236328125" patternUnits="userSpaceOnUse">
                <path 
                    d="M 7.236328125 0 L 0 0 0 7.236328125" 
                    fill="none" 
                    stroke="rgba(207, 207, 207, 0.3)" 
                    stroke-width="1">
                </path>
            </pattern>
            <pattern id="grid" width="36.181640625" height="36.181640625" patternUnits="userSpaceOnUse">
                <rect width="36.181640625" height="36.181640625" fill="url(#smallGrid)"></rect>
                <path 
                    d="M 36.181640625 0 L 0 0 0 36.181640625" 
                    fill="none" 
                    stroke="rgba(186, 186, 186, 0.5)" 
                    stroke-width="1">
                </path>
            </pattern>
        </defs>
        <rect width="100%" height="100%" fill="url(#grid)"></rect>
    </svg>
</template>

<style lang="scss" scoped>
.grid {
    position: absolute;
    top: 0;
    left: 0;
}
</style>

For those who aren't familiar with SVG, I recommend checking out the MDN tutorial.

24. Another implementation method for editor snapshots

In the first article of this series, I already analyzed the implementation principle of snapshots.

snapshotData: [], // Editor snapshot data
snapshotIndex: -1, // Snapshot index

undo(state) {
    if (state.snapshotIndex >= 0) {
        state.snapshotIndex--
        store.commit('setComponentData', deepCopy(state.snapshotData[state.snapshotIndex]))
    }
},

redo(state) {
    if (state.snapshotIndex < state.snapshotData.length - 1) {
        state.snapshotIndex++
        store.commit('setComponentData', deepCopy(state.snapshotData[state.snapshotIndex]))
    }
},

setComponentData(state, componentData = []) {
    Vue.set(state, 'componentData', componentData)
},

recordSnapshot(state) {
    // Add a new snapshot
    state.snapshotData[++state.snapshotIndex] = deepCopy(state.componentData)
    // When adding a new snapshot during the undo process, clear the snapshots after it
    if (state.snapshotIndex < state.snapshotData.length - 1) {
        state.snapshotData = state.snapshotData.slice(0, state.snapshotIndex + 1)
    }
},

An array is used to save the editor's snapshot data. Saving a snapshot is continuously executing the push() operation, pushing the current editor data into the snapshotData array, and increasing the snapshot index snapshotIndex.

Since each time a snapshot is added, all the current editor's component data is pushed into snapshotData, the more snapshots saved, the more memory is used. There are two solutions to this:

Limit the number of snapshot steps, for example, only saving data for 50 steps.
Only save the differences when saving snapshots.

Now let me describe the second solution in detail.

Suppose we add components a, b, c, and d to the canvas in sequence. In the original implementation, the corresponding snapshotData would be:

// snapshotData
[
  [a],
  [a, b],
  [a, b, c],
  [a, b, c, d],
]

From the code above, we can see that between each adjacent snapshot, only one piece of data is different. So we can add a type field for each snapshot step to indicate whether this operation is an addition or a deletion.

Then for the above operation of adding four components, the corresponding snapshotData would be:

// snapshotData
[
  [{ type: 'add', value: a }],
  [{ type: 'add', value: b }],
  [{ type: 'add', value: c }],
  [{ type: 'add', value: d }],
]

If we want to delete component c, then the snapshotData would become:

// snapshotData
[
  [{ type: 'add', value: a }],
  [{ type: 'add', value: b }],
  [{ type: 'add', value: c }],
  [{ type: 'add', value: d }],
  [{ type: 'remove', value: c }],
]

So how do we use this snapshot data now?

We need to iterate through the snapshot data to generate the editor's component data componentData. Suppose we perform an undo operation on the above data:

// snapshotData
// Snapshot index snapshotIndex is now 3
[
  [{ type: 'add', value: a }],
  [{ type: 'add', value: b }],
  [{ type: 'add', value: c }],
  [{ type: 'add', value: d }],
  [{ type: 'remove', value: c }],
]

snapshotData[0] type is add, add component a to componentData, now componentData is [a]
Similarly, progress to [a, b]
[a, b, c]
[a, b, c, d]

If we now execute a redo operation, the snapshot index snapshotIndex becomes 4. The corresponding snapshot data type is type: 'remove', removing component c. The array data becomes [a, b, d].

This method is actually trading time for space. Although each saved snapshot only has one item, we need to iterate through all the snapshot data each time. Neither method is perfect, and which one to use depends on you. Currently, I'm still using the first method.

Summary

From the perspective of creating tools, this is my fourth relatively satisfying project, the other three being:

Creating projects is a great way to improve your technical skills, but you should create meaningful and challenging projects, and only create one of each type. After completing a project, you should also write a summary, ideally sharing it as an article.

References

Analysis of Key Technical Principles for a Visual Drag-and-Drop Component Library - 2

woai3c — Tue, 08 Apr 2025 09:52:54 +0000

This article is a supplement to "Analysis of Key Technical Principles for a Visual Drag-and-Drop Component Library". The previous article mainly explained the following functional points:

Editor
Custom Components
Drag and Drop
Deleting Components, Adjusting Layer Hierarchy
Zoom In and Out
Undo, Redo
Component Property Settings
Snapping
Preview, Save Code
Binding Events
Binding Animations
Importing PSD
Mobile Mode

This article will supplement 4 more functional points based on the previous ones:

Drag Rotation
Copy, Paste, Cut
Data Interaction
Publishing

Like the previous article, I have updated the new features to GitHub:

Friendly reminder: It is recommended to read this alongside the source code for better results (this DEMO uses the Vue technology stack).

14. Drag Rotation

When writing the previous article, the original DEMO already supported rotation functionality. However, this rotation function still had many imperfections:

It did not support drag rotation.
The zoom in and out after rotation was incorrect.
The automatic snapping after rotation was incorrect.
The cursor for the eight resizable points after rotation was incorrect.

In this section, we will solve these four problems one by one.

Drag Rotation

Drag rotation requires the use of the Math.atan2() function.

Math.atan2() returns the angle in the plane (in radians) between the positive x-axis and the ray from the origin (0,0) to the point (x,y), i.e., Math.atan2(y,x). The y and x in Math.atan2(y,x) are both distances relative to the center point (0,0).

Simply put, we set the component's center point as the origin (centerX,centerY), the coordinates when the user presses the mouse down as (startX,startY), and the coordinates when the mouse moves as (curX,curY). The rotation angle can be calculated using (startX,startY) and (curX,curY).

So how do we obtain the rotation angle from point (startX,startY) to point (curX,curY)?

Step one, set the coordinates when the mouse is clicked as (startX,startY):

const startY = e.clientY
const startX = e.clientX

Step two, calculate the component's center point:

// Get the position of the component's center point
const rect = this.$el.getBoundingClientRect()
const centerX = rect.left + rect.width / 2
const centerY = rect.top + rect.height / 2

Step three, set the coordinates when holding the mouse and moving as (curX,curY):

const curX = moveEvent.clientX
const curY = moveEvent.clientY

Step four, calculate the angles corresponding to (startX,startY) and (curX,curY) respectively, then subtract them to get the rotation angle. Additionally, it should be noted that the return value of the Math.atan2() method is a radian, so it needs to be converted to degrees. So the complete code is:

// Angle before rotation
const rotateDegreeBefore = Math.atan2(startY - centerY, startX - centerX) / (Math.PI / 180)
// Angle after rotation
const rotateDegreeAfter = Math.atan2(curY - centerY, curX - centerX) / (Math.PI / 180)
// Get the rotation angle value, startRotate is the initial angle value
pos.rotate = startRotate + rotateDegreeAfter - rotateDegreeBefore

Zoom In and Out

There is a bug with zoom in and out after the component has been rotated.

From the above image, you can see that displacement occurs when zooming in and out. Also, the direction of stretching does not match our dragging direction. The cause of this bug is: when initially designing the zoom functionality, rotation scenarios were not considered. So regardless of the rotation angle, the zoom calculations are still based on the unrotated state.

Let's look at a specific example:

From the above image, you can see that without rotation, when holding a vertex and dragging upward, you only need to use y2 - y1 to get the drag distance s. At this point, adding s to the original height of the component will give the new height, while also updating the component's top and left properties.

Now rotate 180 degrees, if you hold the vertex and drag downward, we expect the result to be an increase in the component's height. But the calculation method is the same as when there was no rotation, so the result is opposite to what we expect, the component's height will decrease (if you don't understand this phenomenon, imagine the unrotated image and holding the vertex dragging downward).

How to solve this problem? I found a solution from a GitHub project snapping-demo: associate the zoom with the rotation angle.

Solution

Below is a rectangle that has been rotated by a certain angle. Suppose now we drag the point at its top left to stretch it.

Now we will step by step analyze how to derive the correct size and displacement of the component after stretching.

Step one, when the mouse is pressed, calculate the center point of the component using the component's coordinates (regardless of the rotation angle, the component's top left properties don't change) and size:

const center = {
    x: style.left + style.width / 2,
    y: style.top + style.height / 2,
}

Step two, use the current click coordinates and the component's center point to calculate the symmetric point coordinates of the current click coordinates:

// Get canvas displacement information
const editorRectInfo = document.querySelector('#editor').getBoundingClientRect()

// Current click coordinates
const curPoint = {
    x: e.clientX - editorRectInfo.left,
    y: e.clientY - editorRectInfo.top,
}

// Get the coordinates of the symmetric point
const symmetricPoint = {
    x: center.x - (curPoint.x - center.x),
    y: center.y - (curPoint.y - center.y),
}

Step three, when stretching by holding the top left corner of the component, calculate the new component center point using the current mouse real-time coordinates and the symmetric point:

const curPositon = {
    x: moveEvent.clientX - editorRectInfo.left,
    y: moveEvent.clientY - editorRectInfo.top,
}

const newCenterPoint = getCenterPoint(curPositon, symmetricPoint)

// Calculate the coordinates of the midpoint between two points
function getCenterPoint(p1, p2) {
    return {
        x: p1.x + ((p2.x - p1.x) / 2),
        y: p1.y + ((p2.y - p1.y) / 2),
    }
}

Since the component is in a rotated state, even if you know the xy distance moved during stretching, you cannot directly calculate on the component. Otherwise, bugs will occur, such as displacement or incorrect zoom direction. Therefore, we need to calculate it when the component is not rotated.

Step four, based on the known rotation angle, new component center point, and current mouse real-time coordinates, we can calculate the coordinates newTopLeftPoint of the current mouse real-time coordinates currentPosition when not rotated. Similarly, we can also calculate the coordinates newBottomRightPoint of the component's symmetric point sPoint when not rotated based on the known rotation angle, new component center point, and symmetric point.

The corresponding calculation formula is as follows:

/**
 * Calculate the coordinates of a point after rotation around a center
 * @param   {Object}  point  The point coordinates before rotation
 * @param   {Object}  center Rotation center
 * @param   {Number}  rotate Angle of rotation
 * @return  {Object}         Coordinates after rotation
 * https://www.zhihu.com/question/67425734/answer/252724399 Rotation matrix formula
 */
export function calculateRotatedPointCoordinate(point, center, rotate) {
    /**
     * Rotation formula:
     *  Point a(x, y)
     *  Rotation center c(x, y)
     *  Point after rotation n(x, y)
     *  Rotation angle θ                tan ??
     * nx = cosθ * (ax - cx) - sinθ * (ay - cy) + cx
     * ny = sinθ * (ax - cx) + cosθ * (ay - cy) + cy
     */

    return {
        x: (point.x - center.x) * Math.cos(angleToRadian(rotate)) - (point.y - center.y) * Math.sin(angleToRadian(rotate)) + center.x,
        y: (point.x - center.x) * Math.sin(angleToRadian(rotate)) + (point.y - center.y) * Math.cos(angleToRadian(rotate)) + center.y,
    }
}

The above formula involves knowledge of rotation matrices in linear algebra, which is really difficult for someone who hasn't gone to college. Fortunately, I found the reasoning process of this formula from an answer on Zhihu, here is the original text of the answer:

Through the calculations above, you can get the component's new displacement values top left and the new component size. The corresponding complete code is as follows:

function calculateLeftTop(style, curPositon, pointInfo) {
    const { symmetricPoint } = pointInfo
    const newCenterPoint = getCenterPoint(curPositon, symmetricPoint)
    const newTopLeftPoint = calculateRotatedPointCoordinate(curPositon, newCenterPoint, -style.rotate)
    const newBottomRightPoint = calculateRotatedPointCoordinate(symmetricPoint, newCenterPoint, -style.rotate)

    const newWidth = newBottomRightPoint.x - newTopLeftPoint.x
    const newHeight = newBottomRightPoint.y - newTopLeftPoint.y
    if (newWidth > 0 && newHeight > 0) {
        style.width = Math.round(newWidth)
        style.height = Math.round(newHeight)
        style.left = Math.round(newTopLeftPoint.x)
        style.top = Math.round(newTopLeftPoint.y)
    }
}

Now let's look at the zoom in and out after rotation:

Automatic Snapping

Automatic snapping is calculated based on the component's four properties top left width height. After rotating the component, these property values do not change. So no matter how many degrees the component rotates, the snapping is still calculated as if it were not rotated. This poses a problem: although the component's top left width height properties have not changed in actuality, they have changed in appearance. Below are two identical components: one not rotated, one rotated 45 degrees.

You can see that after rotation, the button's height property is different from the height we see in appearance, so in this case, the snapping incorrectly bug occurs.

Solution

How to solve this problem? We need to use the size and displacement of the component after rotation for snapping comparison. That is, don't compare the actual properties of the component, but compare the size and displacement we see.

From the above image, you can see that the projection length of the rotated component on the x-axis is the sum of the lengths of the two red lines. The lengths of these two red lines can be calculated using sine and cosine, the left red line using sine and the right red line using cosine:

const newWidth = style.width * cos(style.rotate) + style.height * sin(style.rotate)

Similarly, the height is also calculated:

const newHeight = style.height * cos(style.rotate) + style.width * sin(style.rotate)

With the new width and height, and based on the component's original top left properties, we can derive the component's new top left properties after rotation. Here is the complete code:

translateComponentStyle(style) {
    style = { ...style }
    if (style.rotate != 0) {
        const newWidth = style.width * cos(style.rotate) + style.height * sin(style.rotate)
        const diffX = (style.width - newWidth) / 2
        style.left += diffX
        style.right = style.left + newWidth

        const newHeight = style.height * cos(style.rotate) + style.width * sin(style.rotate)
        const diffY = (newHeight - style.height) / 2
        style.top -= diffY
        style.bottom = style.top + newHeight

        style.width = newWidth
        style.height = newHeight
    } else {
        style.bottom = style.top + style.height
        style.right = style.left + style.width
    }

    return style
}

After the fix, the snapping also displays correctly.

Cursor

The cursor and the draggable direction are mismatched because the cursors of the eight points are fixed settings, not changing with the angle.

Solution

Since 360 / 8 = 45, we can allocate a range of 45 degrees for each direction, with each range corresponding to a cursor. At the same time, set an initial angle for each direction, which is the angle corresponding to each direction of the component when not rotated.

pointList: ['lt', 't', 'rt', 'r', 'rb', 'b', 'lb', 'l'], // Eight directions
initialAngle: { // Initial angle corresponding to each point
    lt: 0,
    t: 45,
    rt: 90,
    r: 135,
    rb: 180,
    b: 225,
    lb: 270,
    l: 315,
},
angleToCursor: [ // Cursor corresponding to each angle range
    { start: 338, end: 23, cursor: 'nw' },
    { start: 23, end: 68, cursor: 'n' },
    { start: 68, end: 113, cursor: 'ne' },
    { start: 113, end: 158, cursor: 'e' },
    { start: 158, end: 203, cursor: 'se' },
    { start: 203, end: 248, cursor: 's' },
    { start: 248, end: 293, cursor: 'sw' },
    { start: 293, end: 338, cursor: 'w' },
],
cursors: {},

The calculation method is also simple:

Suppose the component has now rotated a certain angle a.
Iterate through the eight directions, add a to the initial angle of each direction to get the current angle b.
Iterate through the angleToCursor array to see in which range b falls, then return the corresponding cursor.

After the above three steps, you can calculate the correct cursor direction after the component has rotated. The specific code is as follows:

getCursor() {
    const { angleToCursor, initialAngle, pointList, curComponent } = this
    const rotate = (curComponent.style.rotate + 360) % 360 // Prevent negative angles, so + 360
    const result = {}
    let lastMatchIndex = -1 // Start matching the next one from the index of the last hit, reducing time complexity
    pointList.forEach(point => {
        const angle = (initialAngle[point] + rotate) % 360
        const len = angleToCursor.length
        while (true) {
            lastMatchIndex = (lastMatchIndex + 1) % len
            const angleLimit = angleToCursor[lastMatchIndex]
            if (angle < 23 || angle >= 338) {
                result[point] = 'nw-resize'
                return
            }

            if (angleLimit.start <= angle && angle < angleLimit.end) {
                result[point] = angleLimit.cursor + '-resize'
                return
            }
        }
    })

    return result
},

From the above GIF, you can see that the cursor on all eight directions now displays correctly.

15. Copy, Paste, Cut

Compared to the drag rotation function, copy and paste are simpler.

const ctrlKey = 17, vKey = 86, cKey = 67, xKey = 88
let isCtrlDown = false

window.onkeydown = (e) => {
    if (e.keyCode == ctrlKey) {
        isCtrlDown = true
    } else if (isCtrlDown && e.keyCode == cKey) {
        this.$store.commit('copy')
    } else if (isCtrlDown && e.keyCode == vKey) {
        this.$store.commit('paste')
    } else if (isCtrlDown && e.keyCode == xKey) {
        this.$store.commit('cut')
    }
}

window.onkeyup = (e) => {
    if (e.keyCode == ctrlKey) {
        isCtrlDown = false
    }
}

Monitor the user's key operations and trigger the corresponding operation when specific keys are pressed.

Copy Operation

In vuex, copyData is used to represent the copied data. When the user presses ctrl + c, deep copy the current component data to copyData.

copy(state) {
    state.copyData = {
        data: deepCopy(state.curComponent),
        index: state.curComponentIndex,
    }
},

At the same time, the index of the current component in the component data needs to be recorded, which will be used in the cut operation.

Paste Operation

paste(state, isMouse) {
    if (!state.copyData) {
        toast('Please select a component')
        return
    }

    const data = state.copyData.data

    if (isMouse) {
        data.style.top = state.menuTop
        data.style.left = state.menuLeft
    } else {
        data.style.top += 10
        data.style.left += 10
    }

    data.id = generateID()
    store.commit('addComponent', { component: data })
    store.commit('recordSnapshot')
    state.copyData = null
},

When pasting, if it's a key operation ctrl+v, add 10 to the component's top left properties to avoid overlapping with the original component. If using the right mouse button to execute the paste operation, place the copied component at the mouse click location.

Cut Operation

cut(state) {
    if (!state.curComponent) {
        toast('Please select a component')
        return
    }

    if (state.copyData) {
        store.commit('addComponent', { component: state.copyData.data, index: state.copyData.index })
        if (state.curComponentIndex >= state.copyData.index) {
            // If the current component index is greater than or equal to the insertion index, it needs to be incremented by one, because the current component has moved back one position
            state.curComponentIndex++
        }
    }

    store.commit('copy')
    store.commit('deleteComponent')
},

The cut operation is essentially still a copy, but after executing the copy, the current component needs to be deleted. To avoid the situation where the user executes a cut operation and then, instead of executing a paste operation, continues to execute cut, we need to restore the previously cut data. This is where the index recorded in the copy data comes into play, allowing us to restore the original data to its original position through the index.

Right-Click Operation

The right-click operation is the same as the key operation, one function with two triggering paths.

<li @click="copy" v-show="curComponent">Copy</li>
<li @click="paste">Paste</li>
<li @click="cut" v-show="curComponent">Cut</li>

cut() {
    this.$store.commit('cut')
},

copy() {
    this.$store.commit('copy')
},

paste() {
    this.$store.commit('paste', true)
},

16. Data Interaction

Method One

Prepare a series of ajax request APIs in advance, select the API as needed when clicking on a component, and then fill in the parameters after selecting the API. For example, the following component shows how to use ajax requests to interact with the backend:

<template>
    <div>{{ propValue.data }}</div>
</template>

<script>
export default {
    // propValue: {
    //     api: {
    //             request: a,
    //             params,
    //      },
    //     data: null
    // }
    props: {
        propValue: {
            type: Object,
            default: () => {},
        },
    },
    created() {
        this.propValue.api.request(this.propValue.api.params).then(res => {
            this.propValue.data = res.data
        })
    },
}
</script>

Method Two

Method two is suitable for purely display components. For example, there is an alarm component that can display the corresponding color based on data from the backend. In the editing page, you can request the websocket data available to the page through ajax:

const data = ['status', 'text'...]

Then add different properties for different components. For example, there is a component a, whose bound property is status.

// Data that the component can receive
props: {
    propValue: {
        type: String,
    },
    element: {
        type: Object,
    },
    wsKey: {
        type: String,
        default: '',
    },
},

In the component, get this bound property through wsKey. After the page is published or previewed, request global data through websocket and place it on vuex. Then the component can access the data through wsKey.

<template>
    <div>{{ wsData[wsKey] }}</div>
</template>

<script>
import { mapState } from 'vuex'

export default {
    props: {
        propValue: {
            type: String,
        },
        element: {
            type: Object,
        },
        wsKey: {
            type: String,
            default: '',
        },
    },
    computed: mapState([
        'wsData',
    ]),
</script>

There are many ways to interact with the backend, not just the two methods above. I'm just providing some ideas here for reference.

17. Publishing

There are two ways to publish a page: one is to render the component data as a separate HTML page; the other is to extract a minimum runtime from this project as a separate project.

Let me talk about the second method. The minimum runtime in this project is actually the preview page plus custom components. Extract this code as a project and package it separately. When publishing a page, pass the component data to the server in JSON format, and generate a unique ID for each page.

Suppose there are now three pages, the IDs generated for the published pages are a, b, c. When accessing a page, you just need to bring the ID, so you can get the component data corresponding to each page based on the ID.

www.test.com/?id=a
www.test.com/?id=c
www.test.com/?id=b

Lazy Loading

If there are too many custom components, for example, dozens or even hundreds. At this time, custom components can be imported using the import method to achieve lazy loading, reducing the first screen rendering time:

import Vue from 'vue'

const components = [
    'Picture',
    'VText',
    'VButton',
]

components.forEach(key => {
    Vue.component(key, () => import(`@/custom-component/${key}`))
})

Publish by Version

Custom components may have updates. For example, the original components have been used for half a year, and now there are functional changes. In order not to affect the original pages, it is recommended to bring the version number of the component when publishing:

- v-text
  - v1.vue
  - v2.vue

For example, the v-text component has two versions, when using it in the left component list area, you can bring the version number:

{
  component: 'v-text',
  version: 'v1'
  ...
}

This way, when importing components, you can import them according to the component version number:

import Vue from 'vue'
import componentList from '@/custom-component/component-list`

componentList.forEach(component => {
    Vue.component(component.name, () => import(`@/custom-component/${component.name}/${component.version}`))
})

References

Analysis of Key Technical Principles for a Visual Drag-and-Drop Component Library

woai3c — Mon, 07 Apr 2025 12:09:35 +0000

Analysis of the Following Technical Points:

Editor
Custom Components
Drag and Drop
Deleting Components, Adjusting Layer Hierarchy
Zoom In and Out
Undo, Redo
Component Property Settings
Snapping
Preview, Save Code
Binding Events
Binding Animations
Importing PSD
Mobile Mode

To make this article easier to understand, I have combined the above technical points to create a visual drag-and-drop component library DEMO:

I recommend reading this alongside the source code for better results (this DEMO uses the Vue technology stack).

1. Editor

Let's first look at the overall structure of the page.

The editor discussed in this section is actually the canvas in the middle. Its role is: when a component is dragged from the left component list to the canvas, the canvas needs to render this component.

The implementation approach for this editor is:

Use an array componentData to maintain the data in the editor.
When a component is dragged to the canvas, use the push() method to add the new component data to componentData.
The editor uses the v-for directive to iterate through componentData, rendering each component one by one onto the canvas (you can also use JSX syntax with the render() method instead).

The core code for editor rendering is as follows:

<component
  v-for="item in componentData"
  :key="item.id"
  :is="item.component"
  :style="item.style"
  :propValue="item.propValue"
/>

Each component's data roughly looks like this:

{
    component: 'v-text', // Component name, needs to be pre-registered in Vue
    label: 'Text', // Name displayed in the left component list
    propValue: 'Text', // Value used by the component
    icon: 'el-icon-edit', // Icon displayed in the left component list
    animations: [], // Animation list
    events: {}, // Event list
    style: { // Component styles
        width: 200,
        height: 33,
        fontSize: 14,
        fontWeight: 500,
        lineHeight: '',
        letterSpacing: 0,
        textAlign: '',
        color: '',
    },
}

When iterating through the componentData, the is attribute is mainly used to identify which component should actually be rendered.

For example, if the component data to be rendered is { component: 'v-text' }, then <component :is="item.component" /> will be converted to <v-text />. Of course, you need to register this component in Vue beforehand.

If you want to learn more about the is attribute, please check the official documentation.

2. Custom Components

In principle, using third-party components is also possible, but it's recommended that you encapsulate them. Whether third-party components or custom components, each component may require different properties, so each component's data can expose a property called propValue for passing values.

For example, if component a only needs one property, your propValue can be written like this: propValue: 'aaa'. If multiple properties are needed, propValue can be an object:

propValue: {
  a: 1,
  b: 'text'
}

In this DEMO component library, I defined three components.

Image component Picture:

<template>
  <div style="overflow: hidden">
    <img :src="propValue" />
  </div>
</template>

<script>
  export default {
    props: {
      propValue: {
        type: String,
        require: true,
      },
    },
  }
</script>

Button component VButton:

<template>
  <button class="v-button">{{ propValue }}</button>
</template>

<script>
  export default {
    props: {
      propValue: {
        type: String,
        default: '',
      },
    },
  }
</script>

Text component VText:

<template>
    <textarea
        v-if="editMode == 'edit'"
        :value="propValue"
        class="text textarea"
        @input="handleInput"
        ref="v-text"
    ></textarea>
    <div v-else class="text disabled">
        <div v-for="(text, index) in propValue.split('\n')" :key="index">{{ text }}</div>
    </div>
</template>

<script>
import { mapState } from 'vuex'

export default {
    props: {
        propValue: {
            type: String,
        },
        element: {
            type: Object,
        },
    },
    computed: mapState([
        'editMode',
    ]),
    methods: {
        handleInput(e) {
            this.$emit('input', this.element, e.target.value)
        },
    },
}
</script>

3. Drag and Drop

From Component List to Canvas

For an element to be made draggable, it must have a draggable attribute added to it. Additionally, when dragging components from the component list to the canvas, two events play a key role:

The dragstart event, triggered at the beginning of the drag. It's mainly used to pass the dragged component information to the canvas.
The drop event, triggered at the end of the drag. Mainly used to receive the dragged component information.

Let's first look at the code for the left component list:

<div @dragstart="handleDragStart" class="component-list">
  <div v-for="(item, index) in componentList" :key="index" class="list" draggable :data-index="index">
    <i :class="item.icon"></i>
    <span>{{ item.label }}</span>
  </div>
</div>

handleDragStart(e) {
    e.dataTransfer.setData('index', e.target.dataset.index)
}

You can see that the draggable attribute is set for each component in the list. Additionally, when the dragstart event is triggered, data is transmitted using dataTransfer.setData(). Now let's look at the code for receiving data:

<div class="content" @drop="handleDrop" @dragover="handleDragOver" @click="deselectCurComponent">
  <Editor />
</div>

handleDrop(e) {
    e.preventDefault()
    e.stopPropagation()
    const component = deepCopy(componentList[e.dataTransfer.getData('index')])
    this.$store.commit('addComponent', component)
}

When the drop event is triggered, dataTransfer.getData() is used to receive the transmitted index data, then the corresponding component data is found based on this index, and finally added to the canvas to render the component.

Moving Components on the Canvas

First, the canvas needs to be set to relative positioning position: relative, and then each component needs to be set to absolute positioning position: absolute. Apart from this, three events need to be monitored for movement:

The mousedown event, when the mouse is pressed on a component, record the component's current position, i.e., xy coordinates (for ease of explanation, I'm using coordinate axis here, but in reality, xy corresponds to left and top in CSS).
The mousemove event, each time the mouse moves, subtract the initial xy coordinates from the latest xy coordinates to calculate the distance moved, and then change the component's position.
The mouseup event, which ends the movement when the mouse is lifted.

handleMouseDown(e) {
    e.stopPropagation()
    this.$store.commit('setCurComponent', { component: this.element, zIndex: this.zIndex })

    const pos = { ...this.defaultStyle }
    const startY = e.clientY
    const startX = e.clientX
    // To avoid the value type becoming a string when modifying properties directly, convert to numeric type
    const startTop = Number(pos.top)
    const startLeft = Number(pos.left)

    const move = (moveEvent) => {
        const currX = moveEvent.clientX
        const currY = moveEvent.clientY
        pos.top = currY - startY + startTop
        pos.left = currX - startX + startLeft
        // Modify the current component style
        this.$store.commit('setShapeStyle', pos)
    }

    const up = () => {
        document.removeEventListener('mousemove', move)
        document.removeEventListener('mouseup', up)
    }

    document.addEventListener('mousemove', move)
    document.addEventListener('mouseup', up)
}

PS: Many users have reported lag when dragging; the solution is simple: just close your browser's console.

4. Deleting Components, Adjusting Layer Hierarchy

Changing Layer Hierarchy

Since dragging components to the canvas has a sequential order, we can allocate layer hierarchy based on the data order.

For example, if five components abcde are added to the canvas, their order in the canvas data is [a, b, c, d, e]. The layer hierarchy corresponds to the index one-to-one, meaning their z-index attribute values are 01234 (last one on top). This can be expressed in code as follows:

<div v-for="(item, index) in componentData" :zIndex="index"></div>

If you're not familiar with the z-index attribute, please check the MDN documentation.

With this understanding, changing the layer hierarchy becomes easy. Changing the layer hierarchy means changing the order of component data in the componentData array. For example, with three components [a, b, c], their layer hierarchy from low to high is abc (the larger the index, the higher the layer).

If you want to move component b up, just swap it with c:

const temp = componentData[1]
componentData[1] = componentData[2]
componentData[2] = temp

Similarly, for moving to the top or bottom, for example, to move component a to the top, just swap a with the last component:

const temp = componentData[0]
componentData[0] = componentData[componentData.lenght - 1]
componentData[componentData.lenght - 1] = temp

Deleting Components

Deleting components is very simple, just one line of code: componentData.splice(index, 1).

5. Zoom In and Out

Observant users may notice that when clicking on a component on the canvas, eight small dots appear on the component. These eight dots are used for zooming. The implementation principle is as follows:

1. Wrap each component in a `Shape` component, which contains 8 small dots and a `<slot>` for placing the component.

<!--Page component list display-->
<Shape
  v-for="(item, index) in componentData"
  :defaultStyle="item.style"
  :style="getShapeStyle(item.style, index)"
  :key="item.id"
  :active="item === curComponent"
  :element="item"
  :zIndex="index"
>
  <component
    class="component"
    :is="item.component"
    :style="getComponentStyle(item.style)"
    :propValue="item.propValue"
  />
</Shape>

Internal structure of the Shape component:

<template>
  <div
    class="shape"
    :class="{ active: this.active }"
    @click="selectCurComponent"
    @mousedown="handleMouseDown"
    @contextmenu="handleContextMenu"
  >
    <div
      class="shape-point"
      v-for="(item, index) in (active? pointList : [])"
      @mousedown="handleMouseDownOnPoint(item)"
      :key="index"
      :style="getPointStyle(item)"
    ></div>
    <slot></slot>
  </div>
</template>

2. When clicking on a component, display the 8 small dots.

This is achieved through the code line :active="item === curComponent".

3. Calculate the position of each small dot.

Let's look at the code for calculating the position of the small dots:

const pointList = ['t', 'r', 'b', 'l', 'lt', 'rt', 'lb', 'rb']

getPointStyle(point) {
    const { width, height } = this.defaultStyle
    const hasT = /t/.test(point)
    const hasB = /b/.test(point)
    const hasL = /l/.test(point)
    const hasR = /r/.test(point)
    let newLeft = 0
    let newTop = 0

    // Four corner dots
    if (point.length === 2) {
        newLeft = hasL? 0 : width
        newTop = hasT? 0 : height
    } else {
        // Top and bottom dots, width centered
        if (hasT || hasB) {
            newLeft = width / 2
            newTop = hasT? 0 : height
        }

        // Left and right dots, height centered
        if (hasL || hasR) {
            newLeft = hasL? 0 : width
            newTop = Math.floor(height / 2)
        }
    }

    const style = {
        marginLeft: hasR? '-4px' : '-3px',
        marginTop: '-3px',
        left: `${newLeft}px`,
        top: `${newTop}px`,
        cursor: point.split('').reverse().map(m => this.directionKey[m]).join('') + '-resize',
    }

    return style
}

Calculating the position of the small dots requires some information:

Component height height and width width

Note that the small dots are also absolutely positioned, relative to the Shape component. So the positions of four of the small dots are easy to determine:

Top-left dot, coordinates left: 0, top: 0
Top-right dot, coordinates left: width, top: 0
Bottom-left dot, coordinates left: 0, top: height
Bottom-right dot, coordinates left: width, top: height

The other four dots need to be calculated indirectly. For example, the middle-left dot's calculation formula is left: 0, top: height / 2, and similar for the other dots.

4. When clicking on a small dot, zooming operations can be performed.

handleMouseDownOnPoint(point) {
    const downEvent = window.event
    downEvent.stopPropagation()
    downEvent.preventDefault()

    const pos = { ...this.defaultStyle }
    const height = Number(pos.height)
    const width = Number(pos.width)
    const top = Number(pos.top)
    const left = Number(pos.left)
    const startX = downEvent.clientX
    const startY = downEvent.clientY

    // Whether a snapshot needs to be saved
    let needSave = false
    const move = (moveEvent) => {
        needSave = true
        const currX = moveEvent.clientX
        const currY = moveEvent.clientY
        const disY = currY - startY
        const disX = currX - startX
        const hasT = /t/.test(point)
        const hasB = /b/.test(point)
        const hasL = /l/.test(point)
        const hasR = /r/.test(point)
        const newHeight = height + (hasT? -disY : hasB? disY : 0)
        const newWidth = width + (hasL? -disX : hasR? disX : 0)
        pos.height = newHeight > 0? newHeight : 0
        pos.width = newWidth > 0? newWidth : 0
        pos.left = left + (hasL? disX : 0)
        pos.top = top + (hasT? disY : 0)
        this.$store.commit('setShapeStyle', pos)
    }

    const up = () => {
        document.removeEventListener('mousemove', move)
        document.removeEventListener('mouseup', up)
        needSave && this.$store.commit('recordSnapshot')
    }

    document.addEventListener('mousemove', move)
    document.addEventListener('mouseup', up)
}

The principle is as follows:

When clicking on a small dot, record the clicked xy coordinates.
Let's say we drag downward, so the y coordinate increases.
Subtract the original y coordinate from the new y coordinate to determine how far we've moved in the vertical direction.
Finally, add the movement distance to the original component height to get the new component height.
If it's positive, it means we're dragging downward, increasing the component's height. If negative, we're dragging upward, decreasing the component's height.

6. Undo, Redo

The principle of undo and redo is actually quite simple, let's look at the code first:

snapshotData: [], // Editor snapshot data
snapshotIndex: -1, // Snapshot index

undo(state) {
    if (state.snapshotIndex >= 0) {
        state.snapshotIndex--
        store.commit('setComponentData', deepCopy(state.snapshotData[state.snapshotIndex]))
    }
},

redo(state) {
    if (state.snapshotIndex < state.snapshotData.length - 1) {
        state.snapshotIndex++
        store.commit('setComponentData', deepCopy(state.snapshotData[state.snapshotIndex]))
    }
},

setComponentData(state, componentData = []) {
    Vue.set(state, 'componentData', componentData)
},

recordSnapshot(state) {
    // Add a new snapshot
    state.snapshotData[++state.snapshotIndex] = deepCopy(state.componentData)
    // During the undo process, when adding a new snapshot, clear the snapshots after it
    if (state.snapshotIndex < state.snapshotData.length - 1) {
        state.snapshotData = state.snapshotData.slice(0, state.snapshotIndex + 1)
    }
},

An array is used to save the editor's snapshot data. Saving a snapshot is a continuous push() operation, pushing the current editor data into the snapshotData array and increasing the snapshot index snapshotIndex. Currently, the following actions trigger the snapshot save operation:

Adding a component
Deleting a component
Changing layer hierarchy
When dragging components ends ...

Undo

Let's say snapshotData has saved 4 snapshots. That is, [a, b, c, d], with a corresponding snapshot index of 3. If an undo operation is performed now, we need to decrease the snapshot index by 1, and then assign the corresponding snapshot data to the canvas.

For example, if the current canvas data is d, after an undo, the index is -1, and now the canvas data is c.

Redo

With undo understood, redo is easy to comprehend—it's increasing the snapshot index by 1, and then assigning the corresponding snapshot data to the canvas.

However, there's one thing to note: what if a new operation is performed during the undo operation? There are two solutions:

Replace all data after the current snapshot index with the new operation. Using the data [a, b, c, d] from earlier as an example, let's say two undo operations have been performed, making the snapshot index 1, corresponding to snapshot data b. If a new operation is performed at this time, corresponding to snapshot data e, then e will replace cd, and the snapshot data becomes [a, b, e].
Don't replace data, but add a new record to the original snapshot. Using the previous example, e won't replace cd but will be inserted before cd, making the snapshot data [a, b, e, c, d].

I've adopted the first approach.

7. Snapping

What is snapping? When dragging a component, if it's relatively close to another component, it will automatically snap to it.

The snapping code is about 300 lines long, so I suggest looking at the source code file directly (file path: src\components\Editor\MarkLine.vue). I won't paste the code here, but I'll explain the principle of how it's implemented.

Markers

Create 6 lines on the page, 3 horizontal and 3 vertical. These 6 lines serve for alignment. When do they appear?

Vertical lines appear when two components in the up-down direction align on the left, middle, or right
Horizontal lines appear when two components in the left-right direction align on the top, middle, or bottom

The specific calculation formulas are mainly based on the xy coordinates and width/height of each component. For example, to determine if the left sides of two components a and b are aligned, we need to know the x-coordinate of each component; to determine if their right sides are aligned, we need to know not only the x-coordinate but also the width of each component.

// Condition for left alignment
a.x == b.x

// Condition for right alignment
a.x + a.width == b.x + b.width

The markers are displayed during alignment.

Additionally, we need to determine if components a and b are "close enough". If they're close enough, they snap together. Whether they're close enough is determined by a variable:

diff: 3, // Will automatically snap when within diff pixels

Automatic snapping occurs when less than or equal to diff pixels apart.

Snapping

How is the snapping effect implemented?

Let's say we have components a and b, with a's x and y coordinates both at 0, and its width and height both at 100. Now assume component a is stationary and we're dragging component b. When b is dragged to coordinates x: 0, y: 103, since 103 - 100 <= 3(diff), we can determine they're close enough. At this point, we manually set b's y-coordinate to 100, thus snapping components a and b together.

Optimization

Having all 6 markers displayed during dragging might not look aesthetically pleasing. So we can optimize it so that at most one line is displayed in each direction simultaneously. The implementation principle is as follows:

Component a is on the left and stationary, while we drag component b towards a.
At this point, the first alignment is between a's right side and b's left side, so only one line is needed.
If components a and b are already close, and b continues to move to the left, we now need to determine if their middles are aligned.
As b continues to be dragged, we need to determine if a's left side and b's right side are aligned, again needing just one line.

We can see that the key is knowing the direction of the two components. That is, when components a and b are close, we need to know whether b is to the left or right of a.

This can be determined through the mouse movement event. As mentioned earlier when discussing dragging, the mousedown event records the starting coordinates. So each time the mousemove event is triggered, by subtracting the original coordinates from the current ones, we can determine the component's direction. For example, in the x-direction, if the difference b.x - a.x is positive, b is to the right of a; otherwise, it's to the left.

// Trigger element movement event, used for displaying markers and snapping functionality
// The last two parameters represent the mouse movement direction
// currY - startY > 0 true means moving downward, false means moving upward
// currX - startX > 0 true means moving to the right, false means moving to the left
eventBus.$emit('move', this.$el, currY - startY > 0, currX - startX > 0)

8. Component Property Settings

Each component has some common properties and unique properties, so we need to provide a place to display and modify these properties.

// Each component's data is roughly like this
{
    component: 'v-text', // Component name, needs to be pre-registered in Vue
    label: 'Text', // Name displayed in the left component list
    propValue: 'Text', // Value used by the component
    icon: 'el-icon-edit', // Icon displayed in the left component list
    animations: [], // Animation list
    events: {}, // Event list
    style: { // Component styles
        width: 200,
        height: 33,
        fontSize: 14,
        fontWeight: 500,
        lineHeight: '',
        letterSpacing: 0,
        textAlign: '',
        color: '',
    },
}

I defined an AttrList component to display each component's properties.

<template>
  <div class="attr-list">
    <el-form>
      <el-form-item v-for="(key, index) in styleKeys" :key="index" :label="map[key]">
        <el-color-picker v-if="key == 'borderColor'" v-model="curComponent.style[key]"></el-color-picker>
        <el-color-picker v-else-if="key == 'color'" v-model="curComponent.style[key]"></el-color-picker>
        <el-color-picker v-else-if="key == 'backgroundColor'" v-model="curComponent.style[key]"></el-color-picker>
        <el-select v-else-if="key == 'textAlign'" v-model="curComponent.style[key]">
          <el-option v-for="item in options" :key="item.value" :label="item.label" :value="item.value"></el-option>
        </el-select>
        <el-input type="number" v-else v-model="curComponent.style[key]" />
      </el-form-item>
      <el-form-item
        label="Content"
        v-if="curComponent && curComponent.propValue && !excludes.includes(curComponent.component)"
      >
        <el-input type="textarea" v-model="curComponent.propValue" />
      </el-form-item>
    </el-form>
  </div>
</template>

The code logic is simple: iterate through the component's style object, looping through each property. Different components need to be used to display different properties; for example, color properties need to be displayed with a color picker, while numeric properties need to be displayed with an input component of type=number, and so on.

To make it convenient for users to modify property values, I've used v-model to bind the component and value together.

9. Preview, Save Code

The rendering principles for preview and editing are the same, the difference being that preview doesn't need editing functionality. So we just need to slightly modify the code that renders components.

<!--Page component list display-->
<Shape
  v-for="(item, index) in componentData"
  :defaultStyle="item.style"
  :style="getShapeStyle(item.style, index)"
  :key="item.id"
  :active="item === curComponent"
  :element="item"
  :zIndex="index"
>
  <component
    class="component"
    :is="item.component"
    :style="getComponentStyle(item.style)"
    :propValue="item.propValue"
  />
</Shape>

From the previous introductions, we know that the Shape component has drag-and-drop and resizing functionalities. Now we just need to remove the Shape component and change the outer container to a regular DIV (actually, we could do without this DIV, but for event binding functionality, we need to add it).

<!--Page component list display-->
<div v-for="(item, index) in componentData" :key="item.id">
  <component
    class="component"
    :is="item.component"
    :style="getComponentStyle(item.style)"
    :propValue="item.propValue"
  />
</div>

The code-saving feature is also very simple, just save the canvas data componentData. There are two options for saving:

Save to the server
Save locally

In the DEMO, I use localStorage to save locally.

10. Binding Events

Each component has an events object used to store bound events. Currently, I've only defined two events:

alert event
redirect event

// Editor custom events
const events = {
  redirect(url) {
    if (url) {
      window.location.href = url
    }
  },

  alert(msg) {
    if (msg) {
      alert(msg)
    }
  },
}

const mixins = {
  methods: events,
}

const eventList = [
  {
    key: 'redirect',
    label: 'Redirect Event',
    event: events.redirect,
    param: '',
  },
  {
    key: 'alert',
    label: 'Alert Event',
    event: events.alert,
    param: '',
  },
]

export { mixins, events, eventList }

However, these events can't be triggered during editing but can be triggered during preview.

Adding Events

Render the event list using the v-for directive:

<el-tabs v-model="eventActiveName">
  <el-tab-pane v-for="item in eventList" :key="item.key" :label="item.label" :name="item.key" style="padding: 0 20px">
    <el-input
      v-if="item.key == 'redirect'"
      v-model="item.param"
      type="textarea"
      placeholder="Please enter the complete URL"
    />
    <el-input
      v-if="item.key == 'alert'"
      v-model="item.param"
      type="textarea"
      placeholder="Please enter the content to alert"
    />
    <el-button style="margin-top: 20px;" @click="addEvent(item.key, item.param)">Confirm</el-button>
  </el-tab-pane>
</el-tabs>

When an event is selected, it's added to the component's events object.

Triggering Events

When previewing or actually rendering the page, each component also needs to be wrapped in a DIV. This way, a click event can be bound to the DIV, which triggers the events we added earlier when clicked.

<template>
  <div @click="handleClick">
    <component class="conponent" :is="config.component" :style="getStyle(config.style)" :propValue="config.propValue" />
  </div>
</template>

handleClick() {
    const events = this.config.events
    // Loop through and trigger bound events
    Object.keys(events).forEach(event => {
        this[event](events[event])
    })
}

11. Binding Animations

Animations work on the same principle as events: first render all animations using the v-for directive, then click on an animation to add the corresponding animation to the component's animations array. Just like with events, when executing, all of the component's animations are iterated through and executed.

For convenience, we use the animate.css animation library.

// main.js
import '@/styles/animate.css'

Now let's predefine all the animation data:

export default [
  {
    label: 'Enter',
    children: [
      { label: 'Fade In', value: 'fadeIn' },
      { label: 'Enter from Right', value: 'fadeInLeft' },
      { label: 'Enter from Left', value: 'fadeInRight' },
      { label: 'Enter from Top', value: 'fadeInUp' },
      { label: 'Enter from Bottom', value: 'fadeInDown' },
      { label: 'Enter from Right Long Distance', value: 'fadeInLeftBig' },
      { label: 'Enter from Left Long Distance', value: 'fadeInRightBig' },
      { label: 'Enter from Top Long Distance', value: 'fadeInUpBig' },
      { label: 'Enter from Bottom Long Distance', value: 'fadeInDownBig' },
      { label: 'Rotate In', value: 'rotateIn' },
      { label: 'Rotate Clockwise from Left', value: 'rotateInDownLeft' },
      { label: 'Rotate Counter-clockwise from Right', value: 'rotateInDownRight' },
      { label: 'Rotate Counter-clockwise from Left', value: 'rotateInUpLeft' },
      { label: 'Rotate Counter-clockwise from Right', value: 'rotateInUpRight' },
      { label: 'Bounce In', value: 'bounceIn' },
      { label: 'Bounce In from Right', value: 'bounceInLeft' },
      { label: 'Bounce In from Left', value: 'bounceInRight' },
      { label: 'Bounce In from Top', value: 'bounceInUp' },
      { label: 'Bounce In from Bottom', value: 'bounceInDown' },
      { label: 'Light Speed from Right', value: 'lightSpeedInRight' },
      { label: 'Light Speed from Left', value: 'lightSpeedInLeft' },
      { label: 'Light Speed Exit Right', value: 'lightSpeedOutRight' },
      { label: 'Light Speed Exit Left', value: 'lightSpeedOutLeft' },
      { label: 'Y-axis Rotation', value: 'flip' },
      { label: 'Center X-axis Rotation', value: 'flipInX' },
      { label: 'Center Y-axis Rotation', value: 'flipInY' },
      { label: 'Long Left Radius Rotation', value: 'rollIn' },
      { label: 'Grow from Small', value: 'zoomIn' },
      { label: 'Grow from Left', value: 'zoomInLeft' },
      { label: 'Grow from Right', value: 'zoomInRight' },
      { label: 'Grow from Top', value: 'zoomInUp' },
      { label: 'Grow from Bottom', value: 'zoomInDown' },
      { label: 'Slide Right and Expand', value: 'slideInLeft' },
      { label: 'Slide Left and Expand', value: 'slideInRight' },
      { label: 'Slide Up and Expand', value: 'slideInUp' },
      { label: 'Slide Down and Expand', value: 'slideInDown' },
    ],
  },
  {
    label: 'Emphasis',
    children: [
      { label: 'Bounce', value: 'bounce' },
      { label: 'Flash', value: 'flash' },
      { label: 'Grow and Shrink', value: 'pulse' },
      { label: 'Grow and Shrink (Spring)', value: 'rubberBand' },
      { label: 'Shake Left and Right', value: 'headShake' },
      { label: 'Fan-shaped Swing Left and Right', value: 'swing' },
      { label: 'Grow, Shake, Shrink', value: 'tada' },
      { label: 'Fan-shaped Swing', value: 'wobble' },
      { label: 'Shake Left, Right, Up, Down', value: 'jello' },
      { label: 'Y-axis Rotation', value: 'flip' },
    ],
  },
  {
    label: 'Exit',
    children: [
      { label: 'Fade Out', value: 'fadeOut' },
      { label: 'Exit to Left', value: 'fadeOutLeft' },
      { label: 'Exit to Right', value: 'fadeOutRight' },
      { label: 'Exit Upward', value: 'fadeOutUp' },
      { label: 'Exit Downward', value: 'fadeOutDown' },
      { label: 'Exit to Left Long Distance', value: 'fadeOutLeftBig' },
      { label: 'Exit to Right Long Distance', value: 'fadeOutRightBig' },
      { label: 'Exit Upward Long Distance', value: 'fadeOutUpBig' },
      { label: 'Exit Downward Long Distance', value: 'fadeOutDownBig' },
      { label: 'Rotate Out', value: 'rotateOut' },
      { label: 'Rotate Clockwise from Left', value: 'rotateOutDownLeft' },
      { label: 'Rotate Counter-clockwise from Right', value: 'rotateOutDownRight' },
      { label: 'Rotate Counter-clockwise from Left', value: 'rotateOutUpLeft' },
      { label: 'Rotate Counter-clockwise from Right', value: 'rotateOutUpRight' },
      { label: 'Bounce Out', value: 'bounceOut' },
      { label: 'Bounce Out to Left', value: 'bounceOutLeft' },
      { label: 'Bounce Out to Right', value: 'bounceOutRight' },
      { label: 'Bounce Out Upward', value: 'bounceOutUp' },
      { label: 'Bounce Out Downward', value: 'bounceOutDown' },
      { label: 'Center X-axis Rotation', value: 'flipOutX' },
      { label: 'Center Y-axis Rotation', value: 'flipOutY' },
      { label: 'Long Left Radius Rotation', value: 'rollOut' },
      { label: 'Shrink from Large', value: 'zoomOut' },
      { label: 'Shrink to Left', value: 'zoomOutLeft' },
      { label: 'Shrink to Right', value: 'zoomOutRight' },
      { label: 'Shrink Upward', value: 'zoomOutUp' },
      { label: 'Shrink Downward', value: 'zoomOutDown' },
      { label: 'Slide Left and Collapse', value: 'slideOutLeft' },
      { label: 'Slide Right and Collapse', value: 'slideOutRight' },
      { label: 'Slide Up and Collapse', value: 'slideOutUp' },
      { label: 'Slide Down and Collapse', value: 'slideOutDown' },
    ],
  },
]

Then use the v-for directive to render out the animation list.

Adding Animations

<el-tabs v-model="animationActiveName">
  <el-tab-pane v-for="item in animationClassData" :key="item.label" :label="item.label" :name="item.label">
    <el-scrollbar class="animate-container">
      <div
        class="animate"
        v-for="(animate, index) in item.children"
        :key="index"
        @mouseover="hoverPreviewAnimate = animate.value"
        @click="addAnimation(animate)"
      >
        <div :class="[hoverPreviewAnimate === animate.value && animate.value + ' animated']">{{ animate.label }}</div>
      </div>
    </el-scrollbar>
  </el-tab-pane>
</el-tabs>

Clicking on an animation will call addAnimation(animate) to add the animation to the component's animations array.

Triggering Animations

Code for running animations:

export default async function runAnimation($el, animations = []) {
  const play = (animation) =>
    new Promise((resolve) => {
      $el.classList.add(animation.value, 'animated')
      const removeAnimation = () => {
        $el.removeEventListener('animationend', removeAnimation)
        $el.removeEventListener('animationcancel', removeAnimation)
        $el.classList.remove(animation.value, 'animated')
        resolve()
      }

      $el.addEventListener('animationend', removeAnimation)
      $el.addEventListener('animationcancel', removeAnimation)
    })

  for (let i = 0, len = animations.length; i < len; i++) {
    await play(animations[i])
  }
}

Running animations requires two parameters: the DOM element corresponding to the component (obtained with this.$el in the component) and its animation data animations. It also needs to listen for the animationend event and the animationcancel event: one is triggered when the animation ends, the other when the animation is unexpectedly terminated.

Using this in combination with Promise, you can run each of the component's animations one by one.

12. Importing PSD

Due to time constraints, I haven't implemented this feature yet. Here's a brief description of how to implement it. Use the psd.js library, which can parse PSD files.

The data obtained by parsing PSD files using the psd library looks like this:

{ children:
   [ { type: 'group',
       visible: false,
       opacity: 1,
       blendingMode: 'normal',
       name: 'Version D',
       left: 0,
       right: 900,
       top: 0,
       bottom: 600,
       height: 600,
       width: 900,
       children:
        [ { type: 'layer',
            visible: true,
            opacity: 1,
            blendingMode: 'normal',
            name: 'Make a change and save.',
            left: 275,
            right: 636,
            top: 435,
            bottom: 466,
            height: 31,
            width: 361,
            mask: {},
            text:
             { value: 'Make a change and save.',
               font:
                { name: 'HelveticaNeue-Light',
                  sizes: [ 33 ],
                  colors: [ [ 85, 96, 110, 255 ] ],
                  alignment: [ 'center' ] },
               left: 0,
               top: 0,
               right: 0,
               bottom: 0,
               transform: { xx: 1, xy: 0, yx: 0, yy: 1, tx: 456, ty: 459 } },
            image: {} } ] } ],
    document:
       { width: 900,
         height: 600,
         resources:
          { layerComps:
             [ { id: 692243163, name: 'Version A', capturedInfo: 1 },
               { id: 725235304, name: 'Version B', capturedInfo: 1 },
               { id: 730932877, name: 'Version C', capturedInfo: 1 } ],
            guides: [],
            slices: [] } } }

From the code above, we can see that this data is very similar to CSS. Based on this observation, we only need to write a conversion function to convert this data into the data required by our components, thus implementing the functionality of converting PSD files into rendered components. Currently, quark-h5 and luban-h5 both implement PSD conversion functionality in this way.

13. Mobile Mode

Since the canvas size can be adjusted, we can use the iPhone 6 resolution to develop mobile pages.

Pages developed this way can also be viewed normally on mobile devices, but there may be style discrepancies. This is because my three custom components are not made responsive. If you need to develop mobile pages, you must use a mobile UI component library for your custom components, or develop custom components specifically for mobile use.

Conclusion

Since the DEMO code is quite extensive, when explaining each feature point, I only included the key code. So you'll find that the source code of the DEMO differs somewhat from the code I've presented here, but please don't be concerned about this.

Additionally, the styling of the DEMO is rather rudimentary, mainly because I've been quite busy recently and haven't had much time to make it more visually appealing, so please bear with me.

References

Step-by-Step Guide to Front-end Engineering — A Comprehensive Tutorial

woai3c — Thu, 03 Apr 2025 04:11:38 +0000

This article will be divided into the following 7 sections:

Technology Selection
Unified Standards
Testing
Deployment
Monitoring
Performance Optimization
Refactoring

Some sections provide very detailed practical tutorials for hands-on practice.

Additionally, I've created a frontend engineering demo on GitHub. This demo includes JavaScript, CSS, and Git validation. The JavaScript and CSS validation require VSCode installation, and specific tutorials will be mentioned later in this article.

Technology Selection

For frontend development, technology selection is quite simple. It's like a multiple-choice question - choose one of the three major frameworks. In my opinion, you can select based on the following two characteristics:

Choose what you or your team is most familiar with, ensuring that someone can fix issues when facing tricky problems.
Choose frameworks with high market share. In other words, choose what makes recruitment easier.

The second point is especially important for small companies. Small companies already have difficulty recruiting, and if you choose a framework with low market share (such as Angular), you'll barely see any resumes...

UI component libraries are even simpler - use the one with the most stars on GitHub. More stars means more users, and many issues have already been encountered and resolved by others, saving you trouble.

Unified Standards

Code Standards

Let's first look at the benefits of unified code standards:

Standardized code promotes team collaboration
Standardized code reduces maintenance costs
Standardized code helps with code review
Developing standardized code habits contributes to a programmer's growth

When team members strictly follow code standards, it ensures that everyone's code looks like it was written by the same person. Reading someone else's code becomes like reading your own. More importantly, we recognize the importance of standards and maintain standardized development habits.

How to Establish Code Standards

It's recommended to find a good code standard and customize it based on your team's needs.

Here are some JavaScript code standards with many stars:

There are also many CSS code standards, such as:

How to Check Code Standards

You can use ESLint to check if your code complies with your team's standards. Let's see how to configure ESLint for code checking.

Download dependencies

// eslint-config-airbnb-base uses airbnb code standards
npm i -D babel-eslint eslint eslint-config-airbnb-base eslint-plugin-import

Configure the .eslintrc file

{
    "parserOptions": {
        "ecmaVersion": 2019
    },
    "env": {
        "es6": true,
    },
    "parser": "babel-eslint",
    "extends": "airbnb-base",
}

Add this line to the scripts in package.json: "lint": "eslint --ext .js test/ src/". Then run npm run lint to start validating code. The test/ src/ in the code specifies which code directories to check, indicating that you want to check code in the test and src directories.

However, checking code this way is too inefficient as you have to manually check each time. Plus, when errors are reported, you still need to manually modify the code.

To improve these drawbacks, we can use VSCode. With VSCode and appropriate configurations, you can automatically validate and format code every time you save, eliminating the need for manual work.

For CSS code standard checking, use the stylelint plugin.

Due to space limitations, for specific configuration instructions, please refer to my other article ESlint + stylelint + VSCode automated code formatting (2020).

Git Standards

Git standards include two aspects: branch management standards and git commit standards.

Branch Management Standards

Projects generally have a main branch (master) and other branches.

When a team member needs to develop a new feature or fix a bug, they create a new branch from the master branch. For example, if a project needs to change from client-side rendering to server-side rendering, create a new branch called ssr, and merge it back to the master branch after development.

For bug fixes, you can also create a new branch from the master branch, naming it after the bug number (though our small team finds this troublesome and doesn't do this unless there's a particularly major bug).

Git Commit Standards

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

This is roughly divided into three parts (separated by blank lines):

Title line: Required, describes the main type and content of modification
Main content: Describes why the modification was made, what kind of modification was made, and the development thought process
Footer notes: Can include comments, bug number links

type: commit type

feat: New feature
fix: Bug fix
perf: Code changes to improve performance
refactor: Code refactoring (modifying code without affecting internal behavior or functionality)
docs: Documentation changes
style: Code format changes, not CSS changes (e.g., semicolon modifications)
test: Adding or modifying test cases
build: Changes affecting project builds or dependencies
revert: Reverting previous commits
ci: Changes to continuous integration related files
chore: Other changes (not in above types)
release: Release new version
workflow: Changes to workflow related files

scope: The scope affected by the commit, such as: route, component, utils, build...
subject: The summary of the commit
body: Specific content of the commit, can be multi-line.
footer: Some notes, usually BREAKING CHANGE or links to fixed bugs.

Examples

fix (Bug Fix)

If the bug fix only affects the current file, you can omit the scope. If the impact is more extensive, add a scope description.

For example, if this bug fix affects globally, you can add "global". If it affects a specific directory or functionality, you can add the path of that directory or the corresponding feature name.

// Example 1
fix(global): Fix checkbox unable to be checked
// Example 2 - the "common" in parentheses below is the name of common management
fix(common): Fix font size too small, change default font size to 14px for all pages under common management
// Example 3
fix: value.length -> values.length

feat (Adding New Features or Pages)

feat: Add website homepage static page

This is an example assuming some description of a static page for inspection tasks.

Here are notes, which can include bug links or important information.

chore (Other Changes)

Chore literally translates to daily matters or routine work, meaning modifications not in other commit types.

chore: Change "View Details" to "Details" in the table

Other types of commits are similar to the three examples above, so they won't be elaborated.

Validating Git Commit Standards

To validate git commit standards, primarily use git's pre-commit hook function. Of course, you'll also need a helper tool to assist with validation.

Download the helper tool

npm i -D husky

Add the following code to package.json

"husky": {
  "hooks": {
    "pre-commit": "npm run lint",
    "commit-msg": "node script/verify-commit.js",
    "pre-push": "npm test"
  }
}

Then create a folder named script in your project root directory, and create a file called verify-commit.js with the following code:

const msgPath = process.env.HUSKY_GIT_PARAMS
const msg = require('fs')
.readFileSync(msgPath, 'utf-8')
.trim()

const commitRE = /^(feat|fix|docs|style|refactor|perf|test|workflow|build|ci|chore|release|workflow)(\(.+\))?: .{1,50}/

if (!commitRE.test(msg)) {
    console.log()
    console.error(`
        Invalid commit message format.
        Please check the git commit submission specification: https://github.com/woai3c/Front-end-articles/blob/master/git%20commit%20style.md
    `)

    process.exit(1)
}

Now let's explain the meaning of each hook:

"pre-commit": "npm run lint" executes npm run lint before git commit to check code format.
"commit-msg": "node script/verify-commit.js" executes the verify-commit.js script during git commit to validate the commit message. It will report an error if it doesn't meet the format defined in the script.
"pre-push": "npm test" executes npm test before you run git push to push code to the remote repository. If the test fails, the push won't proceed.

Project Standards

This mainly refers to how project files are organized and named.

Let's use our Vue project as an example.

├─public
├─src
├─test

A project typically contains public (public resources not processed by webpack), src (source code), and test (test code) directories. The src directory can be further subdivided:

├─api (interfaces)
├─assets (static resources)
├─components (common components)
├─styles (common styles)
├─router (router)
├─store (vuex global data)
├─utils (utility functions)
└─views (pages)

If filenames are too long, use hyphens as separators.

UI Standards

UI standards need to be communicated and agreed upon by frontend developers, UI designers, and product managers. Using a unified UI component library is recommended.

Benefits of establishing UI standards:

Unify page UI standards, saving UI design time
Improve frontend development efficiency

Testing

Testing is an essential part of frontend engineering. Its purpose is to find bugs, and the earlier bugs are found, the lower the cost required to fix them. More importantly, its role is more significant in the future rather than the present.

Imagine that six months later, you need to add a new feature to your project. After adding it, you're not sure if it affects existing functionality and need to test. Since too much time has passed, you're no longer familiar with the project code. In this situation, if you haven't written tests, you'd have to manually test everything repeatedly. But if you've written tests, you just need to run the test code once, saving time and effort.

Writing tests also allows you to modify code without psychological burden, without constantly worrying about whether changes will cause issues or bugs. With tests, these concerns are eliminated.

The most commonly used testing in frontend is unit testing (I rarely use end-to-end testing and am not familiar with it), which I'll focus on explaining.

Unit Testing

Unit testing involves testing a function, component, or class, targeting a relatively small granularity.

How should it be written?

Write tests based on correctness, meaning correct inputs should yield normal results.
Write tests based on exceptions, meaning incorrect inputs should yield error results.

Testing a Function

For example, an absolute value function abs(), inputs 1,2 should yield the same output as the input; inputs -1,-2 should yield results opposite to the input. If a non-numeric input like "abc" is provided, a type error should be thrown.

Testing a Class

Assume there's a class like this:

class Math {
    abs() {

    }

    sqrt() {

    }

    pow() {

    }
    ...
}

Unit testing requires testing all methods of this class.

Testing a Component

Component testing is more difficult because many components involve DOM operations.

For example, an image upload component has a method to convert images to base64 code. How do you test this? Tests usually run in a Node environment, which doesn't have DOM objects.

Let's first review the image upload process:

Click <input type="file" /> to select and upload an image.
Trigger the change event of the input to get the file object.
Use FileReader to convert the image to base64 code.

This process is the same as the following code:

document.querySelector('input').onchange = function fileChangeHandler(e) {
    const file = e.target.files[0]
    const reader = new FileReader()
    reader.onload = (res) => {
        const fileResult = res.target.result
        console.log(fileResult) // Output base64 code
    }

    reader.readAsDataURL(file)
}

The code above is just a simulation. In real situations, it should be used like this:

document.querySelector('input').onchange = function fileChangeHandler(e) {
    const file = e.target.files[0]
    tobase64(file)
}

function tobase64(file) {
    return new Promise((resolve, reject) => {
        const reader = new FileReader()
        reader.onload = (res) => {
            const fileResult = res.target.result
            resolve(fileResult) // Output base64 code
        }

        reader.readAsDataURL(file)
    })
}

As you can see, the code above uses the window's event object event and FileReader. This means that as long as we can provide these two objects, we can run it in any environment. So we can add these two objects in the test environment:

// Rewrite File
window.File = function () {}

// Rewrite FileReader
window.FileReader = function () {
    this.readAsDataURL = function () {
        this.onload
            && this.onload({
                target: {
                    result: fileData,
                },
            })
    }
}

Then the test can be written like this:

// Prepare file content beforehand
const fileData = 'data:image/test'

// Provide a fake file object to the tobase64() function
function test() {
    const file = new File()
    const event = { target: { files: [file] } }
    file.type = 'image/png'
    file.name = 'test.png'
    file.size = 1024

    it('file content', (done) => {
        tobase64(file).then(base64 => {
            expect(base64).toEqual(fileData) // 'data:image/test'
            done()
        })
    })
}

// Execute the test
test()

With this hack, we've achieved testing for components involving DOM operations. My vue-upload-imgs library uses this approach for unit testing, feel free to check it out.

TDD (Test-Driven Development)

TDD means writing test code in advance based on requirements, then implementing functionality according to the test code.

The intention behind TDD is good, but if your requirements change frequently (you know what I mean), it's not a good idea. You might end up modifying test code every day while barely touching business code.
So until now, in over three years of my programming career, I haven't tried TDD development.

Despite the challenging environment, TDD should be attempted when conditions allow. For example, when you're responsible for a project and not too busy, you can use this method to write test cases.

Recommended Testing Framework

My commonly used testing framework is jest. Its advantage is that it has Chinese documentation, and the API is clear and easy to understand at a glance.

Deployment

Before learning automated deployment, this is how I deployed projects:

Run tests with npm run test.
Build the project with npm run build.
Place the packaged files on a static server.

Doing this once or twice is fine, but if you do it every day, a lot of time is wasted on repetitive operations. So we need to learn automated deployment to completely free our hands.

Automated deployment (also called Continuous Deployment, abbreviated as CD) generally has two trigger methods:

Polling.
Listening for webhook events.

Polling

Polling means the build software automatically executes packaging and deployment operations at regular intervals.

This approach isn't ideal, as it's very possible that I might change code right after the software finishes deploying. To see the effect of the new page, I'd have to wait until the next build starts.

Another side effect is that if I don't change any code all day, the build software will still continuously execute packaging and deployment operations, wasting resources.

Therefore, most build software now uses the approach of listening for webhook events for deployment.

Listening for `webhook` Events

A webhook function is set up on your build software to monitor a certain event (usually monitoring the push event). When the event is triggered, it automatically executes predefined scripts.

For example, Github Actions has this feature.

For newcomers, it's impossible to learn automated deployment just from this section. Therefore, I've specially written an automated deployment tutorial that doesn't require you to learn automated deployment knowledge in advance. Just follow the guide to achieve frontend project automated deployment.

Frontend Project Automated Deployment—Super Detailed Tutorial (Jenkins, Github Actions). The tutorial is provided, and if you find it useful after reading, don't forget to give it a like. Much appreciated.

Monitoring

Monitoring includes performance monitoring and error monitoring. Its purpose is to provide early warnings and track and locate issues.

Performance Monitoring

Performance monitoring generally uses window.performance for data collection.

The Performance interface can obtain performance-related information from the current page. It's part of the High Resolution Time API and also integrates the Performance Timeline API, Navigation Timing API, User Timing API, and Resource Timing API.

The timing property of this API includes the start and end times of each stage of page loading.

To help everyone understand the meaning of each timing property, I found an introduction about timing written by a fellow netizen on Zhihu (whose name I've forgotten and couldn't find later, my apologies), which I'm reposting here.

timing: {
        // Timestamp when the previous page unload event ended in the same browser. If there's no previous page, this value will be the same as fetchStart.
    navigationStart: 1543806782096,

    // Timestamp when the unload event from the previous page was fired. If there's no previous page, this value will return 0.
    unloadEventStart: 1543806782523,

    // Corresponding to unloadEventStart, the timestamp when the unload event handling was completed. If there's no previous page, this value will return 0.
    unloadEventEnd: 1543806782523,

    // Timestamp when the first HTTP redirect began. If there are no redirects, or if one of the redirects is from a different origin, this value will return 0.
    redirectStart: 0,

    // Timestamp when the last HTTP redirect was completed (that is, when the last bit of the HTTP response was received). If there are no redirects, or if one of the redirects is from a different origin, this value will return 0.
    redirectEnd: 0,

    // Timestamp when the browser is ready to fetch the document using an HTTP request. This timestamp will be before checking any application caches.
    fetchStart: 1543806782096,

    // Timestamp when the DNS domain lookup started.
        // If a persistent connection is used, or this information is stored in cache or local resources, this value will be the same as fetchStart.
    domainLookupStart: 1543806782096,

    // Timestamp when the DNS domain lookup was completed.
    // If local cache is used (meaning no DNS lookup) or a persistent connection, it will be equal to the fetchStart value.
    domainLookupEnd: 1543806782096,

    // Timestamp when the HTTP (TCP) domain lookup ended.
        // If a persistent connection is used, or this information is stored in cache or local resources, this value will be the same as fetchStart.
    connectStart: 1543806782099,

    // HTTP (TCP) returns the timestamp when the connection between the browser and server was established.
        // If it's a persistent connection, the return value is the same as the fetchStart property. Connection establishment refers to the completion of all handshakes and authentication processes.
    connectEnd: 1543806782227,

    // HTTPS returns the timestamp when the browser started the handshake process for a secure connection with the server. If the current page doesn't require a secure connection, it returns 0.
    secureConnectionStart: 1543806782162,

    // Returns the timestamp when the browser sent the HTTP request to the server (or started reading from local cache).
    requestStart: 1543806782241,

    // Returns the timestamp when the browser received (or read from local cache) the first byte.
        // If the transport layer fails after starting the request and the connection is reopened, this property will be set to the time corresponding to the new request.
    responseStart: 1543806782516,

    // Returns the timestamp when the browser received (or read from local cache or local resources) the last byte
        // (or if the HTTP connection has already closed, returns the closing time).
    responseEnd: 1543806782537,

    // Timestamp when the current webpage DOM structure started parsing (i.e., when Document.readyState property changed to "loading" and the corresponding readystatechange event was triggered).
    domLoading: 1543806782573,

    // Timestamp when the current webpage DOM structure finished parsing and started loading embedded resources (i.e., when Document.readyState property changed to "interactive" and the corresponding readystatechange event was triggered).
    domInteractive: 1543806783203,

    // Timestamp when the parser sent the DOMContentLoaded event, meaning all scripts that need to be executed have been parsed.
    domContentLoadedEventStart: 1543806783203,

    // Timestamp when all scripts that need immediate execution have been executed (regardless of execution order).
    domContentLoadedEventEnd: 1543806783216,

    // Timestamp when the current document parsing is complete, i.e., when Document.readyState changes to 'complete' and the corresponding readystatechange is triggered.
    domComplete: 1543806783796,

    // Timestamp when the load event was sent. If this event hasn't been sent yet, its value will be 0.
    loadEventStart: 1543806783796,

    // Timestamp when the load event ended, i.e., when the loading event was completed. If this event hasn't been sent yet or hasn't been completed, its value will be 0.
    loadEventEnd: 1543806783802
}

From this data, we can derive several useful times:

// Redirect time
redirect: timing.redirectEnd - timing.redirectStart,
// DOM rendering time
dom: timing.domComplete - timing.domLoading,
// Page loading time
load: timing.loadEventEnd - timing.navigationStart,
// Page unload time
unload: timing.unloadEventEnd - timing.unloadEventStart,
// Request time
request: timing.responseEnd - timing.requestStart,
// Current time when getting performance information
time: new Date().getTime(),

Another important time is white screen time, which refers to the time from entering the URL to when the page begins to display content.

Placing the following script before </head> allows you to get the white screen time.

<script>
    whiteScreen = new Date() - performance.timing.navigationStart
</script>

With these times, you can determine how well the page's first screen loads.

Additionally, through the window.performance.getEntriesByType('resource') method, we can obtain the loading time of related resources (js, css, img...). It returns all resources currently loaded on the page.

It generally includes the following types:

script
link
img
css
fetch
other
xmlhttprequest

We only need the following information:

// Resource name
name: item.name,
// Resource loading time
duration: item.duration.toFixed(2),
// Resource size
size: item.transferSize,
// Protocol used by the resource
protocol: item.nextHopProtocol,

Now, let's write a few lines of code to collect this data.

// Collect performance information
const getPerformance = () => {
    if (!window.performance) return
    const timing = window.performance.timing
    const performance = {
        // Redirect time
        redirect: timing.redirectEnd - timing.redirectStart,
        // White screen time
        whiteScreen: whiteScreen,
        // DOM rendering time
        dom: timing.domComplete - timing.domLoading,
        // Page loading time
        load: timing.loadEventEnd - timing.navigationStart,
        // Page unload time
        unload: timing.unloadEventEnd - timing.unloadEventStart,
        // Request time
        request: timing.responseEnd - timing.requestStart,
        // Current time when getting performance information
        time: new Date().getTime(),
    }

    return performance
}

// Get resource information
const getResources = () => {
    if (!window.performance) return
    const data = window.performance.getEntriesByType('resource')
    const resource = {
        xmlhttprequest: [],
        css: [],
        other: [],
        script: [],
        img: [],
        link: [],
        fetch: [],
        // Current time when getting resource information
        time: new Date().getTime(),
    }

    data.forEach(item => {
        const arry = resource[item.initiatorType]
        arry && arry.push({
            // Resource name
            name: item.name,
            // Resource loading time
            duration: item.duration.toFixed(2),
            // Resource size
            size: item.transferSize,
            // Protocol used by the resource
            protocol: item.nextHopProtocol,
        })
    })

    return resource
}

Summary

By interpreting performance and resource information, we can determine that slow page loading has several reasons:

Too many resources
Slow network speed
Too many DOM elements

Apart from the user's slow network speed, which we can't control, the other two reasons can be resolved. Performance optimization will be discussed in the next section, "Performance Optimization."

Error Monitoring

Currently, three types of errors can be captured:

Resource loading errors, captured through addEventListener('error', callback, true) during the capture phase.
JavaScript execution errors, captured through window.onerror.
Promise errors, captured through addEventListener('unhandledrejection', callback), though without line and column information, only manually thrown error information.

We can create an error array variable errors to add relevant error information when errors occur, and then report them collectively at a certain stage. Here's how to do it:

// Capture resource loading failure errors for js, css, img...
addEventListener('error', e => {
    const target = e.target
    if (target != window) {
        monitor.errors.push({
            type: target.localName,
            url: target.src || target.href,
            msg: (target.src || target.href) + ' is load error',
            // Time when the error occurred
            time: new Date().getTime(),
        })
    }
}, true)

// Monitor JavaScript errors
window.onerror = function(msg, url, row, col, error) {
    monitor.errors.push({
        type: 'javascript',
        row: row,
        col: col,
        msg: error && error.stack? error.stack : msg,
        url: url,
        // Time when the error occurred
        time: new Date().getTime(),
    })
}

// Monitor Promise errors - drawback is that line number data can't be obtained
addEventListener('unhandledrejection', e => {
    monitor.errors.push({
        type: 'promise',
        msg: (e.reason && e.reason.msg) || e.reason || '',
        // Time when the error occurred
        time: new Date().getTime(),
    })
})

Summary

Through error collection, we can understand the types and quantities of errors occurring on the website, allowing for adjustments to reduce errors.
For complete code and a DEMO, please refer to the end of my other article Frontend Performance and Error Monitoring. You can copy the code (HTML file) and test it locally.

Data Reporting

Performance Data Reporting

Performance data can be reported after the page has loaded, to avoid impacting page performance.

window.onload = () => {
    // Get performance and resource information during browser idle time
    // https://developer.mozilla.org/zh-CN/docs/Web/API/Window/requestIdleCallback
    if (window.requestIdleCallback) {
        window.requestIdleCallback(() => {
            monitor.performance = getPerformance()
            monitor.resources = getResources()
        })
    } else {
        setTimeout(() => {
            monitor.performance = getPerformance()
            monitor.resources = getResources()
        }, 0)
    }
}

Of course, you can also set up a timer for cyclic reporting. However, it's best to compare and deduplicate data before each report to avoid repeatedly reporting the same data.

Error Data Reporting

The code I provided in the DEMO collects all errors in an errors array and reports them collectively at a certain stage (delayed reporting).
Actually, you can also change it to report when an error occurs (immediate reporting). This avoids the problem of error data being lost if the user closes the webpage before the delayed reporting triggers after error collection.

// Monitor JavaScript errors
window.onerror = function(msg, url, row, col, error) {
    const data = {
        type: 'javascript',
        row: row,
        col: col,
        msg: error && error.stack? error.stack : msg,
        url: url,
        // Time when the error occurred
        time: new Date().getTime(),
    }

    // Immediate reporting
    axios.post({ url: 'xxx', data, })
}

SPA

The window.performance API has a drawback - when switching routes in an SPA, the data in window.performance.timing doesn't update.
So we need to find another way to record the time from route switching to loading completion.
Taking Vue as an example, a feasible approach is to get the start time in the router's global guard beforeEach when switching routes, and get the component's rendering completion time in the component's mounted hook by executing the vm.$nextTick function.

router.beforeEach((to, from, next) => {
    store.commit('setPageLoadedStartTime', new Date())
})

mounted() {
    this.$nextTick(() => {
        this.$store.commit('setPageLoadedTime', new Date() - this.$store.state.pageLoadedStartTime)
    })
}

Besides performance and error monitoring, we can do even more.

User Information Collection

navigator

Using window.navigator, we can collect user device information, operating system, browser information, etc.

UV (Unique Visitor)

This refers to natural persons who access and browse the webpage through the internet. A client computer accessing your website is considered one visitor. The same client is only counted once within 00:00-24:00. Multiple visits from the same visitor in one day only count as one UV.
When users visit the website, a random string + date can be generated and saved locally. When the webpage makes a request (if it exceeds 24 hours that day, it's regenerated), these parameters are passed to the backend, and the backend uses this information to generate UV statistical reports.

PV (Page View)

This refers to page views or clicks. Each time a user visits each page on the website, 1 PV is recorded. Multiple visits to the same page by a user accumulate PV count, used to measure the number of pages visited by website users.

Page Stay Time

Traditional Websites
When a user enters page A, the time they enter is sent along with the backend request. After 10 minutes, when the user enters page B, the backend can determine through the parameters that the user stayed on page A for 10 minutes.
SPA
We can use routers to get the user's stay time. Taking Vue as an example, we can get the time a user stays on a route component using the router.beforeEach and destroyed hook functions.

Browsing Depth

By using the document.documentElement.scrollTop property along with screen height, we can determine whether a user has browsed through the website content completely.

Page Referral Source

Through the document.referrer property, we can know which website the user came from.

Summary

By analyzing user data, we can understand users' browsing habits, preferences, and more. It's quite scary to think about how little privacy remains.

Frontend Monitoring Deployment Tutorial

All the above discusses monitoring principles, but implementation requires coding. To avoid trouble, we can use existing tools like Sentry for this task.

Sentry is a performance and error monitoring tool written in Python. You can use Sentry's services (with limited free features) or deploy your own service. Let's see how to use Sentry's services for monitoring.

Register an Account

Open https://sentry.io/signup/ to register.

Select a project, I chose Vue.

Install Sentry Dependencies

After selecting a project, specific Sentry installation instructions will be shown below.

Following the prompts, execute this code in your Vue project npm install --save @sentry/browser @sentry/integrations @sentry/tracing to install Sentry's required dependencies.

Then copy the code below to your main.js, placing it before new Vue().

import * as Sentry from "@sentry/browser";
import { Vue as VueIntegration } from "@sentry/integrations";
import { Integrations } from "@sentry/tracing";

Sentry.init({
  dsn: "xxxxx", // This is your dsn address, available after registration
  integrations: [
    new VueIntegration({
      Vue,
      tracing: true,
    }),
    new Integrations.BrowserTracing(),
  ],

  // We recommend adjusting this value in production, or using tracesSampler
  // for finer control
  tracesSampleRate: 1.0,
});

Then click skip this onboarding from the first step to enter the control panel.

If you've forgotten your DSN, click on the left menu bar and select Settings -> Projects -> click on your project -> Client Keys(DSN).

Create Your First Error

Execute a print statement in your Vue project: console.log(b).

Now, if you open the Issues section on the Sentry homepage, you'll find an error message b is not defined:

This error message includes detailed information about the error, as well as your IP, browser information, etc.

Oddly, our browser console doesn't show any error output.

This is because it's been blocked by Sentry, so we need to add an option logErrors: true.

Then, viewing the page again, you'll find the console also has an error message:

Upload Sourcemap

Generally, code after packaging is compressed. Without sourcemap, even with error messages, it's difficult to locate the corresponding source code.

Let's see how to upload sourcemap.

First, create an auth token.

This generated token will be used later.

Install sentry-cli and @sentry/webpack-plugin:

npm install sentry-cli-binary -g
npm install --save-dev @sentry/webpack-plugin

After installing these two plugins, create a .sentryclirc file in the project root directory (don't forget to add this file to .gitignore to avoid exposing the token), with the following content:

[auth]
token=xxx

[defaults]
url=https://sentry.io/
org=woai3c
project=woai3c

Replace xxx with the token you just generated.

org is your organization name.

project is your project name, which can be found following the instructions below.

Create a vue.config.js file in your project and fill it with the following content:

const SentryWebpackPlugin = require('@sentry/webpack-plugin')

const config = {
    configureWebpack: {
        plugins: [
            new SentryWebpackPlugin({
                include: './dist', // Directory after packaging
                ignore: ['node_modules', 'vue.config.js', 'babel.config.js'],
            }),
        ],
    },
}

// Only upload sourcemap in production environment
module.exports = process.env.NODE_ENV == 'production'? config : {}

After filling this out, execute npm run build to see the upload results of the sourcemap.

Let's compare the error messages before and after uploading sourcemap.

Before uploading sourcemap

After uploading sourcemap

As you can see, the error messages after uploading sourcemap are more accurate.

Switch to Chinese Environment and Time Zone

Refresh after selection.

Performance Monitoring

Open the performance option to see how each project runs. For detailed parameter explanations, please refer to the documentation Performance Monitoring.

Performance Optimization

Performance optimization is mainly divided into two categories:

Load-time optimization
Runtime optimization

For example, compressing files and using CDN belong to load-time optimization; reducing DOM operations and using event delegation belong to runtime optimization.

Before solving a problem, you must first identify it, or you won't know where to start. So before performing performance optimization, it's best to investigate your website's loading and runtime performance.

Manual Checking

Check Loading Performance

A website's loading performance mainly depends on white screen time and first screen time.

White screen time: The time from entering the URL to when the page begins to display content.
First screen time: The time from entering the URL to when the page is completely rendered.

Placing the following script before </head> allows you to get the white screen time.

<script>
    new Date() - performance.timing.navigationStart
</script>

In the window.onload event, executing new Date() - performance.timing.navigationStart will give you the first screen time.

Check Runtime Performance

With Chrome's developer tools, we can check the website's runtime performance.

Open the website, press F12 to select performance, click the gray dot in the upper left corner, and it turns red to indicate recording has started. At this point, you can simulate users using the website, and when you're done, click stop. Then you'll see the website's performance report during runtime. If there are red blocks, it means frames are being dropped; if it's green, it means the FPS is good.

Additionally, under the performance tab, pressing ESC will pop up a small box. Click the three dots on the left side of the small box and check rendering.

Of these two options, the first highlights repaint areas, and the other displays frame rendering information. Check these two options, and then browse the webpage to see your webpage rendering changes in real-time.

Using Tools for Checking

Monitoring Tools

You can deploy a frontend monitoring system to monitor website performance. Sentry, mentioned in the previous section, belongs to this category.

Chrome Tool Lighthouse

If you have installed Chrome 52+ version, press F12 to open the developer tools.

It not only scores your website's performance but also scores SEO.

Use Lighthouse to Audit Web Applications

How to Perform Performance Optimization

There are countless articles and books about performance optimization online, but many optimization rules are outdated. So I wrote a performance optimization article 24 Frontend Performance Optimization Tips (2020), analyzing and summarizing 24 performance optimization suggestions. Highly recommended.

Refactoring

In the book Refactoring (2nd Edition), refactoring is defined as:

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its essence is improving the design of code after it has been written.

Refactoring and performance optimization have similarities and differences.

The similarity is that they both modify code without changing program functionality; the difference is that refactoring aims to make code more readable and understandable, while performance optimization aims to make programs run faster.

Refactoring can be done while writing code or after the program is complete, setting aside time specifically for refactoring. Neither approach is necessarily better; it depends on individual circumstances.

If you specifically allocate time for refactoring, it's recommended to test immediately after refactoring a piece of code. This helps avoid modifying too much code and not being able to locate errors when they occur.

Principles of Refactoring

Don't repeat yourself (DRY). Don't write the same code more than twice; refactor in such situations.
If a piece of code is difficult to understand, consider refactoring.
If you understand the code but it's too cumbersome or not good enough, you can refactor it.
Functions that are too long need refactoring.
A function should correspond to one functionality. If a function has multiple functionalities, it should be refactored.

Refactoring Techniques

In Refactoring (2nd Edition), more than a hundred refactoring techniques are introduced. But I think two are particularly common:

Extract repetitive code, encapsulate into functions
Split functions that are too long or have too many functionalities

Extract Repetitive Code, Encapsulate into Functions

Suppose there's a data query interface /getUserData?age=17&city=beijing. Now you need to convert user data: { age: 17, city: 'beijing' } into URL parameter form:

let result = ''
const keys = Object.keys(data)  // { age: 17, city: 'beijing' }
keys.forEach(key => {
    result += '&' + key + '=' + data[key]
})

result.substr(1) // age=17&city=beijing

If only one interface needs conversion, not encapsulating it into a function is fine. But if multiple interfaces have this requirement, then you should encapsulate it into a function:

function JSON2Params(data) {
    let result = ''
    const keys = Object.keys(data)
    keys.forEach(key => {
        result += '&' + key + '=' + data[key]
    })

    return result.substr(1)
}

Split Functions That Are Too Long or Have Too Many Functionalities

Suppose there's a registration function, represented in pseudocode:

function register(data) {
    // 1. Validate user data
    /**
     * Validate account
     * Validate password
     * Validate SMS verification code
     * Validate ID card
     * Validate email
     */

    // 2. If the user uploaded an avatar, convert it to base64 code for saving
    /**
     * Create a FileReader object
     * Convert the image to base64 code
     */

    // 3. Call the registration interface
    // ...
}

This function contains three functionalities: validation, conversion, and registration. The validation and conversion functionalities can be extracted and encapsulated into separate functions:

function register(data) {
    // 1. Validate user data
    // verify()

    // 2. If the user uploaded an avatar, convert it to base64 code for saving
    // tobase64()

    // 3. Call the registration interface
    // ...
}

If you're interested in refactoring, I strongly recommend reading Refactoring (2nd Edition).

References:

Refactoring (2nd Edition)

Summary

I wrote this article mainly to summarize my more than one year of work experience, as I've been primarily researching frontend engineering and how to improve team development efficiency. I hope this article can help beginners with no experience in frontend engineering enter the field through this article.

If this article has been helpful to you, please give it a like. Much appreciated.

24 Front-end Performance Optimization Tips

woai3c — Tue, 01 Apr 2025 04:20:54 +0000

Performance optimization is a double-edged sword, with both good and bad aspects. The good side is that it can improve website performance, while the bad side is that it's complicated to configure, or there are too many rules to follow. Additionally, some performance optimization rules aren't suitable for all scenarios and should be used with caution. Readers should approach this article with a critical eye.

The references for the optimization suggestions in this article will be provided after each suggestion or at the end of the article.

1. Reduce HTTP Requests

A complete HTTP request needs to go through DNS lookup, TCP handshake, browser sending the HTTP request, server receiving the request, server processing the request and sending back a response, browser receiving the response, and other processes. Let's look at a specific example to understand HTTP:

This is an HTTP request, and the file size is 28.4KB.

Terminology explained:

Queueing: Time spent in the request queue.
Stalled: The time difference between when the TCP connection is established and when data can actually be transmitted, including proxy negotiation time.
Proxy negotiation: Time spent negotiating with the proxy server.
DNS Lookup: Time spent performing DNS lookup. Each different domain on a page requires a DNS lookup.
Initial Connection / Connecting: Time spent establishing a connection, including TCP handshake/retry and SSL negotiation.
SSL: Time spent completing the SSL handshake.
Request sent: Time spent sending the network request, usually a millisecond.
Waiting (TFFB): TFFB is the time from when the page request is made until the first byte of response data is received.
Content Download: Time spent receiving the response data.

From this example, we can see that the actual data download time accounts for only 13.05 / 204.16 = 6.39% of the total. The smaller the file, the smaller this ratio; the larger the file, the higher the ratio. This is why it's recommended to combine multiple small files into one large file, thereby reducing the number of HTTP requests.

How to combine multiple files

There are several techniques to reduce the number of HTTP requests by combining files:

1. Bundle JavaScript files with Webpack

// webpack.config.js
module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
  },
};

This will combine all JavaScript files imported in your entry point into a single bundle.

2. Combine CSS files
Using CSS preprocessors like Sass:

/* main.scss */
@import 'reset';
@import 'variables';
@import 'typography';
@import 'layout';
@import 'components';

Then compile to a single CSS file:

sass main.scss:main.css

Reference:

understanding-resource-timing

2. Use HTTP2

Compared to HTTP1.1, HTTP2 has several advantages:

Faster parsing

When parsing HTTP1.1 requests, the server must continuously read bytes until it encounters the CRLF delimiter. Parsing HTTP2 requests isn't as complicated because HTTP2 is a frame-based protocol, and each frame has a field indicating its length.

Multiplexing

With HTTP1.1, if you want to make multiple requests simultaneously, you need to establish multiple TCP connections because one TCP connection can only handle one HTTP1.1 request at a time.

In HTTP2, multiple requests can share a single TCP connection, which is called multiplexing. Each request and response is represented by a stream with a unique stream ID to identify it.
Multiple requests and responses can be sent out of order within the TCP connection and then reassembled at the destination using the stream ID.

Header compression

HTTP2 provides header compression functionality.

For example, consider the following two requests:

:authority: unpkg.zhimg.com
:method: GET
:path: /za-js-sdk@2.16.0/dist/zap.js
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
pragma: no-cache
referer: https://www.zhihu.com/
sec-fetch-dest: script
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

:authority: zz.bdstatic.com
:method: GET
:path: /linksubmit/push.js
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cache-control: no-cache
pragma: no-cache
referer: https://www.zhihu.com/
sec-fetch-dest: script
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

From the two requests above, you can see that a lot of data is repeated. If we could store the same headers and only send the differences between them, we could save a lot of bandwidth and speed up the request time.

HTTP/2 uses "header tables" on the client and server sides to track and store previously sent key-value pairs, and for identical data, it's no longer sent through each request and response.

Here's a simplified example. Suppose the client sends the following header requests in sequence:

Header1:foo
Header2:bar
Header3:bat

When the client sends a request, it creates a table based on the header values:

Index	Header Name	Value
62	Header1	foo
63	Header2	bar
64	Header3	bat

If the server receives the request, it will create the same table.
When the client sends the next request, if the headers are the same, it can directly send a header block like this:

62 63 64

The server will look up the previously established table and restore these numbers to the complete headers they correspond to.

Priority

HTTP2 can set a higher priority for more urgent requests, and the server can prioritize handling them after receiving such requests.

Flow control

Since the bandwidth of a TCP connection (depending on the network bandwidth from client to server) is fixed, when there are multiple concurrent requests, if one request occupies more traffic, another request will occupy less. Flow control can precisely control the flow of different streams.

Server push

A powerful new feature added in HTTP2 is that the server can send multiple responses to a single client request. In other words, in addition to responding to the initial request, the server can also push additional resources to the client without the client explicitly requesting them.

For example, when a browser requests a website, in addition to returning the HTML page, the server can also proactively push resources based on the URLs of resources in the HTML page.

Many websites have already started using HTTP2, such as Zhihu:

Where "h2" refers to the HTTP2 protocol, and "http/1.1" refers to the HTTP1.1 protocol.

References:

3. Use Server-Side Rendering

Client-side rendering: Get the HTML file, download JavaScript files as needed, run the files, generate the DOM, and then render.

Server-side rendering: The server returns the HTML file, and the client only needs to parse the HTML.

Pros: Faster first-screen rendering, better SEO.
Cons: Complicated configuration, increases the computational load on the server.

Below, I'll use Vue SSR as an example to briefly describe the SSR process.

Client-side rendering process

Visit a client-rendered website.
The server returns an HTML file containing resource import statements and <div id="app"></div>.
The client requests resources from the server via HTTP, and when the necessary resources are loaded, it executes new Vue() to instantiate and render the page.

Example of client-side rendered app (Vue):

<!-- index.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Client-side Rendering Example</title>
</head>
<body>
  <!-- Initially empty container -->
  <div id="app"></div>

  <!-- JavaScript bundle that will render the content -->
  <script src="/dist/bundle.js"></script>
</body>
</html>

// main.js (compiled into bundle.js)
import Vue from 'vue';
import App from './App.vue';

// Client-side rendering happens here - after JS loads and executes
new Vue({
  render: h => h(App)
}).$mount('#app');

// App.vue
<template>
  <div>
    <h1>{{ title }}</h1>
    <p>This content is rendered client-side.</p>
  </div>
</template>

<script>
export default {
  data() {
    return {
      title: 'Hello World'
    }
  },
  // In client-side rendering, this lifecycle hook runs in the browser
  mounted() {
    console.log('Component mounted in browser');
  }
}
</script>

Server-side rendering process

Visit a server-rendered website.
The server checks which resource files the current route component needs, then fills the content of these files into the HTML file. If there are AJAX requests, it will execute them for data pre-fetching and fill them into the HTML file, and finally return this HTML page.
When the client receives this HTML page, it can start rendering the page immediately. At the same time, the page also loads resources, and when the necessary resources are fully loaded, it begins to execute new Vue() to instantiate and take over the page.

Example of server-side rendered app (Vue):

// server.js
const express = require('express');
const server = express();
const { createBundleRenderer } = require('vue-server-renderer');

// Create a renderer based on the server bundle
const renderer = createBundleRenderer('./dist/vue-ssr-server-bundle.json', {
  template: require('fs').readFileSync('./index.template.html', 'utf-8'),
  clientManifest: require('./dist/vue-ssr-client-manifest.json')
});

// Handle all routes with the same renderer
server.get('*', (req, res) => {
  const context = { url: req.url };

  // Render our Vue app to a string
  renderer.renderToString(context, (err, html) => {
    if (err) {
      // Handle error
      res.status(500).end('Server Error');
      return;
    }
    // Send the rendered HTML to the client
    res.end(html);
  });
});

server.listen(8080);

<!-- index.template.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Server-side Rendering Example</title>
  <!-- Resources injected by the server renderer -->
</head>
<body>
  <!-- This will be replaced with the app's HTML -->
  <!--vue-ssr-outlet-->
</body>
</html>

// entry-server.js
import { createApp } from './app';

export default context => {
  return new Promise((resolve, reject) => {
    const { app, router } = createApp();

    // Set server-side router's location
    router.push(context.url);

    // Wait until router has resolved possible async components and hooks
    router.onReady(() => {
      const matchedComponents = router.getMatchedComponents();

      // No matched routes, reject with 404
      if (!matchedComponents.length) {
        return reject({ code: 404 });
      }

      // The Promise resolves to the app instance
      resolve(app);
    }, reject);
  });
}

From the two processes above, we can see that the difference lies in the second step. A client-rendered website will directly return the HTML file, while a server-rendered website will render the page completely before returning this HTML file.

What's the benefit of doing this? It's a faster time-to-content.

Suppose your website needs to load four files (a, b, c, d) to render completely. And each file is 1 MB in size.

Calculating this way: a client-rendered website needs to load 4 files and an HTML file to complete the home page rendering, totaling 4MB (ignoring the HTML file size). While a server-rendered website only needs to load a fully rendered HTML file to complete the home page rendering, totaling the size of the already rendered HTML file (which isn't usually too large, generally a few hundred KB; my personal blog website (SSR) loads an HTML file of 400KB). This is why server-side rendering is faster.

References:

4. Use CDN for Static Resources

A Content Delivery Network (CDN) is a set of web servers distributed across multiple geographic locations. We all know that the further the server is from the user, the higher the latency. CDNs are designed to solve this problem by deploying servers in multiple locations, bringing users closer to servers, thereby shortening request times.

CDN Principles

When a user visits a website without a CDN, the process is as follows:

The browser needs to resolve the domain name into an IP address, so it makes a request to the local DNS.
The local DNS makes successive requests to the root server, top-level domain server, and authoritative server to get the IP address of the website's server.
The local DNS sends the IP address back to the browser, and the browser makes a request to the website server's IP address and receives the resources.

If the user is visiting a website that has deployed a CDN, the process is as follows:

The browser needs to resolve the domain name into an IP address, so it makes a request to the local DNS.
The local DNS makes successive requests to the root server, top-level domain server, and authoritative server to get the IP address of the Global Server Load Balancing (GSLB) system.
The local DNS then makes a request to the GSLB. The main function of the GSLB is to determine the user's location based on the local DNS's IP address, filter out the closest local Server Load Balancing (SLB) system to the user, and return the IP address of that SLB to the local DNS.
The local DNS sends the SLB's IP address back to the browser, and the browser makes a request to the SLB.
The SLB selects the optimal cache server based on the resource and address requested by the browser and sends it back to the browser.
The browser then redirects to the cache server based on the address returned by the SLB.
If the cache server has the resource the browser needs, it sends the resource back to the browser. If not, it requests the resource from the source server, sends it to the browser, and caches it locally.

Note: The diagrams above should ideally be recreated with English labels for better clarity.

References:

5. Place CSS in the head and JavaScript Files at the Bottom

CSS execution blocks rendering and prevents JS execution
JS loading and execution block HTML parsing and prevent CSSOM construction

If these CSS and JS tags are placed in the HEAD tag, and they take a long time to load and parse, then the page will be blank. Therefore, JS files should be placed at the bottom (not blocking DOM parsing but will block rendering) so that HTML parsing is completed before loading JS files, presenting the page content to the user as early as possible.

So why should CSS files still be placed in the head?

Because loading HTML first and then loading CSS will make users see an unstyled, "ugly" page at first glance. To avoid this situation, CSS files should be placed in the head.

Additionally, JS files can also be placed in the head as long as the script tag has the defer attribute, which means asynchronous download and delayed execution.

Here's an example of optimal placement:

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Optimized Resource Loading</title>

  <!-- CSS in the head for faster rendering -->
  <link rel="stylesheet" href="styles.css">

  <!-- Critical JS that must load early can use defer -->
  <script defer src="critical.js"></script>
</head>
<body>
  <header>
    <h1>My Website</h1>
    <!-- Page content here -->
  </header>

  <main>
    <p>Content that users need to see quickly...</p>
  </main>

  <footer>
    <!-- Footer content -->
  </footer>

  <!-- Non-critical JavaScript at the bottom -->
  <script src="app.js"></script>
  <script src="analytics.js"></script>
</body>
</html>

Explanation of this approach:

CSS in the <head>: Ensures the page is styled as soon as it renders, preventing the "flash of unstyled content" (FOUC). CSS is render-blocking, but that's actually what we want in this case.
Critical JS with defer: The defer attribute tells the browser to:
- Download the script in parallel while parsing HTML
- Only execute the script after HTML parsing is complete but before the DOMContentLoaded event
- Maintain the order of execution if there are multiple deferred scripts
Non-critical JS before closing </body>: Scripts without special attributes will:
- Block HTML parsing while they download and execute
- By placing them at the bottom, we ensure that all the important content is parsed and displayed first
- This improves perceived performance even if the total load time is the same

You can also use async for scripts that don't depend on DOM or other scripts:

<script async src="independent.js"></script>

The async attribute will download the script in parallel and execute it as soon as it's available, which may interrupt HTML parsing. Use this only for scripts that don't modify the DOM or depend on other scripts.

Reference:

Adding Interactivity with JavaScript

6. Use Font Icons (iconfont) Instead of Image Icons

A font icon is an icon made into a font. When using it, it's just like a font, and you can set attributes such as font-size, color, etc., which is very convenient. Moreover, font icons are vector graphics and won't lose clarity. Another advantage is that the generated files are particularly small.

Compress Font Files

Use the fontmin-webpack plugin to compress font files (thanks to Frontend Xiaowei for providing this).

References:

7. Make Good Use of Caching, Avoid Reloading the Same Resources

To prevent users from having to request files every time they visit a website, we can control this behavior by adding Expires or max-age. Expires sets a time, and as long as it's before this time, the browser won't request the file but will directly use the cache. Max-age is a relative time, and it's recommended to use max-age instead of Expires.

However, this creates a problem: what happens when the file is updated? How do we notify the browser to request the file again?

This can be done by updating the resource link addresses referenced in the page, making the browser actively abandon the cache and load new resources.

The specific approach is to associate the URL modification of the resource address with the file content, which means that only when the file content changes, the corresponding URL will change, thereby achieving file-level precise cache control. What is related to file content? We naturally think of using digest algorithms to derive digest information for the file. The digest information corresponds one-to-one with the file content, providing a basis for cache control that's precise to the granularity of individual files.

Here's how to implement caching and cache-busting:

1. Server-side cache headers (using Express.js as an example):

// Set cache control headers for static resources
app.use('/static', express.static('public', {
  maxAge: '1y', // Cache for 1 year
  etag: true,   // Use ETag for validation
  lastModified: true // Use Last-Modified for validation
}));

// For HTML files that shouldn't be cached as long
app.get('/*.html', (req, res) => {
  res.set({
    'Cache-Control': 'public, max-age=300', // Cache for 5 minutes
    'Expires': new Date(Date.now() + 300000).toUTCString()
  });
  // Send HTML content
});

2. Using content hashes in filenames (Webpack configuration):

// webpack.config.js
module.exports = {
  output: {
    filename: '[name].[contenthash].js', // Uses content hash in filename
    path: path.resolve(__dirname, 'dist'),
  },
  plugins: [
    // Extract CSS into separate files with content hash
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash].css'
    }),
    // Generate HTML with correct hashed filenames
    new HtmlWebpackPlugin({
      template: 'src/index.html'
    })
  ]
};

This will produce output files like:

main.8e0d62a10c151dad4f8e.js
styles.f4e3a77c616562b26ca1.css

When you change the content of a file, its hash will change, forcing the browser to download the new file instead of using the cached version.

3. Example of generated HTML with cache-busting:

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Cache Busting Example</title>
  <!-- Note the content hash in the filename -->
  <link rel="stylesheet" href="/static/styles.f4e3a77c616562b26ca1.css">
</head>
<body>
  <div id="app"></div>
  <!-- Script with content hash -->
  <script src="/static/main.8e0d62a10c151dad4f8e.js"></script>
</body>
</html>

4. Version query parameters (simpler but less effective approach):

<link rel="stylesheet" href="styles.css?v=1.2.3">
<script src="app.js?v=1.2.3"></script>

When updating files, manually change the version number to force a new download.

References:

8. Compress Files

Compressing files can reduce file download time, providing a better user experience.

Thanks to the development of webpack and node, file compression is now very convenient.

In webpack, the following plugins can be used for compression:

JavaScript: UglifyPlugin
CSS: MiniCssExtractPlugin
HTML: HtmlWebpackPlugin

In fact, we can do even better by using gzip compression. This can be enabled by adding the gzip identifier to the Accept-Encoding header in the HTTP request header. Of course, the server must also support this feature.

Gzip is currently the most popular and effective compression method. For example, the app.js file generated after building a project I developed with Vue has a size of 1.4MB, but after gzip compression, it's only 573KB, reducing the volume by nearly 60%.

Here are the methods for configuring gzip in webpack and node.

Download plugins

npm install compression-webpack-plugin --save-dev
npm install compression

webpack configuration

const CompressionPlugin = require('compression-webpack-plugin');

module.exports = {
  plugins: [new CompressionPlugin()],
}

node configuration

const compression = require('compression')
// Use before other middleware
app.use(compression())

9. Image Optimization

(1). Lazy Loading Images

In a page, don't initially set the path for images, only load the actual image when it appears in the browser's viewport. This is lazy loading. For websites with many images, loading all images at once can have a significant impact on user experience, so image lazy loading is necessary.

First, set up the images like this, where images won't load when they're not visible in the page:

<img data-src="https://avatars0.githubusercontent.com/u/22117876?s=460&u=7bd8f32788df6988833da6bd155c3cfbebc68006&v=4">

When the page becomes visible, use JS to load the image:

const img = document.querySelector('img')
img.src = img.dataset.src

This is how the image gets loaded. For the complete code, please refer to the reference materials.

Reference:

Web front-end image lazy loading implementation principles

(2). Responsive Images

The advantage of responsive images is that browsers can automatically load appropriate images based on screen size.

Implementation through picture

<picture>
    <source srcset="banner_w1000.jpg" media="(min-width: 801px)">
    <source srcset="banner_w800.jpg" media="(max-width: 800px)">
    <img src="banner_w800.jpg" alt="">
</picture>

Implementation through @media

@media (min-width: 769px) {
    .bg {
        background-image: url(bg1080.jpg);
    }
}
@media (max-width: 768px) {
    .bg {
        background-image: url(bg768.jpg);
    }
}

(3). Adjust Image Size

For example, if you have a 1920 * 1080 size image, you show it to users as a thumbnail, and only display the full image when users hover over it. If users never actually hover over the thumbnail, the time spent downloading the image is wasted.

Therefore, we can optimize this with two images. Initially, only load the thumbnail, and when users hover over the image, then load the large image. Another approach is to lazy load the large image, manually changing the src of the large image to download it after all elements have loaded.

Example implementation of image size optimization:

<!-- HTML Structure -->
<div class="image-container">
  <img class="thumbnail" src="thumbnail-small.jpg" alt="Small thumbnail">
  <img class="full-size" data-src="image-large.jpg" alt="Full-size image">
</div>

/* CSS for the container and images */
.image-container {
  position: relative;
  width: 200px;
  height: 150px;
  overflow: hidden;
}

.thumbnail {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}

.full-size {
  display: none;
  position: absolute;
  top: 0;
  left: 0;
  z-index: 2;
  max-width: 600px;
  max-height: 400px;
}

/* Show full size on hover */
.image-container:hover .full-size {
  display: block;
}

// JavaScript to lazy load the full-size image
document.addEventListener('DOMContentLoaded', () => {
  const containers = document.querySelectorAll('.image-container');

  containers.forEach(container => {
    const thumbnail = container.querySelector('.thumbnail');
    const fullSize = container.querySelector('.full-size');

    // Load the full-size image when the user hovers over the thumbnail
    container.addEventListener('mouseenter', () => {
      if (!fullSize.src && fullSize.dataset.src) {
        fullSize.src = fullSize.dataset.src;
      }
    });

    // Alternative: Load the full-size image after the page loads completely
    /*
    window.addEventListener('load', () => {
      setTimeout(() => {
        if (!fullSize.src && fullSize.dataset.src) {
          fullSize.src = fullSize.dataset.src;
        }
      }, 1000); // Delay loading by 1 second after window load
    });
    */
  });
});

This implementation:

Shows only the thumbnail initially
Loads the full-size image only when the user hovers over the thumbnail
Provides an alternative approach to load all full-size images with a delay after page load

(4). Reduce Image Quality

For example, with JPG format images, there's usually no noticeable difference between 100% quality and 90% quality, especially when used as background images. When cutting background images in PS, I often cut the image into JPG format and compress it to 60% quality, and basically can't see any difference.

There are two compression methods: one is through the webpack plugin image-webpack-loader, and the other is through online compression websites.

Here's how to use the webpack plugin image-webpack-loader:

npm i -D image-webpack-loader

webpack configuration

{
  test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
  use:[
    {
    loader: 'url-loader',
    options: {
      limit: 10000, /* Images smaller than 1000 bytes will be automatically converted to base64 code references */
      name: utils.assetsPath('img/[name].[hash:7].[ext]')
      }
    },
    /* Compress images */
    {
      loader: 'image-webpack-loader',
      options: {
        bypassOnDebug: true,
      }
    }
  ]
}

(5). Use CSS3 Effects Instead of Images When Possible

Many images can be drawn with CSS effects (gradients, shadows, etc.), and in these cases, CSS3 effects are better. This is because code size is usually a fraction or even a tenth of the image size.

Reference:

Using images in webpack

(6). Use webp Format Images

WebP's advantage is reflected in its better image data compression algorithm, which brings smaller image volume while maintaining image quality that's indistinguishable to the naked eye. It also has lossless and lossy compression modes, Alpha transparency, and animation features. Its conversion effects on JPEG and PNG are quite excellent, stable, and uniform.

Example of implementing WebP with fallbacks:

<!-- Using the picture element for WebP with fallback -->
<picture>
  <source srcset="image.webp" type="image/webp">
  <source srcset="image.jpg" type="image/jpeg">
  <img src="image.jpg" alt="Description of the image">
</picture>

Server-side WebP detection and serving:

// Express.js example
app.get('/images/:imageName', (req, res) => {
  const supportsWebP = req.headers.accept && req.headers.accept.includes('image/webp');
  const imagePath = supportsWebP 
    ? `public/images/${req.params.imageName}.webp` 
    : `public/images/${req.params.imageName}.jpg`;

  res.sendFile(path.resolve(__dirname, imagePath));
});

Reference:

What are the advantages of WebP compared to PNG and JPG?

10. Load Code on Demand Through Webpack, Extract Third-Party Libraries, Reduce Redundant Code When Converting ES6 to ES5

The following quote from the official Webpack documentation explains the concept of lazy loading:

"Lazy loading or on-demand loading is a great way to optimize a website or application. This approach actually separates your code at some logical breakpoints, and then immediately references or is about to reference some new code blocks after completing certain operations in some code blocks. This speeds up the initial loading of the application and lightens its overall volume because some code blocks may never be loaded."

Quote source: Lazy Loading

Note: While image lazy loading (discussed in section 9.1) delays the loading of image resources until they're visible in the viewport, code lazy loading splits JavaScript bundles and loads code fragments only when they're needed for specific functionality. They both improve initial load time, but they work at different levels of resource optimization.

Generate File Names Based on File Content, Combined with Import Dynamic Import of Components to Achieve On-Demand Loading

This requirement can be achieved by configuring the filename property of output. One of the value options in the filename property is [contenthash], which creates a unique hash based on file content. When the file content changes, [contenthash] also changes.

output: {
    filename: '[name].[contenthash].js',
    chunkFilename: '[name].[contenthash].js',
    path: path.resolve(__dirname, '../dist'),
},

Example of code lazy loading in a Vue application:

// Instead of importing synchronously like this:
// import UserProfile from './components/UserProfile.vue'

// Use dynamic import for route components:
const UserProfile = () => import('./components/UserProfile.vue')

// Then use it in your routes
const router = new VueRouter({
  routes: [
    { path: '/user/:id', component: UserProfile }
  ]
})

This ensures the UserProfile component is only loaded when a user navigates to that route, not on initial page load.

Extract Third-Party Libraries

Since imported third-party libraries are generally stable and don't change frequently, extracting them separately as long-term caches is a better choice.
This requires using the cacheGroups option of webpack4's splitChunk plugin.

optimization: {
    runtimeChunk: {
        name: 'manifest' // Split webpack's runtime code into a separate chunk.
    },
    splitChunks: {
        cacheGroups: {
            vendor: {
                name: 'chunk-vendors',
                test: /[\\/]node_modules[\\/]/,
                priority: -10,
                chunks: 'initial'
            },
            common: {
                name: 'chunk-common',
                minChunks: 2,
                priority: -20,
                chunks: 'initial',
                reuseExistingChunk: true
            }
        },
    }
},

test: Used to control which modules are matched by this cache group. If passed unchanged, it defaults to select all modules. Types of values that can be passed: RegExp, String, and Function;
priority: Indicates extraction weight, with higher numbers indicating higher priority. Since a module might meet the conditions of multiple cacheGroups, extraction is determined by the highest weight;
reuseExistingChunk: Indicates whether to use existing chunks. If true, it means that if the current chunk contains modules that have already been extracted, new ones won't be generated.
minChunks (default is 1): The minimum number of times this code block should be referenced before splitting (note: to ensure code block reusability, the default strategy doesn't require multiple references to be split)
chunks (default is async): initial, async, and all
name (name of the packaged chunks): String or function (functions can customize names based on conditions)

Reduce Redundant Code When Converting ES6 to ES5

To achieve the same functionality as the original code after Babel conversion, some helper functions are needed, for example:

class Person {}

will be converted to:

"use strict";

function _classCallCheck(instance, Constructor) {
  if (!(instance instanceof Constructor)) {
    throw new TypeError("Cannot call a class as a function");
  }
}

var Person = function Person() {
  _classCallCheck(this, Person);
};

Here, _classCallCheck is a helper function. If classes are declared in many files, then many such helper functions will be generated.

The @babel/runtime package declares all the helper functions needed, and the role of @babel/plugin-transform-runtime is to import all files that need helper functions from the @babel/runtime package:

"use strict";

var _classCallCheck2 = require("@babel/runtime/helpers/classCallCheck");

var _classCallCheck3 = _interopRequireDefault(_classCallCheck2);

function _interopRequireDefault(obj) {
  return obj && obj.__esModule ? obj : { default: obj };
}

var Person = function Person() {
  (0, _classCallCheck3.default)(this, Person);
};

Here, the helper function classCallCheck is no longer compiled, but instead references helpers/classCallCheck from @babel/runtime.

Installation

npm i -D @babel/plugin-transform-runtime @babel/runtime

Usage
In the .babelrc file

"plugins": [
        "@babel/plugin-transform-runtime"
]

References:

11. Reduce Reflows and Repaints

Browser Rendering Process

Parse HTML to generate DOM tree.
Parse CSS to generate CSSOM rules tree.
Combine DOM tree and CSSOM rules tree to generate rendering tree.
Traverse the rendering tree to begin layout, calculating the position and size information of each node.
Paint each node of the rendering tree to the screen.

Reflow

When the position or size of DOM elements is changed, the browser needs to regenerate the rendering tree, a process called reflow.

Repaint

After regenerating the rendering tree, each node of the rendering tree needs to be painted to the screen, a process called repaint. Not all actions will cause reflow, for example, changing font color will only cause repaint. Remember, reflow will cause repaint, but repaint will not cause reflow.

Both reflow and repaint operations are very expensive because the JavaScript engine thread and the GUI rendering thread are mutually exclusive, and only one can work at a time.

What operations will cause reflow?

Adding or removing visible DOM elements
Element position changes
Element size changes
Content changes
Browser window size changes

How to reduce reflows and repaints?

When modifying styles with JavaScript, it's best not to write styles directly, but to replace classes to change styles.
If you need to perform a series of operations on a DOM element, you can take the DOM element out of the document flow, make modifications, and then bring it back to the document. It's recommended to use hidden elements (display:none) or document fragments (DocumentFragement), both of which can implement this approach well.

Example of causing unnecessary reflows (inefficient):

// This causes multiple reflows as each style change triggers a reflow
const element = document.getElementById('myElement');
element.style.width = '100px';
element.style.height = '200px';
element.style.margin = '10px';
element.style.padding = '20px';
element.style.borderRadius = '5px';

Optimized version 1 - Using CSS classes:

/* style.css */
.my-modified-element {
  width: 100px;
  height: 200px;
  margin: 10px;
  padding: 20px;
  border-radius: 5px;
}

// Only one reflow happens when the class is added
document.getElementById('myElement').classList.add('my-modified-element');

Optimized version 2 - Batching style changes:

// Batching style changes using cssText
const element = document.getElementById('myElement');
element.style.cssText = 'width: 100px; height: 200px; margin: 10px; padding: 20px; border-radius: 5px;';

Optimized version 3 - Using document fragments (for multiple elements):

// Instead of adding elements one by one
const list = document.getElementById('myList');
const fragment = document.createDocumentFragment();

for (let i = 0; i < 100; i++) {
  const item = document.createElement('li');
  item.textContent = `Item ${i}`;
  fragment.appendChild(item);
}

// Only one reflow happens when the fragment is appended
list.appendChild(fragment);

Optimized version 4 - Take element out of flow, modify, then reinsert:

// Remove from DOM, make changes, then reinsert
const element = document.getElementById('myElement');
const parent = element.parentNode;
const nextSibling = element.nextSibling;

// Remove (causes one reflow)
parent.removeChild(element);

// Make multiple changes (no reflows while detached)
element.style.width = '100px';
element.style.height = '200px';
element.style.margin = '10px';
element.style.padding = '20px';
element.style.borderRadius = '5px';

// Reinsert (causes one more reflow)
if (nextSibling) {
  parent.insertBefore(element, nextSibling);
} else {
  parent.appendChild(element);
}

Optimized version 5 - Using display:none temporarily:

const element = document.getElementById('myElement');

// Hide element (one reflow)
element.style.display = 'none';

// Make multiple changes (no reflows while hidden)
element.style.width = '100px';
element.style.height = '200px';
element.style.margin = '10px';
element.style.padding = '20px';
element.style.borderRadius = '5px';

// Show element again (one more reflow)
element.style.display = 'block';

By using these optimization techniques, you can significantly reduce the number of reflows and repaints, leading to smoother performance, especially for animations and dynamic content updates.

12. Use Event Delegation

Event delegation takes advantage of event bubbling, allowing you to specify a single event handler to manage all events of a particular type. All events that use buttons (most mouse events and keyboard events) are suitable for the event delegation technique. Using event delegation can save memory.

<ul>
  <li>Apple</li>
  <li>Banana</li>
  <li>Pineapple</li>
</ul>

// good
document.querySelector('ul').onclick = (event) => {
  const target = event.target
  if (target.nodeName === 'LI') {
    console.log(target.innerHTML)
  }
}

// bad
document.querySelectorAll('li').forEach((e) => {
  e.onclick = function() {
    console.log(this.innerHTML)
  }
})

13. Pay Attention to Program Locality

A well-written computer program often has good locality; it tends to reference data items near recently referenced data items or the recently referenced data items themselves. This tendency is known as the principle of locality. Programs with good locality run faster than those with poor locality.

Locality usually takes two different forms:

Temporal locality: In a program with good temporal locality, memory locations that have been referenced once are likely to be referenced multiple times in the near future.
Spatial locality: In a program with good spatial locality, if a memory location has been referenced once, the program is likely to reference a nearby memory location in the near future.

Temporal locality example

function sum(arry) {
    let i, sum = 0
    let len = arry.length

    for (i = 0; i < len; i++) {
        sum += arry[i]
    }

    return sum
}

In this example, the variable sum is referenced once in each loop iteration, so it has good temporal locality.

Spatial locality example

Program with good spatial locality

// Two-dimensional array 
function sum1(arry, rows, cols) {
    let i, j, sum = 0

    for (i = 0; i < rows; i++) {
        for (j = 0; j < cols; j++) {
            sum += arry[i][j]
        }
    }
    return sum
}

Program with poor spatial locality

// Two-dimensional array 
function sum2(arry, rows, cols) {
    let i, j, sum = 0

    for (j = 0; j < cols; j++) {
        for (i = 0; i < rows; i++) {
            sum += arry[i][j]
        }
    }
    return sum
}

Looking at the two spatial locality examples above, the method of accessing each element of the array sequentially starting from each row, as shown in the examples, is called a reference pattern with a stride of 1.
If in an array, every k elements are accessed, it's called a reference pattern with a stride of k.
Generally, as the stride increases, spatial locality decreases.

What's the difference between these two examples? The difference is that the first example scans the array by row, scanning one row completely before moving on to the next row; the second example scans the array by column, scanning one element in a row and immediately going to scan the same column element in the next row.

Arrays are stored in memory in row order, resulting in the example of scanning the array row by row getting a stride-1 reference pattern with good spatial locality; while the other example has a stride of rows, with extremely poor spatial locality.

Performance Testing

Running environment:

CPU: i5-7400
Browser: Chrome 70.0.3538.110

Testing spatial locality on a two-dimensional array with a length of 9000 (child array length also 9000) 10 times, taking the average time (milliseconds), the results are as follows:

The examples used are the two spatial locality examples mentioned above.

Stride 1	Stride 9000
124	2316

From the test results above, the array with a stride of 1 executes an order of magnitude faster than the array with a stride of 9000.

Conclusion:

Programs that repeatedly reference the same variables have good temporal locality
For programs with a reference pattern with a stride of k, the smaller the stride, the better the spatial locality; while programs that jump around in memory with large strides will have very poor spatial locality

Reference:

Computer Systems: A Programmer's Perspective

14. if-else vs switch

As the number of judgment conditions increases, it becomes more preferable to use switch instead of if-else.

if (color == 'blue') {

} else if (color == 'yellow') {

} else if (color == 'white') {

} else if (color == 'black') {

} else if (color == 'green') {

} else if (color == 'orange') {

} else if (color == 'pink') {

}

switch (color) {
    case 'blue':

        break
    case 'yellow':

        break
    case 'white':

        break
    case 'black':

        break
    case 'green':

        break
    case 'orange':

        break
    case 'pink':

        break
}

In situations like the one above, from a readability perspective, using switch is better (JavaScript's switch statement is not based on hash implementation but on loop judgment, so from a performance perspective, if-else and switch are the same).

Why switch is better for multiple conditions:

Improved readability: Switch statements present a clearer visual structure when dealing with multiple conditions against the same variable. The case statements create a more organized, tabular format that's easier to scan and understand.
Cleaner code maintenance: Adding or removing conditions in a switch statement is simpler and less error-prone. With if-else chains, it's easy to accidentally break the chain or forget an "else" keyword.
Less repetition: In the if-else example, we repeat checking the same variable (color) multiple times, while in switch we specify it once at the top.
Better for debugging: When debugging, it's easier to set breakpoints on specific cases in a switch statement than trying to identify which part of a long if-else chain you need to target.
Intent signaling: Using switch communicates to other developers that you're checking multiple possible values of the same variable, rather than potentially unrelated conditions.

For modern JavaScript, there's another alternative worth considering for simple value mapping - object literals:

const colorActions = {
  'blue': () => { /* blue action */ },
  'yellow': () => { /* yellow action */ },
  'white': () => { /* white action */ },
  'black': () => { /* black action */ },
  'green': () => { /* green action */ },
  'orange': () => { /* orange action */ },
  'pink': () => { /* pink action */ }
};

// Execute the action if it exists
if (colorActions[color]) {
  colorActions[color]();
}

This approach provides even better performance (O(1) lookup time) compared to both if-else and switch statement approaches.

15. Lookup Tables

When there are many conditional statements, using switch and if-else is not the best choice. In such cases, you might want to try lookup tables. Lookup tables can be constructed using arrays and objects.

switch (index) {
    case '0':
        return result0
    case '1':
        return result1
    case '2':
        return result2
    case '3':
        return result3
    case '4':
        return result4
    case '5':
        return result5
    case '6':
        return result6
    case '7':
        return result7
    case '8':
        return result8
    case '9':
        return result9
    case '10':
        return result10
    case '11':
        return result11
}

This switch statement can be converted to a lookup table

const results = [result0,result1,result2,result3,result4,result5,result6,result7,result8,result9,result10,result11]

return results[index]

If the conditional statements are not numerical values but strings, you can use an object to build a lookup table

const map = {
  red: result0,
  green: result1,
}

return map[color]

Why lookup tables are better for many conditions:

Constant time complexity (O(1)): Lookup tables provide direct access to the result based on the index/key, making the operation time constant regardless of how many options there are. In contrast, both if-else chains and switch statements have linear time complexity (O(n)) because in the worst case, they might need to check all conditions.
Performance gains with many conditions: As the number of conditions increases, the performance advantage of lookup tables becomes more significant. For a small number of cases (2-5), the difference is negligible, but with dozens or hundreds of cases, lookup tables are substantially faster.
Code brevity: As shown in the examples, lookup tables typically require less code, making your codebase more maintainable.
Dynamic configuration: Lookup tables can be easily populated dynamically:

   const actionMap = {};

   // Dynamically populate the map
   function registerAction(key, handler) {
     actionMap[key] = handler;
   }

   // Register different handlers
   registerAction('save', saveDocument);
   registerAction('delete', deleteDocument);

   // Use it
   if (actionMap[userAction]) {
     actionMap[userAction]();
   }

Reduced cognitive load: When there are many conditions, lookup tables eliminate the mental overhead of following long chains of logic.

When to use each approach:

If-else: Best for a few conditions (2-3) with complex logic or different variables being checked
Switch: Good for moderate number of conditions (4-10) checking against the same variable
Lookup tables: Ideal for many conditions (10+) or when you need O(1) access time

In real applications, lookup tables might be populated from external sources like databases or configuration files, making them flexible for scenarios where the mapping logic might change without requiring code modifications.

16. Avoid Page Stuttering

60fps and Device Refresh Rate

Currently, most devices have a screen refresh rate of 60 times/second. Therefore, if there's an animation or gradient effect on the page, or if the user is scrolling the page, the browser needs to render animations or pages at a rate that matches the device's screen refresh rate.
The budget time for each frame is just over 16 milliseconds (1 second / 60 = 16.66 milliseconds). But in reality, the browser has housekeeping work to do, so all your work needs to be completed within 10 milliseconds. If you can't meet this budget, the frame rate will drop, and content will jitter on the screen. This phenomenon is commonly known as stuttering and has a negative impact on user experience.

Quote source: Google Web Fundamentals - Rendering Performance

Suppose you use JavaScript to modify the DOM, trigger style changes, go through reflow and repaint, and finally paint to the screen. If any of these takes too long, it will cause the rendering time of this frame to be too long, and the average frame rate will drop. Suppose this frame took 50 ms, then the frame rate would be 1s / 50ms = 20fps, and the page would appear to stutter.

For some long-running JavaScript, we can use timers to split and delay execution.

for (let i = 0, len = arry.length; i < len; i++) {
    process(arry[i])
}

Suppose the loop structure above takes too long due to either the high complexity of process() or too many array elements, or both, you might want to try splitting.

const todo = arry.concat()
setTimeout(function() {
    process(todo.shift())
    if (todo.length) {
        setTimeout(arguments.callee, 25)
    } else {
        callback(arry)
    }
}, 25)

If you're interested in learning more, check out High Performance JavaScript Chapter 6 and Efficient Front-end: Web Efficient Programming and Optimization Practices Chapter 3.

Reference:

Rendering Performance

17. Use requestAnimationFrame to Implement Visual Changes

From point 16, we know that most devices have a screen refresh rate of 60 times/second, which means the average time per frame is 16.66 milliseconds. When using JavaScript to implement animation effects, the best case is that the code starts executing at the beginning of each frame. The only way to ensure JavaScript runs at the beginning of a frame is to use requestAnimationFrame.

/**
 * If run as a requestAnimationFrame callback, this
 * will be run at the start of the frame.
 */
function updateScreen(time) {
  // Make visual updates here.
}

requestAnimationFrame(updateScreen);

If you use setTimeout or setInterval to implement animations, the callback function will run at some point in the frame, possibly right at the end, which can often cause us to miss frames, leading to stuttering.

Reference:

Optimize JavaScript Execution

18. Use Web Workers

Web Workers use other worker threads to operate independently of the main thread. They can perform tasks without interfering with the user interface. A worker can send messages to the JavaScript code that created it by sending messages to the event handler specified by that code (and vice versa).

Web Workers are suitable for processing pure data or long-running scripts unrelated to the browser UI.

Creating a new worker is simple, just specify a script URI to execute the worker thread (main.js):

var myWorker = new Worker('worker.js');
// You can send messages to the worker through the postMessage() method and onmessage event
first.onchange = function() {
  myWorker.postMessage([first.value, second.value]);
  console.log('Message posted to worker');
}

second.onchange = function() {
  myWorker.postMessage([first.value, second.value]);
  console.log('Message posted to worker');
}

In the worker, after receiving the message, we can write an event handler function code as a response (worker.js):

onmessage = function(e) {
  console.log('Message received from main script');
  var workerResult = 'Result: ' + (e.data[0] * e.data[1]);
  console.log('Posting message back to main script');
  postMessage(workerResult);
}

The onmessage handler function executes immediately after receiving the message, and the message itself is used as the data property of the event. Here we simply multiply the two numbers and use the postMessage() method again to send the result back to the main thread.

Back in the main thread, we use onmessage again to respond to the message sent back from the worker:

myWorker.onmessage = function(e) {
  result.textContent = e.data;
  console.log('Message received from worker');
}

Here we get the data from the message event and set it as the textContent of result, so the user can directly see the result of the calculation.

Note that inside the worker, you cannot directly manipulate DOM nodes, nor can you use the default methods and properties of the window object. However, you can use many things under the window object, including data storage mechanisms such as WebSockets, IndexedDB, and Firefox OS-specific Data Store API.

Reference:

Web Workers

19. Use Bitwise Operations

Numbers in JavaScript are stored in 64-bit format using the IEEE-754 standard. But in bitwise operations, numbers are converted to 32-bit signed format. Even with the conversion, bitwise operations are much faster than other mathematical and boolean operations.

Modulo

Since the lowest bit of even numbers is 0 and odd numbers is 1, modulo operations can be replaced with bitwise operations.

if (value % 2) {
    // Odd number
} else {
    // Even number 
}
// Bitwise operation
if (value & 1) {
    // Odd number
} else {
    // Even number
}

How it works: The & (bitwise AND) operator compares each bit of the first operand to the corresponding bit of the second operand. If both bits are 1, the corresponding result bit is set to 1; otherwise, it's set to 0.

When we do value & 1, we're only checking the last bit of the number:

For even numbers (e.g., 4 = 100 in binary), the last bit is 0: 100 & 001 = 000 (0)
For odd numbers (e.g., 5 = 101 in binary), the last bit is 1: 101 & 001 = 001 (1)

Floor

~~10.12 // 10
~~10 // 10
~~'1.5' // 1
~~undefined // 0
~~null // 0

How it works: The ~ (bitwise NOT) operator inverts all bits in the operand. For a number n, ~n equals -(n+1). When applied twice (~~n), it effectively truncates the decimal part of a number, similar to Math.floor() for positive numbers and Math.ceil() for negative numbers.

The process:

First ~: Converts the number to a 32-bit integer and inverts all bits
Second ~: Inverts all bits again, resulting in the original number but with decimal part removed

For example:

~10.12 → ~10 → -(10+1) → -11
~(-11) → -(-11+1) → -(-10) → 10

Bitmask

const a = 1
const b = 2
const c = 4
const options = a | b | c

By defining these options, you can use the bitwise AND operation to determine if a/b/c is in the options.

// Is option b in the options?
if (b & options) {
    ...
}

How it works: In bitmasks, each bit represents a boolean flag. The values are typically powers of 2 so each has exactly one bit set.

a = 1: Binary 001
b = 2: Binary 010
c = 4: Binary 100
options = a | b | c: The | (bitwise OR) combines them: 001 | 010 | 100 = 111 (binary) = 7 (decimal)

When checking if a flag is set with if (b & options):

b & options = 010 & 111 = 010 = 2 (decimal)
Since this is non-zero, the condition evaluates to true

This technique is extremely efficient for storing and checking multiple boolean values in a single number, and is commonly used in systems programming, graphics programming, and permission systems.

20. Don't Override Native Methods

No matter how optimized your JavaScript code is, it can't match native methods. This is because native methods are written in low-level languages (C/C++) and compiled into machine code, becoming part of the browser. When native methods are available, try to use them, especially for mathematical operations and DOM manipulations.

Example: String Replacement (Native vs. Custom)

A common pitfall is rewriting native string methods like replaceAll(). Below is an inefficient custom implementation versus the native method, with performance benchmarks:

// Inefficient custom global replacement (manual loop)  
function customReplaceAll(str, oldSubstr, newSubstr) {  
  let result = '';  
  let index = 0;  
  while (index < str.length) {  
    if (str.slice(index, index + oldSubstr.length) === oldSubstr) {  
      result += newSubstr;  
      index += oldSubstr.length;  
    } else {  
      result += str[index];  
      index++;  
    }  
  }  
  return result;  
}  

// Efficient native method (browser-optimized)  
function nativeReplaceAll(str, oldSubstr, newSubstr) {  
  return str.replaceAll(oldSubstr, newSubstr);  
}  

// Test with a large string (100,000 repetitions of "abc ")  
const largeString = 'abc '.repeat(100000);  

// Benchmark: Custom implementation  
console.time('customReplaceAll');  
customReplaceAll(largeString, 'abc', 'xyz');  
console.timeEnd('customReplaceAll'); // Output: ~5ms (varies by browser)  

// Benchmark: Native method  
console.time('nativeReplaceAll');  
nativeReplaceAll(largeString, 'abc', 'xyz');  
console.timeEnd('nativeReplaceAll'); // Output: ~2ms (typically 2-3x faster)

Key Takeaways

Performance: Native methods like replaceAll() are optimized at the browser level, often outperforming handwritten code (as shown in the benchmark above).
Maintainability: Native methods are standardized, well-documented, and less error-prone than custom logic (e.g., handling edge cases like overlapping substrings).
Ecosystem Compatibility: Using native methods ensures consistency with libraries and tools that rely on JavaScript’s built-in behavior.

When to Use Custom Code?

While native methods are usually superior, there are rare cases where you might need custom logic:

When the native method doesn’t exist (e.g., polyfilling for older browsers).
For highly specialized edge cases not covered by native APIs.
When you need to avoid function call overhead in extremely performance-critical loops (e.g., tight numerical computations).

Remember: Browser vendors spend millions of hours optimizing native methods. By leveraging them, you gain free performance boosts and reduce the risk of reinventing flawed solutions.

21. Reduce the Complexity of CSS Selectors

(1). When browsers read selectors, they follow the principle of reading from right to left.

Let's look at an example

#block .text p {
    color: red;
}

Find all P elements.
Check if the elements found in result 1 have parent elements with class name "text"
Check if the elements found in result 2 have parent elements with ID "block"

Why is this inefficient? This right-to-left evaluation process can be very expensive in complex documents. Take the selector #block .text p as an example:

The browser first finds all p elements in the document (potentially hundreds)
For each of those paragraph elements, it must check if any of their ancestors have the class text
For those that pass step 2, it must check if any of their ancestors have the ID block

This creates a significant performance bottleneck because:

The initial selection (p) is very broad
Each subsequent step requires checking multiple ancestors in the DOM tree
This process repeats for every paragraph element

A more efficient alternative would be:

#block p.specific-text {
    color: red;
}

This is more efficient because:

It directly targets only paragraphs with a specific class, avoiding checking all paragraphs

(2). CSS selector priority

Inline > ID selector > Class selector > Tag selector

Based on the above two pieces of information, we can draw conclusions.

The shorter the selector, the better.
Try to use high-priority selectors, such as ID and class selectors.
Avoid using the universal selector *.

Practical advice for optimal CSS selectors:

/* ❌ Inefficient: Too deep, starts with a tag selector */
body div.container ul li a.link {
    color: blue;
}

/* ✅ Better: Shorter, starts with a class selector */
.container .link {
    color: blue;
}

/* ✅ Best: Direct, single class selector */
.nav-link {
    color: blue;
}

Finally, I should say that according to the materials I've found, there's no need to optimize CSS selectors because the performance difference between the slowest and fastest selectors is very small.

References:

22. Use Flexbox Instead of Earlier Layout Models

In early CSS layout methods, we could position elements absolutely, relatively, or using floats. Now, we have a new layout method flexbox, which has an advantage over earlier layout methods: better performance.

The screenshot below shows the layout cost of using floats on 1300 boxes:

Then we recreate this example using flexbox:

Now, for the same number of elements and the same visual appearance, the layout time is much less (3.5 milliseconds versus 14 milliseconds in this example).

However, flexbox compatibility is still an issue, not all browsers support it, so use it with caution.

Browser compatibility:

Chrome 29+
Firefox 28+
Internet Explorer 11
Opera 17+
Safari 6.1+ (prefixed with -webkit-)
Android 4.4+
iOS 7.1+ (prefixed with -webkit-)

Reference:

Use flexbox instead of earlier layout models

23. Use Transform and Opacity Properties to Implement Animations

In CSS, transforms and opacity property changes don't trigger reflow and repaint, they are properties that can be processed by the compositor alone.

Example: Inefficient vs. Efficient Animation

❌ Inefficient animation using properties that trigger reflow and repaint:

/* CSS */
.box-inefficient {
  position: absolute;
  left: 0;
  top: 0;
  width: 100px;
  height: 100px;
  background-color: #3498db;
  animation: move-inefficient 2s infinite alternate;
}

@keyframes move-inefficient {
  to {
    left: 300px;
    top: 200px;
    width: 150px;
    height: 150px;
  }
}

This animation constantly triggers layout recalculations (reflow) because it animates position (left/top) and size (width/height) properties.

✅ Efficient animation using transform and opacity:

/* CSS */
.box-efficient {
  position: absolute;
  width: 100px;
  height: 100px;
  background-color: #3498db;
  animation: move-efficient 2s infinite alternate;
}

@keyframes move-efficient {
  to {
    transform: translate(300px, 200px) scale(1.5);
    opacity: 0.7;
  }
}

Why this is better:

transform: translate(300px, 200px) replaces left: 300px; top: 200px
transform: scale(1.5) replaces width: 150px; height: 150px
These transform operations and opacity changes can be handled directly by the GPU without triggering layout or paint operations

Performance comparison:

The inefficient version may drop frames on lower-end devices because each frame requires:
- JavaScript → Style calculations → Layout → Paint → Composite
The efficient version typically maintains 60fps because it only requires:
- JavaScript → Style calculations → Composite

HTML implementation:

<div class="box-inefficient">Inefficient</div>
<div class="box-efficient">Efficient</div>

For complex animations, you can use the Chrome DevTools Performance panel to visualize the difference. The inefficient animation will show many more layout and paint events compared to the efficient one.

Reference:

Use transform and opacity property changes to implement animations

24. Use Rules Reasonably, Avoid Over-Optimization

Performance optimization is mainly divided into two categories:

Load-time optimization
Runtime optimization

Of the 23 suggestions above, the first 10 belong to load-time optimization, and the last 13 belong to runtime optimization. Usually, there's no need to apply all 23 performance optimization rules. It's best to make targeted adjustments based on the website's user group, saving effort and time.

Before solving a problem, you need to identify the problem first, otherwise you won't know where to start. So before doing performance optimization, it's best to investigate the website's loading and running performance.

Check Loading Performance

A website's loading performance mainly depends on white screen time and first screen time.

White screen time: The time from entering the URL to when the page starts displaying content.
First screen time: The time from entering the URL to when the page is completely rendered.

You can get the white screen time by placing the following script before </head>.

<script>
  new Date() - performance.timing.navigationStart
  // You can also use domLoading and navigationStart
  performance.timing.domLoading - performance.timing.navigationStart
</script>

You can get the first screen time by executing new Date() - performance.timing.navigationStart in the window.onload event.

Check Runtime Performance

With Chrome's developer tools, we can check the website's performance during runtime.

Open the website, press F12 and select performance, click the gray dot in the upper left corner, it turns red to indicate it has started recording. At this point, you can simulate users using the website, and after you're done, click stop, then you'll see the website's performance report during the runtime. If there are red blocks, it means there are frame drops; if it's green, it means the FPS is good. For detailed usage of performance, please search using a search engine, as the scope is limited.

By checking the loading and runtime performance, I believe you already have a general understanding of the website's performance. So what you need to do now is to use the 23 suggestions above to optimize your website. Go for it!

References:

performance.timing.navigationStart

Other References

Conclusion

Performance optimization is a critical aspect of modern web development that directly impacts user experience, engagement, and ultimately, business outcomes. Throughout this article, we've explored 24 diverse techniques spanning various layers of web applications - from network optimization to rendering performance and JavaScript execution.

Key Takeaways

Start with measurement, not optimization. As discussed in point #24, always identify your specific performance bottlenecks before applying optimization techniques. Tools like Chrome DevTools Performance panel, Lighthouse, and WebPageTest can help pinpoint exactly where your application is struggling.
Focus on the critical rendering path. Many of our techniques (placing CSS in the head, JavaScript at the bottom, reducing HTTP requests, server-side rendering) are centered around speeding up the time to first meaningful paint - the moment when users see and can interact with your content.
Understand the browser rendering process. Knowledge of how browsers parse HTML, execute JavaScript, and render pixels to the screen is essential for making informed optimization decisions, especially when dealing with animations and dynamic content.
Balance implementation cost vs. performance gain. Not all optimization techniques are worth implementing for every project. For instance, server-side rendering adds complexity that might not be justified for simple applications, and bitwise operations provide performance gains only in specific heavy computation scenarios.
Consider the device and network conditions of your users. If you're building for users in regions with slower internet connections or less powerful devices, techniques like image optimization, code splitting, and reducing JavaScript payloads become even more important.

Practical Implementation Strategy

Instead of trying to implement all 24 techniques at once, consider taking a phased approach:

First pass: Implement the easy wins with high impact
- Proper image optimization
- HTTP/2
- Basic caching
- CSS/JS placement
Second pass: Address specific measured bottlenecks
- Use performance profiling to identify problem areas
- Apply targeted optimizations based on findings
Ongoing maintenance: Make performance part of your development workflow
- Set performance budgets
- Implement automated performance testing
- Review new feature additions for performance impact

By treating performance as an essential feature rather than an afterthought, you'll create web applications that not only look good and function well but also provide the speed and responsiveness that modern users expect.

Remember that web performance is a continuous journey, not a destination. Browsers evolve, best practices change, and user expectations increase. The techniques in this article provide a strong foundation, but staying current with web performance trends will ensure your applications remain fast and effective for years to come.

Front-End Monitoring: Building an Effective Data Collection and Reporting SDK

woai3c — Sat, 29 Mar 2025 01:35:18 +0000

A complete frontend monitoring system is essential for tracking application performance, errors, and user behavior. It consists of three main components: data collection and reporting, data processing and storage, and data visualization.

This article focuses specifically on the first component - data collection and reporting - showing you how to build a monitoring SDK from scratch. By the end of this article, you'll understand how to gather critical metrics about your application's performance, capture errors, track user behavior, and implement efficient reporting mechanisms.

Below is an outline of the topics we'll cover:

                       ┌────────────────────┐
                       │  Data Collection   │
                       └──────────┬─────────┘
                                  │
         ┌─────────────────┬──────┴──────────────┐
         │                 │                     │
┌────────┴────────┐ ┌──────┴──────┐     ┌────────┴────────┐
│ Error Monitoring │ │ Performance  │     │ Behavior       │
│                  │ │ Monitoring   │     │ Monitoring     │
└────────┬─────────┘ └──────┬──────┘     └────────┬────────┘
         │                  │                     │
┌────────┴────────┐ ┌──────┴──────────┐  ┌────────┴────────┐
│                 │ │                 │  │                 │
│ Resource Loading│ │ Resource Loading│  │     UV, PV      │
│     Errors      │ │      Time       │  │                 │
│                 │ │                 │  │  Page Access    │
│   JS Errors     │ │  API Request    │  │     Depth       │
│                 │ │     Time        │  │                 │
│ Promise Errors  │ │                 │  │   Page Stay     │
│                 │ │   DNS, TCP,     │  │    Duration     │
│ Custom Errors   │ │ First-byte Time │  │                 │
│                 │ │                 │  │  Custom Event   │
│                 │ │   FPS Rate      │  │    Tracking     │
│                 │ │                 │  │                 │
│                 │ │ Cache Hit Rate  │  │   User Clicks   │
│                 │ │                 │  │                 │
│                 │ │  First Screen   │  │ Page Navigation │
│                 │ │  Render Time    │  │                 │
│                 │ │                 │  └─────────────────┘
│                 │ │  FP, FCP, LCP,  │
│                 │ │   FID, LCS,     │
│                 │ │ DOMContentLoaded│
│                 │ │    onload       │
└─────────────────┘ └─────────────────┘

Once data is collected, it needs to be reported to your backend systems for processing and analysis:

                  ┌─────────────────┐
                  │ Data Reporting  │
                  └────────┬────────┘
                           │
          ┌────────────────┴────────────────┐
          │                                 │
┌─────────────────────┐           ┌─────────────────────┐
│  Reporting Methods  │           │  Reporting Timing   │
└──────────┬──────────┘           └──────────┬──────────┘
           │                                 │
     ┌─────┼─────┐               ┌───────────┼───────────┐
     │     │     │               │           │           │
┌────┴───┐ │ ┌───┴────┐ ┌────────┴────────┐ │ ┌─────────┴─────────┐
│  xhr   │ │ │ image  │ │ requestIdle     │ │ │ Upload when cache │
└────────┘ │ └────────┘ │ Callback/       │ │ │ limit is reached  │
           │            │ setTimeout      │ │ └───────────────────┘
     ┌─────┴─────┐      └─────────────────┘ │
     │ sendBeacon│                          │
     └───────────┘                ┌─────────┴──────────┐
                                  │    beforeunload    │
                                  └────────────────────┘

Prerequisites

Before diving into this tutorial, you should have:

Basic knowledge of JavaScript and web development
Familiarity with browser APIs and event handling
Understanding of asynchronous programming concepts
Some experience with performance optimization concepts

Since theoretical knowledge alone can be difficult to grasp, I've created a simple monitoring SDK that implements these technical concepts. You can use it to create simple demos and gain a better understanding. Reading this article while experimenting with the SDK will provide the best learning experience.

Collect Performance Data
- FP (First Paint)
- FCP (First Contentful Paint)
- LCP (Largest Contentful Paint)
- CLS (Cumulative Layout Shift)
- DOMContentLoaded and Load Events
- First Screen Rendering Time
- API Request Timing
- Resource Loading Time and Cache Hit Rate
- Browser Back/Forward Cache
- FPS
- Vue Router Change Rendering Time
Error Data Collection
- Resource Loading Errors
- JavaScript Errors
- Promise Errors
- Sourcemap
- Vue Errors
Behavior Data Collection
- PV and UV
- Page Stay Duration
- Page Access Depth
- User Clicks
- Page Navigation
- Vue Router Changes
Data Reporting
- Reporting Methods
- Reporting Timing
Summary
References
- Performance Monitoring
- Error Monitoring
- Behavior Monitoring

Collect Performance Data

Monitoring performance is crucial for providing users with a smooth, responsive experience. Slow websites lead to higher bounce rates and reduced conversions. By collecting performance metrics, you can identify bottlenecks, optimize critical rendering paths, and improve overall user satisfaction.

The Chrome developer team has proposed a series of metrics to monitor page performance, each measuring a different aspect of the user experience:

FP (First Paint) - Time from when the page starts loading until the first pixel is painted on the screen (essentially the white screen time)
FCP (First Contentful Paint) - Time from page load start until any part of page content is rendered
LCP (Largest Contentful Paint) - Time from page load start until the largest text block or image element completes rendering
CLS (Cumulative Layout Shift) - Cumulative score of all unexpected layout shifts occurring between page load start and when the page's lifecycle state becomes hidden

We can obtain these four performance metrics through PerformanceObserver (they can also be retrieved via performance.getEntriesByName(), but this method doesn't provide real-time notifications when events occur). PerformanceObserver is a performance monitoring interface used to observe performance measurement events.

Let's examine each of these metrics in detail and see how to implement them in our SDK.

FP

First Paint (FP) marks the point when the browser renders anything visually different from what was on the screen before navigation. This could be a background color change or any visual element that indicates to the user that the page is loading.

Implementation code:

const entryHandler = (list) => {        
    for (const entry of list.getEntries()) {
        if (entry.name === 'first-paint') {
            observer.disconnect()
        }
        console.log(entry)
    }
}

const observer = new PerformanceObserver(entryHandler)
// The buffered property indicates whether to observe cached data, 
// allowing observation even if the monitoring code is added after the event occurs
observer.observe({ type: 'paint', buffered: true })

This code creates a new PerformanceObserver that watches for 'paint' type events. When the first-paint event occurs, it logs the entry information and disconnects the observer since we only need to capture this event once per page load. The observer's observe() method is configured with buffered: true to ensure we can catch paint events that occurred before our code runs.

The FP measurement output:

{
    duration: 0,
    entryType: "paint",
    name: "first-paint",
    startTime: 359, // FP time
}

The startTime value represents the paint timing we need. This value (359ms in this example) tells us how long it took from the start of navigation until the first visual change appeared on screen. You can use this metric to optimize your critical rendering path and reduce the time users spend looking at a blank screen.

FCP

FCP (First Contentful Paint) - Time from page load start until any part of page content is rendered. The "content" in this metric refers to text, images (including background images), <svg> elements, and non-white <canvas> elements.

To provide a good user experience, the FCP score should be kept under 1.8 seconds.

The measurement code:

const entryHandler = (list) => {        
    for (const entry of list.getEntries()) {
        if (entry.name === 'first-contentful-paint') {
            observer.disconnect()
        }

        console.log(entry)
    }
}

const observer = new PerformanceObserver(entryHandler)
observer.observe({ type: 'paint', buffered: true })

We can get the value of FCP via the above code:

{
    duration: 0,
    entryType: "paint",
    name: "first-contentful-paint",
    startTime: 459, // fcp 时间
}

The startTime value is the painting time we need.

LCP

LCP (Largest Contentful Paint) - Time from page load start until the largest text block or image element completes rendering. The LCP metric reports the relative render time of the largest visible image or text block in the viewport, measured from when the page first begins loading.

A good LCP score should be kept under 2.5 seconds.

The measurement code:

const entryHandler = (list) => {
    if (observer) {
        observer.disconnect()
    }

    for (const entry of list.getEntries()) {
        console.log(entry)
    }
}

const observer = new PerformanceObserver(entryHandler)
observer.observe({ type: 'largest-contentful-paint', buffered: true })

We can get the value of LCP via the above code:

{
    duration: 0,
    element: p,
    entryType: "largest-contentful-paint",
    id: "",
    loadTime: 0,
    name: "",
    renderTime: 1021.299,
    size: 37932,
    startTime: 1021.299,
    url: "",
}

The startTime value is the painting time we need. And element refers to the element being painted during LCP.

The difference between FCP and LCP is: FCP event occurs when any content is painted, while LCP event occurs when the largest content finishes rendering.

LCP considers these elements:

<img> elements
<image> elements inside <svg>
<video> elements (using poster images)
Elements with background images loaded via the url() function (not using CSS gradients)
Block-level elements containing text nodes or other inline-level text elements

CLS

CLS (Cumulative Layout Shift) - Cumulative score of all unexpected layout shifts occurring between page load start and when the page's lifecycle state becomes hidden.

An "unexpected layout shift" occurs when elements on a page move around without user interaction. Common examples include:

A banner or ad suddenly appearing at the top of the page, pushing content down
A font loading and changing the size of text
An image loading without predefined dimensions, expanding and pushing other content out of the way
A button appearing below where a user is about to click, causing them to click the wrong element

These shifts are frustrating for users and lead to accidental clicks, lost reading position, and overall poor user experience. CLS helps quantify this problem so you can identify and fix problematic elements.

The layout shift score is calculated as follows:

layout shift score = impact score × distance score

The impact score measures how unstable elements affect the visible area between two frames. The distance score is calculated by taking the greatest distance any unstable element has moved (either horizontally or vertically) and dividing it by the viewport's largest dimension (width or height, whichever is greater).

CLS is the sum of all layout shift scores.

A layout shift occurs when a DOM element changes position between two rendered frames, as shown below:

In the above diagram, the rectangle moves from the top-left to the right side, counting as one layout shift. In CLS terminology, there's a concept called "session window": one or more individual layout shifts occurring in rapid succession, with less than 1 second between each shift and a maximum window duration of 5 seconds.

For example, in the second session window shown above, there are four layout shifts. Each shift must occur less than 1 second after the previous one, and the time between the first and last shifts must not exceed 5 seconds to qualify as a session window. If these conditions aren't met, it's considered a new session window. This specification comes from extensive experimentation and research by the Chrome team, as detailed in Evolving the CLS metric.

CLS has three calculation methods:

Cumulative
Average of all session windows
Maximum of all session windows

Cumulative

This method adds up all layout shift scores from page load start. However, this approach disadvantages long-lived pages - the longer a page is open, the higher the CLS score becomes.

Average of All Session Windows

This method calculates based on session windows rather than individual layout shifts, taking the average of all session window scores. However, this approach has limitations.

As shown above, if the first session window has a high CLS score and the second has a low score, averaging them masks the actual page behavior. The average doesn't reflect that the page had more shifts early on and fewer later.

Maximum of All Session Windows

This is currently the optimal calculation method, using the highest session window score to reflect the worst-case scenario for layout shifts. For more details, see Evolving the CLS metric.

Below is the implementation code for the third calculation method:

let sessionValue = 0
let sessionEntries = []
const cls = {
    subType: 'layout-shift',
    name: 'layout-shift',
    type: 'performance',
    pageURL: getPageURL(),
    value: 0,
}

const entryHandler = (list) => {
    for (const entry of list.getEntries()) {
        // Only count layout shifts without recent user input.
        if (!entry.hadRecentInput) {
            const firstSessionEntry = sessionEntries[0]
            const lastSessionEntry = sessionEntries[sessionEntries.length - 1]

            // If the entry occurred less than 1 second after the previous entry and
            // less than 5 seconds after the first entry in the session, include the
            // entry in the current session. Otherwise, start a new session.
            if (
                sessionValue
                && entry.startTime - lastSessionEntry.startTime < 1000
                && entry.startTime - firstSessionEntry.startTime < 5000
            ) {
                sessionValue += entry.value
                sessionEntries.push(formatCLSEntry(entry))
            } else {
                sessionValue = entry.value
                sessionEntries = [formatCLSEntry(entry)]
            }

            // If the current session value is larger than the current CLS value,
            // update CLS and the entries contributing to it.
            if (sessionValue > cls.value) {
                cls.value = sessionValue
                cls.entries = sessionEntries
                cls.startTime = performance.now()
                lazyReportCache(deepCopy(cls))
            }
        }
    }
}

const observer = new PerformanceObserver(entryHandler)
observer.observe({ type: 'layout-shift', buffered: true })

A single layout shift measurement contains the following data:

{
  duration: 0,
  entryType: "layout-shift",
  hadRecentInput: false,
  lastInputTime: 0,
  name: "",
  sources: (2) [LayoutShiftAttribution, LayoutShiftAttribution],
  startTime: 1176.199999999255,
  value: 0.000005752046026677329,
}

The value field represents the layout shift score.

DOMContentLoaded and Load Events

The DOMContentLoaded event is triggered when the HTML is fully loaded and parsed, without waiting for CSS, images, and iframes to load.

The load event is triggered when the entire page and all dependent resources such as stylesheets and images have finished loading.

Although these performance metrics are older, they still provide valuable insights into page behavior. Monitoring them remains necessary.

import { lazyReportCache } from '../utils/report'

['load', 'DOMContentLoaded'].forEach(type => onEvent(type))

function onEvent(type) {
    function callback() {
        lazyReportCache({
            type: 'performance',
            subType: type.toLocaleLowerCase(),
            startTime: performance.now(),
        })

        window.removeEventListener(type, callback, true)
    }

    window.addEventListener(type, callback, true)
}

First Screen Rendering Time

In most cases, the first screen rendering time can be obtained through the load event. However, there are exceptions, such as asynchronously loaded images and DOM elements.

<script>
    setTimeout(() => {
        document.body.innerHTML = `
            <div>
                <!-- lots of code... -->
            </div>
        `
    }, 3000)
</script>

In such cases, we cannot obtain the first screen rendering time through the load event. Instead, we need to use MutationObserver to get the first screen rendering time. MutationObserver triggers events when the properties of the DOM elements it's monitoring change.

The process of calculating first screen rendering time:

Use MutationObserver to monitor the document object, triggering events whenever DOM element properties change.
Check if the DOM element is in the first screen. If it is, call performance.now() in the requestAnimationFrame() callback function to get the current time as its rendering time.
Compare the rendering time of the last DOM element with the loading time of all images in the first screen, and use the maximum value as the first screen rendering time.

Monitoring DOM

const next = window.requestAnimationFrame ? requestAnimationFrame : setTimeout
const ignoreDOMList = ['STYLE', 'SCRIPT', 'LINK']

observer = new MutationObserver(mutationList => {
    const entry = {
        children: [],
    }

    for (const mutation of mutationList) {
        if (mutation.addedNodes.length && isInScreen(mutation.target)) {
             // ...
        }
    }

    if (entry.children.length) {
        entries.push(entry)
        next(() => {
            entry.startTime = performance.now()
        })
    }
})

observer.observe(document, {
    childList: true,
    subtree: true,
})

The code above monitors DOM changes while filtering out style, script, and link tags.

Checking if Element is in First Screen

A page may have a lot of content, but users can only see one screen at a time. Therefore, when calculating first screen rendering time, we need to limit the scope to content visible in the current screen.

const viewportWidth = window.innerWidth
const viewportHeight = window.innerHeight

// Check if DOM element is in screen
function isInScreen(dom) {
    const rectInfo = dom.getBoundingClientRect()
    if (
        rectInfo.left >= 0 
        && rectInfo.left < viewportWidth
        && rectInfo.top >= 0
        && rectInfo.top < viewportHeight
    ) {
        return true
    }
}

Using `requestAnimationFrame()` to Get DOM Rendering Time

When DOM changes trigger the MutationObserver event, it only means the DOM content can be read, not that it has been painted to the screen.

As shown in the image above, when the MutationObserver event is triggered, we can read that document.body already has content, but the left side of the screen hasn't painted anything yet. Therefore, we need to call requestAnimationFrame() to get the current time as the DOM rendering time after the browser has successfully painted.

Comparing with All Image Loading Times in First Screen

function getRenderTime() {
    let startTime = 0
    entries.forEach(entry => {
        if (entry.startTime > startTime) {
            startTime = entry.startTime
        }
    })

    // Need to compare with all image loading times in current page, take the maximum
    // Image request time must be less than startTime, response end time must be greater than startTime
    performance.getEntriesByType('resource').forEach(item => {
        if (
            item.initiatorType === 'img'
            && item.fetchStart < startTime 
            && item.responseEnd > startTime
        ) {
            startTime = item.responseEnd
        }
    })

    return startTime
}

Optimization

The current code still needs optimization, with two main points to consider:

When should we report the rendering time?
How to handle asynchronously added DOM elements?

For the first point, we must report the rendering time after DOM changes stop, which typically happens after the load event triggers. Therefore, we can report at this point.

For the second point, we can report after the LCP event triggers. Whether DOM elements are loaded synchronously or asynchronously, they need to be painted, so we can monitor the LCP event and only allow reporting after it triggers.

Combining these two approaches, we get the following code:

let isOnLoaded = false
executeAfterLoad(() => {
    isOnLoaded = true
})

let timer
let observer
function checkDOMChange() {
    clearTimeout(timer)
    timer = setTimeout(() => {
        // Calculate first screen rendering time after load and LCP events trigger and DOM tree stops changing
        if (isOnLoaded && isLCPDone()) {
            observer && observer.disconnect()
            lazyReportCache({
                type: 'performance',
                subType: 'first-screen-paint',
                startTime: getRenderTime(),
                pageURL: getPageURL(),
            })

            entries = null
        } else {
            checkDOMChange()
        }
    }, 500)
}

The checkDOMChange() function is called each time the MutationObserver event triggers and needs to be debounced.

API Request Timing

To monitor API request timing, we need to intercept both XMLHttpRequest and fetch requests.

Monitoring XMLHttpRequest

originalProto.open = function newOpen(...args) {
    this.url = args[1]
    this.method = args[0]
    originalOpen.apply(this, args)
}

originalProto.send = function newSend(...args) {
    this.startTime = Date.now()

    const onLoadend = () => {
        this.endTime = Date.now()
        this.duration = this.endTime - this.startTime

        const { status, duration, startTime, endTime, url, method } = this
        const reportData = {
            status,
            duration,
            startTime,
            endTime,
            url,
            method: (method || 'GET').toUpperCase(),
            success: status >= 200 && status < 300,
            subType: 'xhr',
            type: 'performance',
        }

        lazyReportCache(reportData)

        this.removeEventListener('loadend', onLoadend, true)
    }

    this.addEventListener('loadend', onLoadend, true)
    originalSend.apply(this, args)
}

To determine if an XML request is successful, we can check if its status code is between 200 and 299. If it is, the request was successful; otherwise, it failed.

Monitoring fetch

const originalFetch = window.fetch

function overwriteFetch() {
    window.fetch = function newFetch(url, config) {
        const startTime = Date.now()
        const reportData = {
            startTime,
            url,
            method: (config?.method || 'GET').toUpperCase(),
            subType: 'fetch',
            type: 'performance',
        }

        return originalFetch(url, config)
        .then(res => {
            reportData.endTime = Date.now()
            reportData.duration = reportData.endTime - reportData.startTime

            const data = res.clone()
            reportData.status = data.status
            reportData.success = data.ok

            lazyReportCache(reportData)

            return res
        })
        .catch(err => {
            reportData.endTime = Date.now()
            reportData.duration = reportData.endTime - reportData.startTime
            reportData.status = 0
            reportData.success = false

            lazyReportCache(reportData)

            throw err
        })
    }
}

For fetch requests, we can determine success by checking the ok field in the response data. If it's true, the request was successful; otherwise, it failed.

Note: The API request timing we monitor may differ from what's shown in Chrome DevTools. This is because Chrome DevTools shows the time for the entire HTTP request and interface process. However, XHR and fetch are asynchronous requests - after the interface request succeeds, the callback function needs to be called. When the event triggers, the callback function is placed in the message queue, and then the browser processes it. There's also a waiting period in between.

Resource Loading Time and Cache Hit Rate

We can monitor resource and navigation events through PerformanceObserver. If the browser doesn't support PerformanceObserver, we can fall back to using performance.getEntriesByType(entryType).

When the resource event triggers, we can get the corresponding resource list. Each resource object contains the following fields:

From these fields, we can extract useful information:

{
    name: entry.name, // Resource name
    subType: entryType,
    type: 'performance',
    sourceType: entry.initiatorType, // Resource type
    duration: entry.duration, // Resource loading duration
    dns: entry.domainLookupEnd - entry.domainLookupStart, // DNS duration
    tcp: entry.connectEnd - entry.connectStart, // TCP connection duration
    redirect: entry.redirectEnd - entry.redirectStart, // Redirect duration
    ttfb: entry.responseStart, // Time to first byte
    protocol: entry.nextHopProtocol, // Request protocol
    responseBodySize: entry.encodedBodySize, // Response body size
    responseHeaderSize: entry.transferSize - entry.encodedBodySize, // Response header size
    resourceSize: entry.decodedBodySize, // Resource size after decompression
    isCache: isCache(entry), // Whether cache was hit
    startTime: performance.now(),
}

Determining if Resource Hit Cache

Among these resource objects, there's a transferSize field that represents the size of the resource being fetched, including response header fields and response data size. If this value is 0, it means the resource was read directly from cache (forced cache). If this value is not 0 but the encodedBodySize field is 0, it means it used negotiated cache (encodedBodySize represents the size of the response data body).

function isCache(entry) {
    // Read directly from cache or 304
    return entry.transferSize === 0 || (entry.transferSize !== 0 && entry.encodedBodySize === 0)
}

If it doesn't meet the above conditions, it means the cache was not hit. Then we can calculate the cache hit rate by dividing all cached data/total data.

Browser Back/Forward Cache (BFC)

BFC is a memory cache that saves the entire page in memory. When users navigate back, they can see the entire page immediately without refreshing. According to the article bfcache, Firefox and Safari have always supported BFC, while Chrome only supports it in high-version mobile browsers. However, when I tested it, only Safari supported it - my Firefox version might have been different.

However, BFC also has drawbacks. When users navigate back and restore the page from BFC, the original page's code won't execute again. For this reason, browsers provide a pageshow event where we can put code that needs to be executed again.

window.addEventListener('pageshow', function(event) {
  // If this property is true, it means the page was restored from BFC
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

For pages restored from BFC, we also need to collect their FP, FCP, LCP, and other timing metrics.

onBFCacheRestore(event => {
    requestAnimationFrame(() => {
        ['first-paint', 'first-contentful-paint'].forEach(type => {
            lazyReportCache({
                startTime: performance.now() - event.timeStamp,
                name: type,
                subType: type,
                type: 'performance',
                pageURL: getPageURL(),
                bfc: true,
            })
        })
    })
})

The code above is easy to understand. After the pageshow event triggers, we subtract the event timestamp from the current time - this time difference is the rendering time of the performance metrics. Note: For pages restored from BFC, these performance metrics usually have very small values, around 10 ms. Therefore, we need to add an identifier field bfc: true so we can ignore them when doing performance statistics.

FPS

We can calculate the current page's FPS using requestAnimationFrame().

const next = window.requestAnimationFrame 
    ? requestAnimationFrame : (callback) => { setTimeout(callback, 1000 / 60) }

const frames = []

export default function fps() {
    let frame = 0
    let lastSecond = Date.now()

    function calculateFPS() {
        frame++
        const now = Date.now()
        if (lastSecond + 1000 <= now) {
            // Since now - lastSecond is in milliseconds, frame needs to be multiplied by 1000
            const fps = Math.round((frame * 1000) / (now - lastSecond))
            frames.push(fps)

            frame = 0
            lastSecond = now
        }

        // Avoid reporting too frequently, cache a certain amount before reporting
        if (frames.length >= 60) {
            report(deepCopy({
                frames,
                type: 'performace',
                subType: 'fps',
            }))

            frames.length = 0
        }

        next(calculateFPS)
    }

    calculateFPS()
}

The code logic is as follows:

First record an initial time, then each time requestAnimationFrame() triggers, increment the frame count by 1. After one second passes, we can get the current frame rate by dividing frame count/elapsed time.

When three consecutive FPS values below 20 appear, we can determine that the page has become unresponsive. This technique is based on the observation that smooth animations require at least 20 FPS to appear fluid to users.

export function isBlocking(fpsList, below = 20, last = 3) {
    let count = 0
    for (let i = 0; i < fpsList.length; i++) {
        if (fpsList[i] && fpsList[i] < below) {
            count++
        } else {
            count = 0
        }

        if (count >= last) {
            return true
        }
    }

    return false
}

Vue Router Change Rendering Time

We already know how to calculate first screen rendering time, but how do we calculate the page rendering time caused by route changes in SPA applications? This article uses Vue as an example to explain my approach.

export default function onVueRouter(Vue, router) {
    let isFirst = true
    let startTime
    router.beforeEach((to, from, next) => {
        // First page load already has other rendering time metrics available
        if (isFirst) {
            isFirst = false
            return next()
        }

        // Add a new field to router to indicate whether to calculate rendering time
        // Only needed for route changes
        router.needCalculateRenderTime = true
        startTime = performance.now()

        next()
    })

    let timer
    Vue.mixin({
        mounted() {
            if (!router.needCalculateRenderTime) return

            this.$nextTick(() => {
                // Code that only runs after the entire view has been rendered
                const now = performance.now()
                clearTimeout(timer)

                timer = setTimeout(() => {
                    router.needCalculateRenderTime = false
                    lazyReportCache({
                        type: 'performance',
                        subType: 'vue-router-change-paint',
                        duration: now - startTime,
                        startTime: now,
                        pageURL: getPageURL(),
                    })
                }, 1000)
            })
        },
    })
}

The code logic is as follows:

Monitor route hooks - when route changes occur, the router.beforeEach() hook triggers. In this hook's callback function, record the current time as the rendering start time.
Use Vue.mixin() to inject a function into all components' mounted() hooks. Each function executes a debounced function.
When the last component's mounted() triggers, it means all components under this route have been mounted. We can get the rendering time in the this.$nextTick() callback function.

Additionally, we need to consider another case. When not changing routes, there may also be component changes, in which case we shouldn't calculate rendering time in these components' mounted() hooks. Therefore, we need to add a needCalculateRenderTime field - set it to true when changing routes to indicate that rendering time can be calculated.

Error Data Collection

Error monitoring is a critical aspect of frontend monitoring that helps identify issues users encounter while interacting with your application. By tracking and analyzing these errors, you can proactively fix bugs before they affect more users, improving both user experience and application reliability.

In this section, we'll explore how to capture various types of errors including resource loading failures, JavaScript runtime errors, unhandled promises, and framework-specific errors.

Resource Loading Errors

Resource loading errors occur when the browser fails to load external resources like images, stylesheets, scripts, and fonts. These errors can significantly impact user experience by causing missing content, broken layouts, or even preventing core functionality from working.

Using addEventListener() to monitor the error event can capture resource loading failure errors.

// Capture resource loading failure errors js css img...
window.addEventListener('error', e => {
    const target = e.target
    if (!target) return

    if (target.src || target.href) {
        const url = target.src || target.href
        lazyReportCache({
            url,
            type: 'error',
            subType: 'resource',
            startTime: e.timeStamp,
            html: target.outerHTML,
            resourceType: target.tagName,
            paths: e.path.map(item => item.tagName).filter(Boolean),
            pageURL: getPageURL(),
        })
    }
}, true)

This code listens for the global error event with the capture option set to true, which allows it to catch errors from resource elements like <img>, <link>, and <script>. When a resource fails to load, it collects important information including:

The URL of the failed resource
The element type (img, link, script)
The HTML of the element that failed
The DOM path to the element
The page URL where the error occurred

With this data, you can identify which resources are failing most frequently, prioritize fixes, and implement fallback strategies for critical resources.

JavaScript Errors

JavaScript errors occur during script execution and can prevent features from working properly. These include syntax errors, reference errors, type errors, and other runtime exceptions.

Using window.onerror can monitor JavaScript errors.

// Monitor JavaScript errors
window.onerror = (msg, url, line, column, error) => {
    lazyReportCache({
        msg,
        line,
        column,
        error: error.stack,
        subType: 'js',
        pageURL: url,
        type: 'error',
        startTime: performance.now(),
    })
}

This handler captures detailed information about JavaScript errors:

The error message
The file URL where the error occurred
The line and column number of the error
The full error stack trace

This information is invaluable for debugging and fixing issues, especially in production environments where direct debugging isn't possible. By analyzing these errors, you can identify patterns and prioritize fixes for the most common or impactful issues.

Promise Errors

Modern JavaScript applications heavily use Promises for asynchronous operations. When a Promise rejection isn't handled with .catch() or a second argument to .then(), it results in an unhandled rejection which can cause silent failures.

Using addEventListener() to monitor the unhandledrejection event can capture unhandled promise errors.

// Monitor promise errors - drawback is can't get column data
window.addEventListener('unhandledrejection', e => {
    lazyReportCache({
        reason: e.reason?.stack,
        subType: 'promise',
        type: 'error',
        startTime: e.timeStamp,
        pageURL: getPageURL(),
    })
})

This code captures unhandled Promise rejections and reports:

The rejection reason (usually an error object with a stack trace)
The timestamp when the rejection occurred
The page URL where the rejection happened

Tracking unhandled Promise rejections is particularly important for asynchronous operations like API calls, where errors might otherwise go unnoticed. By monitoring these rejections, you can ensure that all asynchronous errors are properly handled and resolved.

Sourcemap

Generally, production environment code is minified, and sourcemap files are not uploaded to production. Therefore, error messages in production environment code are difficult to read. For this reason, we can use source-map to restore these minified code error messages.

When code errors occur, we can get the corresponding filename, line number, and column number:

{
    line: 1,
    column: 17,
    file: 'https:/www.xxx.com/bundlejs',
}

Then call the following code to restore:

async function parse(error) {
    const mapObj = JSON.parse(getMapFileContent(error.url))
    const consumer = await new sourceMap.SourceMapConsumer(mapObj)
    // Remove ./ from webpack://source-map-demo/./src/index.js file
    const sources = mapObj.sources.map(item => format(item))
    // Get original line and column numbers and source file based on minified error information
    const originalInfo = consumer.originalPositionFor({ line: error.line, column: error.column })
    // sourcesContent contains the original source code of each file before minification, find corresponding source code by filename
    const originalFileContent = mapObj.sourcesContent[sources.indexOf(originalInfo.source)]
    return {
        file: originalInfo.source,
        content: originalFileContent,
        line: originalInfo.line,
        column: originalInfo.column,
        msg: error.msg,
        error: error.error
    }
}

function format(item) {
    return item.replace(/(\.\/)*/g, '')
}

function getMapFileContent(url) {
    return fs.readFileSync(path.resolve(__dirname, `./maps/${url.split('/').pop()}.map`), 'utf-8')
}

Each time the project is built, if sourcemap is enabled, each JS file will have a corresponding map file.

bundle.js
bundle.js.map

At this point, the JS file is placed on the static server for user access, while the map file is stored on the server for error message restoration. The source-map library can restore error messages from minified code to their original state. For example, if the minified code error location is line 1, column 47, the restored location might be line 4, column 10. Besides location information, we can also get the original source code.

The image above shows an example of code error restoration. Since this part doesn't belong to the SDK's scope, I created another repository to handle this. Feel free to check it out if you're interested.

Vue Errors

Using window.onerror cannot capture Vue errors - we need to use Vue's provided API for monitoring.

Vue.config.errorHandler = (err, vm, info) => {
    // Print error information to console
    console.error(err)

    lazyReportCache({
        info,
        error: err.stack,
        subType: 'vue',
        type: 'error',
        startTime: performance.now(),
        pageURL: getPageURL(),
    })
}

Behavior Data Collection

Understanding how users interact with your application is crucial for optimizing user experience, improving engagement, and driving business goals. Behavior monitoring tracks user actions, navigation patterns, and engagement metrics to provide insights into how your application is actually being used.

In this section, we'll explore how to collect key behavioral metrics that can help you make data-driven decisions to improve your application.

PV and UV

PV (Page View) is the number of page views, while UV (Unique Visitor) is the number of unique users visiting. PV counts each page visit, while UV only counts once per user per day.

Why this matters: PV and UV metrics help you understand your application's traffic patterns. A high PV-to-UV ratio indicates users are viewing multiple pages, suggesting good engagement. Tracking these metrics over time helps you identify growth trends, seasonal patterns, and the impact of marketing campaigns or feature releases.

For frontend, we just need to report PV each time a page is entered. UV statistics are handled on the server side, mainly analyzing reported data to calculate UV.

export default function pv() {
    lazyReportCache({
        type: 'behavior',
        subType: 'pv',
        startTime: performance.now(),
        pageURL: getPageURL(),
        referrer: document.referrer,
        uuid: getUUID(),
    })
}

You can use this data to:

Track which pages are most popular
Identify underperforming pages that need improvement
Analyze user flow through your application
Measure the effectiveness of new features or content

Page Stay Duration

Record an initial time when users enter the page, then subtract the initial time from the current time when users leave the page to get the stay duration. This calculation logic can be placed in the beforeunload event.

Why this matters: Page stay duration indicates how engaging your content is. Longer durations typically suggest users find the content valuable, while very short durations might indicate confusion, irrelevant content, or usability issues. This metric helps you identify which pages effectively capture user attention and which ones need improvement.

export default function pageAccessDuration() {
    onBeforeunload(() => {
        report({
            type: 'behavior',
            subType: 'page-access-duration',
            startTime: performance.now(),
            pageURL: getPageURL(),
            uuid: getUUID(),
        }, true)
    })
}

With page stay duration data, you can:

Identify engaging vs. problematic content
Set benchmarks for content performance
Detect potential usability issues (extremely short durations)
Measure the effectiveness of content updates or redesigns

Page Access Depth

Recording page access depth is very useful. For example, for different activity pages a and b, if page a has an average access depth of 50% and page b has 80%, it indicates that page b is more popular with users. Based on this, we can make targeted improvements to page a.

Why this matters: Access depth measures how far users scroll down a page, revealing whether they're viewing all your content or abandoning it partway through. This metric helps identify content engagement patterns and potential issues with content structure or page length.

Additionally, we can use access depth and stay duration to identify e-commerce order fraud. For example, if someone enters the page and immediately scrolls to the bottom, then waits a while before purchasing, while another person slowly scrolls down the page before purchasing. Even though they have the same stay duration, the first person is more likely to be committing fraud.

The page access depth calculation process is slightly more complex:

When users enter the page, record the current time, scrollTop value, viewport height, and total page height.
When users scroll the page, the scroll event triggers. In the callback function, use the data from point 1 to calculate page access depth and stay duration.
When users stop scrolling at a certain point to continue viewing the page, record the current time, scrollTop value, viewport height, and total page height.
Repeat point 2...

Here's the specific code:

let timer
let startTime = 0
let hasReport = false
let pageHeight = 0
let scrollTop = 0
let viewportHeight = 0

export default function pageAccessHeight() {
    window.addEventListener('scroll', onScroll)

    onBeforeunload(() => {
        const now = performance.now()
        report({
            startTime: now,
            duration: now - startTime,
            type: 'behavior',
            subType: 'page-access-height',
            pageURL: getPageURL(),
            value: toPercent((scrollTop + viewportHeight) / pageHeight),
            uuid: getUUID(),
        }, true)
    })

    // Initialize and record current access height and time after page loads
    executeAfterLoad(() => {
        startTime = performance.now()
        pageHeight = document.documentElement.scrollHeight || document.body.scrollHeight
        scrollTop = document.documentElement.scrollTop || document.body.scrollTop
        viewportHeight = window.innerHeight
    })
}

function onScroll() {
    clearTimeout(timer)
    const now = performance.now()

    if (!hasReport) {
        hasReport = true
        lazyReportCache({
            startTime: now,
            duration: now - startTime,
            type: 'behavior',
            subType: 'page-access-height',
            pageURL: getPageURL(),
            value: toPercent((scrollTop + viewportHeight) / pageHeight),
            uuid: getUUID(),
        })
    }

    timer = setTimeout(() => {
        hasReport = false
        startTime = now
        pageHeight = document.documentElement.scrollHeight || document.body.scrollHeight
        scrollTop = document.documentElement.scrollTop || document.body.scrollTop
        viewportHeight = window.innerHeight        
    }, 500)
}

function toPercent(val) {
    if (val >= 1) return '100%'
    return (val * 100).toFixed(2) + '%'
}

With page access depth data, you can:

Identify where users lose interest in your content
Optimize content placement (put important elements where users actually look)
Improve long-form content structure with better hierarchy
Detect unusual user behavior patterns that might indicate fraud or bots

User Clicks

Using addEventListener() to monitor mousedown and touchstart events, we can collect information about each click area's size, click coordinates' specific position in the page, clicked element's content, and other information.

Why this matters: Click tracking reveals what elements users interact with most frequently, helping you understand user interests and optimize UI element placement. It also helps identify usability issues where users might be clicking on non-interactive elements expecting a response.

export default function onClick() {
    ['mousedown', 'touchstart'].forEach(eventType => {
        let timer
        window.addEventListener(eventType, event => {
            clearTimeout(timer)
            timer = setTimeout(() => {
                const target = event.target
                const { top, left } = target.getBoundingClientRect()

                lazyReportCache({
                    top,
                    left,
                    eventType,
                    pageHeight: document.documentElement.scrollHeight || document.body.scrollHeight,
                    scrollTop: document.documentElement.scrollTop || document.body.scrollTop,
                    type: 'behavior',
                    subType: 'click',
                    target: target.tagName,
                    paths: event.path?.map(item => item.tagName).filter(Boolean),
                    startTime: event.timeStamp,
                    pageURL: getPageURL(),
                    outerHTML: target.outerHTML,
                    innerHTML: target.innerHTML,
                    width: target.offsetWidth,
                    height: target.offsetHeight,
                    viewport: {
                        width: window.innerWidth,
                        height: window.innerHeight,
                    },
                    uuid: getUUID(),
                })
            }, 500)
        })
    })
}

With this click data, you can:

Create heatmaps showing where users click most frequently
Identify non-functional elements users try to interact with
Optimize button placement and size for better conversion
Detect rage clicks (multiple rapid clicks in the same area) indicating user frustration

Page Navigation

Using addEventListener() to monitor popstate and hashchange page navigation events allows you to track how users navigate through your application.

Why this matters: Navigation tracking helps you understand user flow patterns - how users move between pages, which navigation paths are most common, and where users might be getting lost or trapped in navigation loops. This data is crucial for optimizing site structure and improving user journey flows.

export default function pageChange() {
    let from = ''
    window.addEventListener('popstate', () => {
        const to = getPageURL()

        lazyReportCache({
            from,
            to,
            type: 'behavior',
            subType: 'popstate',
            startTime: performance.now(),
            uuid: getUUID(),
        })

        from = to
    }, true)

    let oldURL = ''
    window.addEventListener('hashchange', event => {
        const newURL = event.newURL

        lazyReportCache({
            from: oldURL,
            to: newURL,
            type: 'behavior',
            subType: 'hashchange',
            startTime: performance.now(),
            uuid: getUUID(),
        })

        oldURL = newURL
    }, true)
}

With navigation data, you can:

Identify common user paths through your application
Detect navigation dead-ends or loops where users get stuck
Optimize navigation menus based on actual usage patterns
Improve information architecture to better match user behavior

Vue Router Changes

For applications built with Vue, you can use the router's hooks to monitor navigation between routes, providing similar insights to general page navigation tracking but specific to Vue's routing system.

Why this matters: In single-page applications, traditional page navigation events don't capture all route changes. Framework-specific router monitoring ensures you don't miss important navigation data in modern web applications.

export default function onVueRouter(router) {
    router.beforeEach((to, from, next) => {
        // Don't count first page load
        if (!from.name) {
            return next()
        }

        const data = {
            params: to.params,
            query: to.query,
        }

        lazyReportCache({
            data,
            name: to.name || to.path,
            type: 'behavior',
            subType: ['vue-router-change', 'pv'],
            startTime: performance.now(),
            from: from.fullPath,
            to: to.fullPath,
            uuid: getUUID(),
        })

        next()
    })
}

This data helps you:

Track the most frequently accessed routes in your Vue application
Understand navigation patterns specific to your application's structure
Identify potential optimization opportunities in your routing setup
Measure the impact of UX improvements on navigation behavior

Data Reporting

Once you've collected performance, error, and behavior data, you need a reliable system to transmit this information to your backend for processing and analysis. Data reporting is the critical bridge between client-side data collection and server-side analytics.

Effective data reporting must balance several concerns:

Reliability - Ensuring data is successfully transmitted, especially critical errors
Performance - Minimizing impact on the user experience and application performance
Timing - Deciding when to send data to avoid interference with user interactions
Bandwidth - Managing the amount of data transmitted to reduce network usage

Let's explore the various methods and strategies for implementing efficient data reporting.

Reporting Methods

Data can be reported using the following methods:

My simple SDK uses a combination of the first and second methods for reporting. Using sendBeacon for reporting has very obvious advantages.

Using the sendBeacon() method will send data to the server asynchronously when the user agent has an opportunity, without delaying page unload or affecting the performance of the next navigation. This solves all the problems with submitting analytics data: data is reliable, transmission is asynchronous, and it won't affect the loading of the next page.

For browsers that don't support sendBeacon, we can use XMLHttpRequest for reporting. An HTTP request consists of sending and receiving two steps. Actually, for reporting, we just need to ensure the data can be sent - we don't need to receive the response. For this reason, I did an experiment where I sent 30kb of data (generally reported data rarely exceeds this size) using XMLHttpRequest in beforeunload, tested with different browsers, and all were able to send successfully. Of course, this also depends on hardware performance and network conditions.

Here's a sample implementation of a reporting function that uses both methods:

function report(data, isImmediate = false) {
    if (!config.reportUrl) {
        console.error('Report URL is not set')
        return
    }

    // Add timestamp and other common properties
    const reportData = {
        ...data,
        timestamp: Date.now(),
        userAgent: navigator.userAgent,
        userId: getUserId(),
        // Add other common properties as needed
    }

    // Choose reporting method based on browser support and timing
    if (isImmediate) {
        sendData(reportData)
    } else {
        // Queue data for batch sending
        reportQueue.push(reportData)

        // Send when queue reaches threshold
        if (reportQueue.length >= config.batchSize) {
            sendBatchData()
        }
    }
}

function sendData(data) {
    // Try sendBeacon first
    if (navigator.sendBeacon) {
        const blob = new Blob([JSON.stringify(data)], { type: 'application/json' })
        const success = navigator.sendBeacon(config.reportUrl, blob)

        if (success) return
    }

    // Fall back to XMLHttpRequest
    const xhr = new XMLHttpRequest()
    xhr.open('POST', config.reportUrl, true)
    xhr.setRequestHeader('Content-Type', 'application/json')
    xhr.send(JSON.stringify(data))
}

function sendBatchData() {
    if (reportQueue.length === 0) return

    const data = [...reportQueue]
    reportQueue.length = 0

    sendData({ type: 'batch', data })
}

Reporting Timing

There are three reporting timings:

Use requestIdleCallback/setTimeout for delayed reporting
Report in the beforeunload callback function
Cache reported data and report when reaching a certain amount

It's recommended to combine all three methods:

First cache the reported data, and when reaching a certain amount, use requestIdleCallback/setTimeout for delayed reporting
Report all unreported data when leaving the page

Here's how you might implement this combined approach:

// Cache for storing reports until they're sent
let reportCache = []
const MAX_CACHE_SIZE = 10
let timer = null

// Report data with requestIdleCallback when browser is idle
function lazyReportCache(data) {
    reportCache.push(data)

    // If cache reaches threshold, schedule sending
    if (reportCache.length >= MAX_CACHE_SIZE) {
        // Use requestIdleCallback if available, otherwise setTimeout
        const scheduleFn = window.requestIdleCallback || setTimeout

        if (timer) {
            cancelScheduledReport()
        }

        timer = scheduleFn(() => {
            // Send cached data in bulk
            const dataToSend = [...reportCache]
            reportCache = []
            report({
                type: 'batch',
                data: dataToSend,
            })
            timer = null
        }, { timeout: 2000 }) // For requestIdleCallback, timeout after 2s
    }
}

function cancelScheduledReport() {
    if (window.requestIdleCallback && timer) {
        window.cancelIdleCallback(timer)
    } else if (timer) {
        clearTimeout(timer)
    }
    timer = null
}

// Report any remaining data when user leaves the page
function setupUnloadReporting() {
    window.addEventListener('beforeunload', () => {
        if (reportCache.length > 0) {
            // Cancel any scheduled reporting
            cancelScheduledReport()

            // Send remaining cached data immediately
            report({
                type: 'batch',
                data: reportCache,
            }, true) // true for immediate sending

            reportCache = []
        }
    })
}

This implementation:

Collects data in a cache until it reaches a threshold
Uses requestIdleCallback (or setTimeout as fallback) to send data when the browser is idle
Ensures any remaining data is sent when the user leaves the page
Batches multiple reports together to reduce network requests

By combining these methods, you create a robust reporting system that minimizes performance impact while ensuring data reliability.

Summary

In this comprehensive guide, we've explored how to build a complete frontend monitoring SDK for collecting and reporting critical application data. Let's recap what we've covered:

Performance Monitoring
- We implemented methods to capture key web vitals like FP, FCP, LCP, and CLS
- We tracked page load events, API request timing, and resource loading metrics
- We measured first screen rendering time and frame rates to ensure smooth user experiences
- We added support for SPA-specific metrics like Vue router change rendering time
Error Monitoring
- We built systems to capture resource loading errors, JavaScript exceptions, and Promise rejections
- We explored how to use sourcemaps to make minified production errors readable
- We integrated with framework-specific error handling for Vue applications
User Behavior Tracking
- We implemented tracking for page views, stay duration, and scroll depth
- We created methods to monitor user clicks and navigation patterns
- We built custom tracking for SPA navigation with Vue Router
Data Reporting
- We developed robust reporting mechanisms using sendBeacon and XMLHttpRequest
- We implemented intelligent reporting timing strategies to minimize performance impact
- We created batching mechanisms to reduce network requests

Building your own monitoring SDK gives you complete control over what data you collect and how you process it. This approach offers several advantages over third-party solutions:

Privacy: You own all the data and can ensure compliance with regulations like GDPR
Performance: You can optimize the SDK specifically for your application's needs
Customization: You can add custom metrics unique to your business requirements
Integration: Your SDK can easily integrate with your existing systems

As you implement your own monitoring solution, remember these best practices:

Respect User Privacy: Only collect what you need and be transparent about it
Minimize Performance Impact: Ensure your monitoring doesn't degrade the user experience
Balance Detail and Volume: More data isn't always better if it overwhelms your analysis
Act on Insights: The ultimate goal is to improve your application based on the data

By following the approaches outlined in this article, you'll be well-equipped to build a comprehensive monitoring system that helps you deliver better user experiences through data-driven decision making.

References

Performance Monitoring

Error Monitoring

Behavior Monitoring

Implementing Synchronous Scrolling in a Dual-Pane Markdown Editor

woai3c — Wed, 05 Feb 2025 16:16:15 +0000

As someone who frequently writes technical articles using markdown, I'm quite particular about the writing experience. I've noticed that most technical community markdown editors include synchronous scrolling functionality. However, while some implement this feature well, others do it poorly. Out of curiosity, I decided to implement this feature myself.

After careful consideration, I came up with three solutions:

Percentage-based scrolling
Simultaneous rendering of large elements in both panes
Row-based index synchronization for precise scroll alignment

Percentage-based Scrolling

Let's say we're scrolling pane a. The scroll percentage is calculated as: scroll position / total content height, expressed in code as a.scrollTop / a.scrollHeight. When scrolling pane a, we need to manually synchronize pane b's scroll position by calculating its height based on pane a's scroll percentage:

a.onscroll = () => {
  b.scrollTo({ top: a.scrollTop / a.scrollHeight * b.scrollHeight })
}

While the principle is simple, the implementation results are not satisfactory.

As shown in the animation above, when we stop at the second heading, the content in both panes is synchronized. However, when scrolling to the third heading, there's already a height difference of nearly 300 pixels between the two panes. This solution is barely usable - better than nothing, but far from ideal.

Simultaneous Rendering of Large Elements

The height inconsistency between the dual panes occurs because markdown elements can have significantly different heights before and after rendering. For example, an image in markdown is just a single line of code, but once rendered, its height can vary from tens to hundreds of pixels. This issue could be resolved by rendering images in both panes simultaneously.

However, images aren't the only elements that show height differences between their markdown and rendered forms. While not as dramatic as images, elements like h1 and h2 headings also have slight differences. As articles get longer, these small differences accumulate, causing increasingly significant height discrepancies between the two panes. Therefore, this solution isn't particularly reliable either.

Row-based Index Synchronization

This third solution performs much better than the previous two, achieving almost perfect line-by-line synchronization. Here's how it works:

First, monitor changes in the markdown content and assign indices to each row element (excluding empty rows and blank text).

When rendering markdown content, we need to add a data-index value to the rendered elements. This allows us to precisely locate corresponding elements between the edit and preview panes.

Second, calculate the scroll position in pane b based on the scroll position of elements with matching indices in pane a.

When pane a is scrolling, we need to iterate through all elements from top to bottom to find the first visible element. By "visible element," we mean elements that are currently in view, as some elements will scroll out of view during scrolling.

To determine if an element is visible:

function isInScreen(dom) {
    const { top, bottom } = dom.getBoundingClientRect()
    return bottom >= 0 && top < window.innerHeight
}

Beyond checking visibility, we also need to calculate what percentage of the element is visible on screen. For example, if half of a markdown image string is visible, then half of the rendered image should also be visible in the preview pane.

The code for calculating the visible percentage of an element:

function percentOfdomInScreen(dom) {
    // We already know the element is on screen through isInScreen(),
    // so we just need to calculate its visible percentage
    const { height, bottom } = dom.getBoundingClientRect()
    if (bottom <= 0) return 0 // Not visible
    if (bottom >= height) return 1 // Fully visible
    return bottom / height // Partially visible
}

Now we can iterate through elements from top to bottom in pane a to find the first visible element:

// scrollContainer is pane a, ShowContainer is pane b
const nodes = Array.from(scrollContainer.children)
for (const node of nodes) {
    // Find the first visible element
    if (isInScreen(node) && percentOfdomInScreen(node) >= 0) {
        const index = node.dataset.index
        // Find the corresponding element in the preview pane
        const dom = ShowContainer.querySelector(`[data-index="${index}"]`)

        // Get the visible percentage in pane a
        const percent = percentOfdomInScreen(node)
        // Calculate the distance from the container top
        const heightToTop = getHeightToTop(dom)
        // Calculate how much of the element should be hidden based on percent
        const domNeedHideHeight = dom.offsetHeight * (1 - percent)
        // Scroll to the correct position
        ShowContainer.scrollTo({ top: heightToTop + domNeedHideHeight })
        break
    }
}

As shown in the animation above, we've achieved precise line-by-line synchronization.

Handling Edge Cases

Some elements become nested when rendered, such as tables, which render as:

<table>
    <tbody>
        <tr>
            <td></td>
        </tr>
    </tbody>
</table>

With the current rendering logic, if we have a table like:

|1|b|
...

The data-index of |1|b| would correspond to the entire table element.

This creates a bug where scrolling the first row to 50% visibility causes the entire table to scroll to 50% in the preview pane, as shown below:

This isn't the desired behavior - when the edit pane hasn't finished scrolling past the first row, the preview pane has already scrolled halfway through the entire table.

The solution is to apply the data-index to the actual content elements. For tables, this means adding data-index to the tr elements instead of the table itself.

This fixes the synchronization issue. The same principle applies to other nested elements like lists (ul, ol).

Summary

The complete code is available on GitHub:

markdown-editor-sync-scroll-demo

Online demos are available at:

If the online demos are loading slowly, you can clone the project and open the HTML files directly.

Make a tiny browser engine from scratch

woai3c — Sun, 26 Jan 2025 16:05:34 +0000

Introduction

Browser rendering principles are essential knowledge for frontend developers and are frequently discussed in interviews and frontend training courses. You can also find related descriptions in MDN documentation.

As a seasoned frontend developer, I understand browser rendering principles, but my knowledge has been limited to theoretical aspects. Therefore, I decided to build a tiny browser engine from scratch.

The rendering engine is a component of the browser that transforms source code (HTML, CSS, JavaScript) into a format that users can read, view, and hear. However, implementing a complete browser engine alone would be too challenging and time-consuming. So, I decided to take a step back and create a tiny browser engine instead. I happened to find an open-source toy rendering engine called Robinson written in Rust on Github, which inspired me to create my own version using JavaScript. I've also published it on Github as tiny-rendering-engine.

This tiny rendering engine consists of five phases:

Parse HTML and generate DOM tree
Parse CSS and generate CSS rule collection
Combine DOM tree and CSS rules to create Style tree
Generate Layout tree
Painting

I've created separate branches on Github for the code of each phase. Since understanding the entire rendering engine's code at once might be challenging, I advise starting with the first branch and progressing step by step, from easy to difficult, for better learning efficiency.

HTML parser - v1 branch
CSS parser - v2 branch
Style tree - v3 branch
Layout tree - v4 branch
Painting - v5 branch

Now, let's look at how to create an HTML parser.

HTML parser

The purpose of the HTML parser is to transform HTML code into a DOM tree. For example:

<div class="lightblue test" id=" div " data-index="1">test!</div>

The above of HTML code will be transforming as a DOM tree:

{
    "tagName": "div",
    "attributes": {
        "class": "lightblue test",
        "id": "div",
        "data-index": "1"
    },
    "children": [
        {
            "nodeValue": "test!",
            "nodeType": 3
        }
    ],
    "nodeType": 1
}

Writing a parser requires some knowledge of compilation principles such as lexical analysis and syntactic analysis. However, our tiny parser is very simple, so it's okay even if you don't understand these principles - you'll understand once you see the code.

Looking back at the HTML code above, the entire parsing process is shown in the following picture.

Each piece of HTML code has its corresponding parsing method.

To simplify the HTML parser, we need to add some restrictions:

HTML tag must be shown with a pair: <div>...</div>
HTML attribute value must be quoted: <div class="test">...</div>
Don't support comments
No need for most error handling
Only support two nodes: Element and Text

With these restrictions, the HTML parser will be simpler.

Node Types

First, we need to design data structure to support different node types:

export enum NodeType {
    Element = 1,
    Text = 3,
}

export interface Element {
    tagName: string
    attributes: Record<string, string>
    children: Node[]
    nodeType: NodeType.Element
}

interface Text {
    nodeValue: string
    nodeType: NodeType.Text
}

export type Node = Element | Text

And then we need two create function:

export function element(tagName: string) {
    return {
        tagName,
        attributes: {},
        children: [],
        nodeType: NodeType.Element,
    } as Element
}

export function text(data: string) {
    return {
        nodeValue: data,
        nodeType: NodeType.Text,
    } as Text
}

These two functions will return corresponding DOM nodes when they are called in parsing Element code or Text code.

HTML Parser Execution Process

The following diagram shows the execution process of the HTML parser:

The entry point of the HTML parser is the parse() method, which traverses and parses all HTML text until the end:

Check if the current character is <. If it is, parse it as an Element node by calling parseElement(); otherwise, call parseText().
parseText() is relatively simple - it traverses forward through the string until encountering the < character. All characters between the current position and the < character become the value of the Text node.
parseElement() is more complex. First, it calls parseTag() to parse and obtain the element's tag name.
Then it enters the parseAttrs() method to check for attribute nodes. If the node has a class or other HTML attributes, it calls parseAttr() to parse these attributes.
At this point, the first half of the element node has been parsed. Next, it needs to parse the element's child nodes. This creates a recursive process, returning to step 1.
After all child nodes are parsed, it calls parseTag() to verify that the ending tag name matches the starting tag name. If they match, parseElement() or parse() completes; otherwise, it throws an error.

Detailed Implementation of HTML Parser Methods

Entry point `parse()`

The entry point of the HTML parser is parse(rawText):

parse(rawText: string) {
    this.rawText = rawText.trim()
    this.len = this.rawText.length
    this.index = 0
    this.stack = []

    const root = element('root')
    while (this.index < this.len) {
        this.removeSpaces()
        if (this.rawText[this.index].startsWith('<')) {
            this.index++
            this.parseElement(root)
        } else {
            this.parseText(root)
        }
    }
}

The parse() method traverses through the entire HTML text. It first checks if the current character is <. If it is, the text is treated as an Element node and parseElement() is called; otherwise, it's treated as a Text node and parseText() is called.

Parse Element Node `parseElement()`

private parseElement(parent: Element) {
    // Parse tag
    const tag = this.parseTag()
    // Generate element node
    const ele = element(tag)

    this.stack.push(tag)

    parent.children.push(ele)
    // Parse attributes
    this.parseAttrs(ele)

    while (this.index < this.len) {
        this.removeSpaces()
        if (this.rawText[this.index].startsWith('<')) {
            this.index++
            this.removeSpaces()
            // Check if it's an end tag
            if (this.rawText[this.index].startsWith('/')) {
                this.index++
                const startTag = this.stack[this.stack.length - 1]
                // End tag
                const endTag = this.parseTag()
                if (startTag !== endTag) {
                    throw Error(`The end tagName ${endTag} does not match start tagName ${startTag}`)
                }

                this.stack.pop()
                while (this.index < this.len && this.rawText[this.index] !== '>') {
                    this.index++
                }

                break
            } else {
                this.parseElement(ele)
            }
        } else {
            this.parseText(ele)
        }
    }

    this.index++
}

parseElement() first calls parseTag() and parseAttrs() to parse the tag name and attributes, then recursively parses child nodes until all HTML text has been processed.

Parse Text Node `parseText()`

private parseText(parent: Element) {
    let str = ''
    while (
        this.index < this.len
        && !(this.rawText[this.index] === '<' && /\w|\//.test(this.rawText[this.index + 1]))
    ) {
        str += this.rawText[this.index]
        this.index++
    }

    this.sliceText()
    parent.children.push(text(removeExtraSpaces(str)))
}

Parsing text nodes is relatively simpler. The method continues to traverse forward until it encounters the < character. For example, when processing the HTML text <div>test!</div>, parseText() extracts the value test!.

Parse Tag `parseTag()`

After entering parseElement(), the first call is to parseTag(), which parses the tag name:

private parseTag() {
    let tag = ''

    this.removeSpaces()

    // get tag name
    while (this.index < this.len && this.rawText[this.index] !== ' ' && this.rawText[this.index] !== '>') {
        tag += this.rawText[this.index]
        this.index++
    }

    this.sliceText()
    return tag
}

For example, when processing the HTML text <div>test!</div>, parseTag() extracts the tag name div.

Parse Attribute Nodes `parseAttrs()`

After parsing the tag name, the next step is to parse attribute nodes:

private parseAttrs(ele: Element) {
    // Continue traversing until encountering '>', indicating the end of the <div ....> segment
    while (this.index < this.len && this.rawText[this.index] !== '>') {
        this.removeSpaces()
        this.parseAttr(ele)
        this.removeSpaces()
    }

    this.index++
}

// parse a single attribute, such as class="foo bar"
private parseAttr(ele: Element) {
    let attr = ''
    let value = ''
    while (this.index < this.len && this.rawText[this.index] !== '=' && this.rawText[this.index] !== '>') {
        attr += this.rawText[this.index++]
    }

    this.sliceText()
    attr = attr.trim()
    if (!attr.trim()) return

    this.index++
    let startSymbol = ''
    if (this.rawText[this.index] === "'" || this.rawText[this.index] === '"') {
        startSymbol = this.rawText[this.index++]
    }

    while (this.index < this.len && this.rawText[this.index] !== startSymbol) {
        value += this.rawText[this.index++]
    }

    this.index++
    ele.attributes[attr] = value.trim()
    this.sliceText()
}

parseAttr() can parse HTML text such as class="test" into an object { class: "test" }.

Helper Methods

Sometimes there are many unnecessary spaces between different nodes and attributes, so we need a method to remove them:

protected removeSpaces() {
    while (this.index < this.len && (this.rawText[this.index] === ' ' || this.rawText[this.index] === '\n')) {
        this.index++
    }

    this.sliceText()
}

For debugging purposes, developers need to check the current character being processed. If all previously processed characters remain in the text, debugging becomes more difficult as developers need to manually find the current character based on the index value. Therefore, we need to remove all processed characters to ensure only unprocessed text remains:

protected sliceText() {
    this.rawText = this.rawText.slice(this.index)
    this.len = this.rawText.length
    this.index = 0
}

The sliceText() method removes all processed characters. For example, when parsing the tag name div:

After parsing, we need to remove the processed text, as shown in the following diagram:

Brief summary

In conclusion, we have covered the complete logic of the HTML parser. The entire implementation consists of approximately 200 lines of code, or around 100 lines excluding TypeScript type declarations.

CSS Parser

A CSS stylesheet is a collection of CSS rules, and the purpose of CSS parser is to transform CSS text into a CSS rule collection.

div, p {
    font-size: 88px;
    color: #000;
}

For example, the CSS parser will transform the above CSS text into the following CSS rule collection:

[
    {
        "selectors": [
            {
                "id": "",
                "class": "",
                "tagName": "div"
            },
            {
                "id": "",
                "class": "",
                "tagName": "p"
            }
        ],
        "declarations": [
            {
                "name": "font-size",
                "value": "88px"
            },
            {
                "name": "color",
                "value": "#000"
            }
        ]
    }
]

Each rule has a selectors and declarations attribute, where selectors indicates CSS selectors, and declarations indicates a collection of CSS property declarations.

export interface Rule {
    selectors: Selector[]
    declarations: Declaration[]
}

export interface Selector {
    tagName: string
    id: string
    class: string
}

export interface Declaration {
    name: string
    value: string | number
}

Each CSS rule can contain multiple selectors and CSS properties.

Parse CSS Rule `parseRule()`

private parseRule() {
    const rule: Rule = {
        selectors: [],
        declarations: [],
    }

    rule.selectors = this.parseSelectors()
    rule.declarations = this.parseDeclarations()

    return rule
}

In parseRule(), it calls parseSelectors() to parse CSS selectors, and then calls parseDeclarations() to parse CSS properties from the remaining CSS text.

Parse Selector `parseSelector()`

private parseSelector() {
    const selector: Selector = {
        id: '',
        class: '',
        tagName: '',
    }

    switch (this.rawText[this.index]) {
        case '.':
            this.index++
            selector.class = this.parseIdentifier()
            break
        case '#':
            this.index++
            selector.id = this.parseIdentifier()
            break
        case '*':
            this.index++
            selector.tagName = '*'
            break
        default:
            selector.tagName = this.parseIdentifier()
    }

    return selector
}

private parseIdentifier() {
    let result = ''
    while (this.index < this.len && this.identifierRE.test(this.rawText[this.index])) {
        result += this.rawText[this.index++]
    }

    this.sliceText()
    return result
}

We only support tag names, ID selectors with the # prefix, class selectors with the . prefix, or combinations of these. If the tag name is *, it represents a universal selector that can match any tag.

The standard CSS parser will skip unrecognized parts and continue parsing the remaining CSS text. This behavior ensures compatibility with older browsers and prevents program interruption due to errors. Our CSS parser is simpler and doesn't include such error handling.

Parse CSS Properties `parseDeclaration()`

private parseDeclaration() {
    const declaration: Declaration = { name: '', value: '' }
    this.removeSpaces()
    declaration.name = this.parseIdentifier()
    this.removeSpaces()

    while (this.index < this.len && this.rawText[this.index] !== ':') {
        this.index++
    }

    this.index++ // clear :
    this.removeSpaces()
    declaration.value = this.parseValue()
    this.removeSpaces()

    return declaration
}

parseDeclaration() will parse CSS text such as color: red; into an object { name: "color", value: "red" }.

Brief Summary

The CSS parser is relatively simpler since most concepts have been covered in the HTML parser section. The entire CSS parser's code is approximately 100 lines, and if you have read the HTML parser's code, you should find the CSS parser's code easier to understand.

Build Style Tree

The purpose of this phase is to write a style tree builder that takes a DOM tree and a collection of CSS rules as input and generates a style tree.

Each node in the style tree contains CSS property values and a reference to its corresponding DOM node:

interface AnyObject {
    [key: string]: any
}

export interface StyleNode {
    node: Node // DOM node
    values: AnyObject // style property values
    children: StyleNode[] // style tree children
}

Let's look at a simple example:

<div>test</div>

div {
    font-size: 88px;
    color: #000;
}

The above HTML and CSS will be transformed by the style builder into a style tree:

{
    "node": { // DOM node
        "tagName": "div",
        "attributes": {},
        "children": [
            {
                "nodeValue": "test",
                "nodeType": 3
            }
        ],
        "nodeType": 1
    },
    "values": { // CSS property values
        "font-size": "88px",
        "color": "#000"
    },
    "children": [ // style tree children
        {
            "node": {
                "nodeValue": "test",
                "nodeType": 3
            },
            "values": { // text node inherits parent's styles
                "font-size": "88px",
                "color": "#000"
            },
            "children": []
        }
    ]
}

Traverse DOM Tree

Now we need to traverse the DOM tree and check if each node matches any CSS rules.

export function getStyleTree(eles: Node | Node[], cssRules: Rule[], parent?: StyleNode) {
    if (Array.isArray(eles)) {
        return eles.map((ele) => getStyleNode(ele, cssRules, parent))
    }

    return getStyleNode(eles, cssRules, parent)
}

Match Selector

The selector matching is easier to implement since our CSS parser only supports simple selectors. We just need to check if the element itself matches the selector.

/**
 * Check if CSS selector matches the element
 */
function isMatch(ele: Element, selectors: Selector[]) {
    return selectors.some((selector) => {
        // Universal selector
        if (selector.tagName === '*') return true
        if (selector.tagName === ele.tagName) return true
        if (ele.attributes.id === selector.id) return true

        if (ele.attributes.class) {
            const classes = ele.attributes.class.split(' ').filter(Boolean)
            const classes2 = selector.class.split(' ').filter(Boolean)
            for (const name of classes) {
                if (classes2.includes(name)) return true
            }
        }

        return false
    })
}

Once we find the matching DOM node, we need to combine the DOM node with its matching CSS properties to output a style tree node:

function getStyleNode(ele: Node, cssRules: Rule[], parent?: StyleNode) {
    const styleNode: StyleNode = {
        node: ele,
        values: getStyleValues(ele, cssRules, parent),
        children: [],
    }

    if (ele.nodeType === NodeType.Element) {
        // Merge inline styles
        if (ele.attributes.style) {
            styleNode.values = { ...styleNode.values, ...getInlineStyle(ele.attributes.style) }
        }

        styleNode.children = ele.children.map((e) => getStyleNode(e, cssRules, styleNode)) as unknown as StyleNode[]
    }

    return styleNode
}

function getStyleValues(ele: Node, cssRules: Rule[], parent?: StyleNode) {
    const inheritableAttrValue = getInheritableAttrValues(parent)

    // Text nodes inherit inheritable properties from parent
    if (ele.nodeType === NodeType.Text) return inheritableAttrValue

    return cssRules.reduce((result: AnyObject, rule) => {
        if (isMatch(ele as Element, rule.selectors)) {
            result = { ...result, ...cssValueArrToObject(rule.declarations) }
        }

        return result
    }, inheritableAttrValue)
}

In CSS selectors, different selectors have different priorities. For example, ID selector's priority is higher than class selectors. However, for simplicity, we haven't implemented selector priorities - all selectors have the same priority.

Inherit Property

Text nodes can't match any selector, so where do their styles come from? The answer is inheritance - text nodes inherit styles from their parent nodes.

There are many inheritable properties in CSS. Even when child nodes haven't declared certain properties, they can still inherit them from their parents. For example, font color, font family and so on are all inheritable. For simplicity, we only support inheriting the color and font-size properties from parent nodes.

// Inheritable properties for child elements, only two listed here but there are many more
const inheritableAttrs = ['color', 'font-size']

/**
 * Get inheritable property values from parent element
 */
function getInheritableAttrValues(parent?: StyleNode) {
    if (!parent) return {}
    const keys = Object.keys(parent.values)
    return keys.reduce((result: AnyObject, key) => {
        if (inheritableAttrs.includes(key)) {
            result[key] = parent.values[key]
        }

        return result
    }, {})
}

Inline Style

In CSS, inline styles have the highest priority except for !important.

<span style="color: red; background: yellow;">

We first call getStyleValues() to get the current DOM node's CSS property values, and then get the node's inline styles. The inline styles will override the current node's styles.

Layout Tree

The fourth phase, transforming a style tree into a layout tree, is one of the more complex parts of the entire rendering engine.

CSS Box Model

In CSS, every DOM node can be represented as a box. The box model consists of content, padding, border, margin, and information about the node's position on the page.

We can represent the box model using the following data structures:

export default class Dimensions {
    content: Rect
    padding: EdgeSizes
    border: EdgeSizes
    margin: EdgeSizes
}

export default class Rect {
    x: number
    y: number
    width: number
    height: number
}

export interface EdgeSizes {
    top: number
    right: number
    bottom: number
    left: number
}

Block Layout and Inline Layout

The CSS display property determines how a box model is laid out. While the display property can have many values such as block, inline, flex, and others, we will only support block and inline layouts in our implementation. By default, all box models have display: inline.

Let's look at the differences between these layouts using HTML code:

<container>
  <a></a>
  <b></b>
  <c></c>
  <d></d>
</container>

With block layout, elements are stacked vertically (top to bottom):

With inline layout, elements are arranged horizontally (left to right):

When a container has both block and inline elements, we wrap the inline elements in an anonymous block container:

This allows us to properly handle both inline and block elements within the same container.

Generally, page content grows vertically. When child nodes are added to a container, they increase the container's height rather than its width. In other words, child nodes typically expand to fill their container's width, while the container's height expands to accommodate its child nodes.

Layout Tree

The layout tree is a collection of box models.

export default class LayoutBox {
    dimensions: Dimensions
    boxType: BoxType
    children: LayoutBox[]
    styleNode: StyleNode
}

Each box model can be of type block, inline, or anonymous:

export enum BoxType {
    BlockNode = 'BlockNode',
    InlineNode = 'InlineNode',
    AnonymousBlock = 'AnonymousBlock',
}

We generate box models according to each DOM node's display property when building the style tree.

When a block node contains an inline child node, we need to create an anonymous node (which is actually a block node) to wrap the child node. If there are multiple inline child nodes in a row, they all need to be placed in the same anonymous node.

function buildLayoutTree(styleNode: StyleNode) {
    if (getDisplayValue(styleNode) === Display.None) {
        throw new Error('Root node has display: none.')
    }

    const layoutBox = new LayoutBox(styleNode)

    let anonymousBlock: LayoutBox | undefined
    for (const child of styleNode.children) {
        const childDisplay = getDisplayValue(child)
        // Skip if DOM node has display: none
        if (childDisplay === Display.None) continue

        if (childDisplay === Display.Block) {
            anonymousBlock = undefined
            layoutBox.children.push(buildLayoutTree(child))
        } else {
            // Create an anonymous container for inline nodes
            if (!anonymousBlock) {
                anonymousBlock = new LayoutBox()
                layoutBox.children.push(anonymousBlock)
            }

            anonymousBlock.children.push(buildLayoutTree(child))
        }
    }

    return layoutBox
}

Traverse Layout Tree

To start building the layout tree, we use the entry point function getLayoutTree():

export function getLayoutTree(styleNode: StyleNode, parentBlock: Dimensions) {
    parentBlock.content.height = 0
    const root = buildLayoutTree(styleNode)
    root.layout(parentBlock)
    return root
}

The entry point traverses the style tree, combines the relevant information from style tree nodes to generate a LayoutBox object, and then calls the layout() method. This method calculates the position and dimension information for each box model.

As mentioned at the beginning of the chapter, a box model's width depends on its parent, while its height depends on its child nodes. This means our code needs to traverse the tree top-down when calculating widths (so we can set child node widths after knowing their parent's width), and then bottom-up when calculating heights (so we can calculate parent heights after knowing their children's dimensions).

layout(parentBlock: Dimensions) {
    // Calculate current node's width before traversing children
    // since child width depends on parent width
    this.calculateBlockWidth(parentBlock)
    // Calculate box node position
    this.calculateBlockPosition(parentBlock)
    // Traverse children and calculate their positions and dimensions
    this.layoutBlockChildren()
    // Calculate current node's height after children
    // since parent height depends on children's height
    this.calculateBlockHeight()
}

This method performs one complete traversal of the layout tree - top-down for width calculations and bottom-up for height calculations. A production-grade layout engine might perform multiple tree traversals, alternating between top-down and bottom-up passes as needed.

Calculating Width

Now, let's first calculate the box model's width. This part is complex, so we need to explain it in detail.

First, we need to get the current node's width, padding, border, and margin information:

calculateBlockWidth(parentBlock: Dimensions) {
    // Initial values
    const styleValues = this.styleNode?.values || {}

    // Default value is auto
    let width = styleValues.width ?? 'auto'
    let marginLeft = styleValues['margin-left'] || styleValues.margin || 0
    let marginRight = styleValues['margin-right'] || styleValues.margin || 0

    let borderLeft = styleValues['border-left'] || styleValues.border || 0
    let borderRight = styleValues['border-right'] || styleValues.border || 0

    let paddingLeft = styleValues['padding-left'] || styleValues.padding || 0
    let paddingRight = styleValues['padding-right'] || styleValues.padding || 0

    // Get parent node's width, if any property is 'auto', set it to 0
    let totalWidth = sum(width, marginLeft, marginRight, borderLeft, borderRight, paddingLeft, paddingRight)
    // ...
}

If these CSS property values haven't been set, they will default to 0. We also need to compare if the current node's total width is equal to the parent node's width. If the width or margin property is set to auto, then we can adjust these properties to fit the available space. So now we need to check the current node's width.

const isWidthAuto = width === 'auto'
const isMarginLeftAuto = marginLeft === 'auto'
const isMarginRightAuto = marginRight === 'auto'

// If current block width exceeds parent width, set its expandable margins to 0
if (!isWidthAuto && totalWidth > parentWidth) {
    if (isMarginLeftAuto) {
        marginLeft = 0
    }

    if (isMarginRightAuto) {
        marginRight = 0
    }
}

// Adjust current element's width based on the difference between parent and child element widths
const underflow = parentWidth - totalWidth

// If all three values are set, fill the difference into marginRight
if (!isWidthAuto && !isMarginLeftAuto && !isMarginRightAuto) {
    marginRight += underflow
} else if (!isWidthAuto && !isMarginLeftAuto && isMarginRightAuto) {
    // If right margin is auto, set marginRight to the difference value
    marginRight = underflow
} else if (!isWidthAuto && isMarginLeftAuto && !isMarginRightAuto) {
    // If left margin is auto, set marginLeft to the difference value
    marginLeft = underflow
} else if (isWidthAuto) {
    // If only width is auto, set the other two values to 0
    if (isMarginLeftAuto) {
        marginLeft = 0
    }

    if (isMarginRightAuto) {
        marginRight = 0
    }

    if (underflow >= 0) {
        // Expand width to fill remaining space, original width was auto, calculated as 0
        width = underflow
    } else {
        // Width cannot be negative, so adjust marginRight instead
        width = 0
        marginRight += underflow
    }
} else if (!isWidthAuto && isMarginLeftAuto && isMarginRightAuto) {
    // If only marginLeft and marginRight are auto, set both to half of underflow
    marginLeft = underflow / 2
    marginRight = underflow / 2
}

The above code has shown the calculation details, and important parts have been commented.

By comparing the current node's width with the parent's width, we can get a difference value:

// Adjust current element's width based on the difference between parent and child element widths
const underflow = parentWidth - totalWidth

If the difference value is greater than 0, it indicates that the child nodes' width is less than the parent's width. If the difference value is less than 0, it indicates that the child nodes' width is greater than the parent's width. The above code logic uses these property values (underflow, width, padding, margin) to adjust child nodes' width and margin so they can fit within the parent's width.

Position

Calculating the current node's position information is relatively simpler. The method calculateBlockPosition() will locate the current node by calculating the margin, border, padding information of the current node along with the parent node's position information:

calculateBlockPosition(parentBlock: Dimensions) {
    const styleValues = this.styleNode?.values || {}
    const { x, y, height } = parentBlock.content
    const dimensions = this.dimensions

    dimensions.margin.top = transformValueSafe(styleValues['margin-top'] || styleValues.margin || 0)
    dimensions.margin.bottom = transformValueSafe(styleValues['margin-bottom'] || styleValues.margin || 0)

    dimensions.border.top = transformValueSafe(styleValues['border-top'] || styleValues.border || 0)
    dimensions.border.bottom = transformValueSafe(styleValues['border-bottom'] || styleValues.border || 0)

    dimensions.padding.top = transformValueSafe(styleValues['padding-top'] || styleValues.padding || 0)
    dimensions.padding.bottom = transformValueSafe(styleValues['padding-bottom'] || styleValues.padding || 0)

    dimensions.content.x = x + dimensions.margin.left + dimensions.border.left + dimensions.padding.left
    dimensions.content.y = y + height + dimensions.margin.top + dimensions.border.top + dimensions.padding.top
}

function transformValueSafe(val: number | string) {
    if (val === 'auto') return 0
    return parseInt(String(val))
}

For example, the following code shows how to calculate the x coordinate of the current node's content area:

dimensions.content.x = x + dimensions.margin.left + dimensions.border.left + dimensions.padding.left

Traverse Child Nodes

We must traverse child nodes before calculating the parent's height, because the parent's height depends on its child nodes' height.

layoutBlockChildren() {
    const { dimensions } = this
    for (const child of this.children) {
        child.layout(dimensions)
        // Calculate parent node's height after traversing child nodes
        dimensions.content.height += child.dimensions.marginBox().height
    }
}

Each node's height is the difference value of its top margin and bottom margin, so we can call marginBox() to get the height:

export default class Dimensions {
    content: Rect
    padding: EdgeSizes
    border: EdgeSizes
    margin: EdgeSizes

    constructor() {
        const initValue = {
            top: 0,
            right: 0,
            bottom: 0,
            left: 0,
        }

        this.content = new Rect()

        this.padding = { ...initValue }
        this.border = { ...initValue }
        this.margin = { ...initValue }
    }

    paddingBox() {
        return this.content.expandedBy(this.padding)
    }

    borderBox() {
        return this.paddingBox().expandedBy(this.border)
    }

    marginBox() {
        return this.borderBox().expandedBy(this.margin)
    }
}

export default class Rect {
    x: number
    y: number
    width: number
    height: number

    constructor() {
        this.x = 0
        this.y = 0
        this.width = 0
        this.height = 0
    }

    expandedBy(edge: EdgeSizes) {
        const rect = new Rect()
        rect.x = this.x - edge.left
        rect.y = this.y - edge.top
        rect.width = this.width + edge.left + edge.right
        rect.height = this.height + edge.top + edge.bottom

        return rect
    }
}

After traversing through child nodes and performing relative methods, we have got all child nodes' height, and then get the parent's height (the sum of child nodes' height).

Height Property

By default, a node's height is equal to its content's height. But if we have set the height property value manually, we need to set the node's height to the specified value:

calculateBlockHeight() {
    // If element has height property set, use that height; otherwise use height calculated by layoutBlockChildren()
    const height = this.styleNode?.values.height
    if (height) {
        this.dimensions.content.height = parseInt(height)
    }
}

For more simplicity, we don't need to implement collapsing margins.

Brief Summary

The layout tree is the most complex part of the rendering engine. After this phase, we understand each node's position and dimensional information in the layout tree. In the next phase, we need to study how to paint the layout tree onto the browser page.

Paint

The purpose of this phase is painting each node on the page according to the information of the layout tree. The most computers are using raster(bitmap) technology so far. The process of paint each node to page is called rasterization.

Browsers usually use various graphics APIs and libraries (such as Skia, Cairo, Direct2D and others) to implement rasterization. These apis provide a lot of features such as paint Polygons, lines, curves, gradients and text.

Actually, painting is the most complex part, but by using the canvas library, we don't need to implement rasterization ourselves, which simplifies the painting implementation. Before start to the paint phase, we first study some basic knowledge of how to paint image and text, it help us to understand what the implementation process of rasterization.

How Computer Paint Image And Text

Painting pixel is belong to the low operation of computer, it depends on the detail of screen and gpu api. For simplicity, we can use a section of memory to indicates the screen, the each bit of memory indicates a pixel of screen. For example, if painting a pixel on the (x,y) of the screen, we can use memory[x + y * rowSize] = 1 to indicate. Starting from top-left of the screen, the column calculation is left to right, the row calculation is top to bottom. So the coordinate of the top left corner is (0,0).

For simplicity, we use one bit to indicates a pixel of screen, 0 is represent white, 1 is represent black. The each row length of screen is represented with rowSize, the each column height of screen is represented with colSize.

Painting Line

If we need to paint a line, we just need to know the start point (x1,y1) and the end point (x2,y2).

And then set the area memory values from (x1,y1) to (x2,y2) as 1 according to memory[x + y * rowSize] = 1 formula, then we have drawed a line.

Painting Character

For paint text on the screen, we first divide the screen to several area according to the logic character, each area can output a single completely character. Assume that we have a screen with 256 rows and 512 column, if we assign each character with a 11*8 pixel's grid, then the screen can show 23 rows, each row contains 64 characters(it also have 3 pixels not to used).

According to the above precondition, now we plan to draw a A:

The picture of A is represented by a 11*8 pixels grid. For show it in the memory, we can use a two-dimensional array to indicate:

const charA = [
    [0, 0, 1, 1, 0, 0, 0, 0], // 按从左至右的顺序来读取 bit，转换成十进制数字就是 12
    [0, 1, 1, 1, 1, 0, 0, 0], // 30
    [1, 1, 0, 0, 1, 1, 0, 0], // 51
    [1, 1, 0, 0, 1, 1, 0, 0], // 51
    [1, 1, 1, 1, 1, 1, 0, 0], // 63
    [1, 1, 0, 0, 1, 1, 0, 0], // 51
    [1, 1, 0, 0, 1, 1, 0, 0], // 51
    [1, 1, 0, 0, 1, 1, 0, 0], // 51
    [1, 1, 0, 0, 1, 1, 0, 0], // 51
    [0, 0, 0, 0, 0, 0, 0, 0], // 0
    [0, 0, 0, 0, 0, 0, 0, 0], // 0
]

The first item of the two-dimensional array indicates each bit's value of the first row in the memory. There are a total of 11 rows to draw a A.

Painting Layout Tree

After the basic knowledge of paint screen of popular science, now we start to painting layout tree(for convenience, we using node-canvas library).

First, we need to traverse the entire layout tree, and then paint they one by one:

function renderLayoutBox(layoutBox: LayoutBox, ctx: CanvasRenderingContext2D, parent?: LayoutBox) {
    renderBackground(layoutBox, ctx)
    renderBorder(layoutBox, ctx)
    renderText(layoutBox, ctx, parent)
    for (const child of layoutBox.children) {
        renderLayoutBox(child, ctx, layoutBox)
    }
}

The function will traverse each node and then paint background, border, text in turn, and then paint all child nodes recursively.

By default, we will paint HTML elements according to their order in the layout tree. If two elements overlap, we need to paint the next element on the previous element. The sort way also represented in the layout tree, it will paint a element according to its order in the layout tree.

Painting Background Color

function renderBackground(layoutBox: LayoutBox, ctx: CanvasRenderingContext2D) {
    const { width, height, x, y } = layoutBox.dimensions.borderBox()
    ctx.fillStyle = getStyleValue(layoutBox, 'background')
    ctx.fillRect(x, y, width, height)
}

First, we need to get the position and dimension information of the layout node, starting from x,y, paint the rectangle area. And fill the rectangle according to the value of the CSS property background.

Painting Border

function renderBorder(layoutBox: LayoutBox, ctx: CanvasRenderingContext2D) {
    const { width, height, x, y } = layoutBox.dimensions.borderBox()
    const { left, top, right, bottom } = layoutBox.dimensions.border
    const borderColor = getStyleValue(layoutBox, 'border-color')
    if (!borderColor) return

    ctx.fillStyle = borderColor

    // left
    ctx.fillRect(x, y, left, height)
    // top
    ctx.fillRect(x, y, width, top)
    // right
    ctx.fillRect(x + width - right, y, right, height)
    // bottom
    ctx.fillRect(x, y + height - bottom, width, bottom)
}

Actually, Painting border is painting four rectangles, each rectangle is a border.

Painting Text

function renderText(layoutBox: LayoutBox, ctx: CanvasRenderingContext2D, parent?: LayoutBox) {
    if (layoutBox.styleNode?.node.nodeType === NodeType.Text) {
        // get AnonymousBlock x y
        const { x = 0, y = 0, width } = parent?.dimensions.content || {}
        const styles = layoutBox.styleNode?.values || {}
        const fontSize = styles['font-size'] || '14px'
        const fontFamily = styles['font-family'] || 'serif'
        const fontWeight = styles['font-weight'] || 'normal'
        const fontStyle = styles['font-style'] || 'normal'

        ctx.fillStyle = styles.color
        ctx.font = `${fontStyle} ${fontWeight} ${fontSize} ${fontFamily}`
        ctx.fillText(layoutBox.styleNode?.node.nodeValue, x, y + parseInt(fontSize), width)
    }
}

By the fillText() method of canvas, we can very convenient to paint text with different font style, size, color.

Outputting Image

After painting completely, we can output images with the help of the canvas apis. Let's show it with the following example:

<html>
    <body id=" body " data-index="1" style="color: red; background: yellow;">
        <div>
            <div class="lightblue test">test1!</div>
            <div class="lightblue test">
                <div class="foo">foo</div>
            </div>
        </div>
    </body>
</html>

* {
    display: block;
}

div {
    font-size: 14px;
    width: 400px;
    background: #fff;
    margin-bottom: 20px;
    display: block;
    background: lightblue;
}

.lightblue {
    font-size: 16px;
    display: block;
    width: 200px;
    height: 200px;
    background: blue;
    border-color: green;
    border: 10px;
}

.foo {
    width: 100px;
    height: 100px;
    background: red;
    color: yellow;
    margin-left: 50px;
}

body {
    display: block;
    font-size: 88px;
    color: #000;
}

The above HTML, CSS codes will output a image by parse with a rendering engine:

Summary

So far, we have completed our tiny rendering engine. While it may not be practical for real use, implementing it helps us understand how real rendering engines work, making it valuable from a learning perspective.

Reference Material

How to Load Remote Components in Vue 3

woai3c — Tue, 14 Jan 2025 14:33:11 +0000

Background

I recently received a requirement in a Vue 3 low-code project to load remote components. These remote components have unpredictable names and are stored in a database. I need to fetch all component data through an API to determine what components are available. After research, I found two viable solutions to meet this requirement.

HTML File + UMD Components

This is the simplest solution to implement. We just need to package the component in UMD format and use it directly in the HTML file.

<div id="app">
    <test-input></test-input>
</div>
<script src="https://unpkg.com/vue@3/dist/vue.global.js"></script>
<script>
    // Load the component by mounting the script tag and access it through the window object
    await loadScript('http://localhost/component/input/0.1.0/bundle.js')
    app.component('TestInput', window.TestInput)
</script>

However, this solution is not suitable for large projects due to its low efficiency.

Vue 3 Project + ESM/UMD Components

This is the solution I implemented in my low-code project. During my research, I encountered and solved two main problems. Here's how it works:

Problem 1: Relative References

Since our project doesn't need to be compatible with IE, we can package the source code in ESM format. For example:

import { reactive } from 'vue'
// other code...

then use in project:

const { default: TestInput } = await import('http://localhost/component/input/0.1.0/bundle.mjs')

When loading the remote TestInput component as shown above, it causes a "Relative references must start with either '/', './', or '../'" error. This is because browsers don't support directly using import { reactive } from 'vue' - we need to change 'vue' to https://..../vue.js or './vue.js'. Usually, we don't need to worry about this as our build tools handle it automatically.

Problem 2: Different Vue 3 Contexts

My first attempt to solve the first problem was to package the component with all its dependencies. While this removed all import statements, it unfortunately didn't work. This is because the Vue 3 context in our project and the Vue 3 context from node_modules are incompatible - they need to share the same context to work properly.

Even though all Vue 3 method names are the same across different contexts, their variables are not. This prevents remote components from loading normally.

Solution

To solve these problems:

We can replace import { reactive } from 'vue' with const { reactive } = Vue to avoid the relative references error.
We can import the entire Vue 3 instance in main.js instead of packaging it with the source code. This ensures our project and remote components use the same Vue context.

To handle the code transformation, I created a rollup plugin called rollup-plugin-import-to-const (supporting both vite and rollup). It automatically transforms code from import { reactive } from 'vue' to const { reactive } = Vue. With these solutions in place, we can load remote components in our project:

const { default: TestInput } = await import('http://localhost/component/input/0.1.0/bundle.mjs')

Actually, we can load components in any format (ESM/UMD/CJS, etc.) as long as we solve these two problems.

Summary

Loading remote components isn't limited to these two solutions. For example, we can also use vue3-sfc-loader or webpack5 Module Federation. The choice depends on your project's specific requirements.

Generally, loading remote components is most commonly used in low-code platforms.

How to write unit tests and E2E tests for NestJS applications

woai3c — Sun, 12 Jan 2025 15:35:37 +0000

Introduction

Recently, I have been writing unit tests and E2E tests for a NestJS project. This is my first time writing tests for a backend project, and I found the process different from my experience with frontend testing, making it challenging to begin. After looking at some examples, I have gained a clearer understanding of how to approach testing, so I plan to write an article to record and share my learning to help others who may be facing similar confusion.

In addition, I have put together a demo project with the relevant unit and E2E tests completed, which may be of interest. The code has been uploaded to Github: https://github.com/woai3c/nestjs-demo.

Difference Between Unit Testing and E2E Testing
Prerequisites
Writing Unit Tests
The First Test Case
The Second Test Case
Unit Test Coverage
Writing E2E Tests
Whether to Write Tests
Enhancing System Robustness
Enhancing Maintainability
Enhancing Development Efficiency
When Not to Write Tests?
Conclusion
Reference Materials

Prerequisites

Before diving into this tutorial, you should have:

Basic knowledge of TypeScript and Node.js
Familiarity with NestJS framework fundamentals
Understanding of RESTful APIs
MongoDB installed (as the example uses MongoDB)
Node.js and npm/yarn installed on your system
Basic understanding of testing concepts

The complete code examples can be found in the demo repository. You can clone it to follow along with the examples.

Difference Between Unit Testing and E2E Testing

Unit tests and E2E tests are methods of software testing, but they have different goals and scopes.

Unit testing involves checking and verifying the smallest testable unit within the software. A function or a method, for example, can be considered a unit. In unit testing, you provide expected outputs for various inputs of a function and validate the correctness of its operation. The goal of unit testing is to quickly identify bugs within the function, and they are easy to write and execute rapidly.

On the other hand, E2E tests often simulate real-world user scenarios to test the entire application. For instance, the frontend typically uses a browser or headless browser for testing, while the backend does so by simulating API calls.

Within a NestJS project, unit tests might assess a specific service or a method of a controller, such as verifying if the update method in the Users module correctly updates a user. An E2E test, however, may examine a complete user journey, from creating a new user to updating their password and eventually deleting the user, which involves multiple services and controllers.

Writing Unit Tests

Writing unit tests for a utility function or method that doesn't involve interfaces is relatively straightforward. You only need to consider the various inputs and write the corresponding test code. However, the situation becomes more complex once interfaces come into play. Let's use code as an example:

async validateUser(
  username: string,
  password: string,
): Promise<UserAccountDto> {
  const entity = await this.usersService.findOne({ username });
  if (!entity) {
    throw new UnauthorizedException('User not found');
  }
  if (entity.lockUntil && entity.lockUntil > Date.now()) {
    const diffInSeconds = Math.round((entity.lockUntil - Date.now()) / 1000);
    let message = `The account is locked. Please try again in ${diffInSeconds} seconds.`;
    if (diffInSeconds > 60) {
      const diffInMinutes = Math.round(diffInSeconds / 60);
      message = `The account is locked. Please try again in ${diffInMinutes} minutes.`;
    }
    throw new UnauthorizedException(message);
  }
  const passwordMatch = bcrypt.compareSync(password, entity.password);
  if (!passwordMatch) {
    // $inc update to increase failedLoginAttempts
    const update = {
      $inc: { failedLoginAttempts: 1 },
    };
    // lock account when the third try is failed
    if (entity.failedLoginAttempts + 1 >= 3) {
      // $set update to lock the account for 5 minutes
      update['$set'] = { lockUntil: Date.now() + 5 * 60 * 1000 };
    }
    await this.usersService.update(entity._id, update);
    throw new UnauthorizedException('Invalid password');
  }
  // if validation is sucessful, then reset failedLoginAttempts and lockUntil
  if (
    entity.failedLoginAttempts > 0 ||
    (entity.lockUntil && entity.lockUntil > Date.now())
  ) {
    await this.usersService.update(entity._id, {
      $set: { failedLoginAttempts: 0, lockUntil: null },
    });
  }
  return { userId: entity._id, username } as UserAccountDto;
}

The code above is a method validateUser in the auth.service.ts file, primarily used to verify whether the username and password entered by the user during login are correct. It contains the following logic:

Check if the user exists based on username; if not, throw a 401 exception (a 404 exception is also feasible).
See if the user is locked out; if so, throw a 401 exception with a relevant message.
Encrypt the password and compare it with the password in the database; if it's incorrect, throw a 401 exception (three consecutive failed login attempts will lock the account for 5 minutes).
If the login is successful, clear any previously failed login attempt counts (if applicable) and return the user id and username to the next stage.

As can be seen, the validateUser method includes four processing logics, and we need to write corresponding unit test code for these four points to ensure that the entire validateUser function is operating correctly.

The First Test Case

When we start writing unit tests, we encounter a problem: the findOne method needs to interact with the database, and it looks for corresponding users in the database through username. However, if every unit test has to interact with the database, the testing would become very cumbersome. Therefore, we can mock fake data to achieve this.

For example, assume we have registered a user named woai3c. Then, during login, the user data can be retrieved in the validateUser method through const entity = await this.usersService.findOne({ username });. As long as this line of code can return the desired data, there is no problem, even without database interaction. We can achieve this through mock data. Now, let's look at the relevant test code for the validateUser method:

import { Test } from '@nestjs/testing';
import { AuthService } from '@/modules/auth/auth.service';
import { UsersService } from '@/modules/users/users.service';
import { UnauthorizedException } from '@nestjs/common';
import { TEST_USER_NAME, TEST_USER_PASSWORD } from '@tests/constants';
describe('AuthService', () => {
  let authService: AuthService; // Use the actual AuthService type
  let usersService: Partial<Record<keyof UsersService, jest.Mock>>;
  beforeEach(async () => {
    usersService = {
      findOne: jest.fn(),
    };
    const module = await Test.createTestingModule({
      providers: [        AuthService,
        {
          provide: UsersService,
          useValue: usersService,
        },
      ],
    }).compile();
    authService = module.get<AuthService>(AuthService);
  });
  describe('validateUser', () => {
    it('should throw an UnauthorizedException if user is not found', async () => {
      await expect(
        authService.validateUser(TEST_USER_NAME, TEST_USER_PASSWORD),
      ).rejects.toThrow(UnauthorizedException);
    });
    // other tests...
  });
});

We get the user data by calling the findOne method of usersService, so we need to mock the findOne method of usersService in the test code:

beforeEach(async () => {
    usersService = {
      findOne: jest.fn(), // mock findOne method
    };
    const module = await Test.createTestingModule({
      providers: [        AuthService, // real AuthService, because we are testing its methods
        {
          provide: UsersService, // use mock usersService instead of real usersService
          useValue: usersService,
        },
      ],
    }).compile();
    authService = module.get<AuthService>(AuthService);
  });

We use jest.fn() to return a function to replace the real usersService.findOne(). If usersService.findOne() is called now, there will be no return value, so the first unit test case will pass:

it('should throw an UnauthorizedException if user is not found', async () => {
  await expect(
    authService.validateUser(TEST_USER_NAME, TEST_USER_PASSWORD),
  ).rejects.toThrow(UnauthorizedException);
});

Since findOne in const entity = await this.usersService.findOne({ username }); of the validateUser method is a mocked fake function with no return value, the 2nd to 4th lines of code in the validateUser method could execute:

if (!entity) {
  throw new UnauthorizedException('User not found');
}

Throw a 401 error, which is as expected.

The Second Test Case

The second logic in the validateUser method is to determine if the user is locked, with the corresponding code as follows:

if (entity.lockUntil && entity.lockUntil > Date.now()) {
  const diffInSeconds = Math.round((entity.lockUntil - Date.now()) / 1000);
  let message = `The account is locked. Please try again in ${diffInSeconds} seconds.`;
  if (diffInSeconds > 60) {
    const diffInMinutes = Math.round(diffInSeconds / 60);
    message = `The account is locked. Please try again in ${diffInMinutes} minutes.`;
  }
  throw new UnauthorizedException(message);
}

As you can see, we can determine that the current account is locked if there is a lock time lockUntil in the user data and the lock end time is greater than the current time. Therefore, we need to mock a user data with the lockUntil field:

it('should throw an UnauthorizedException if the account is locked', async () => {
  const lockedUser = {
    _id: TEST_USER_ID,
    username: TEST_USER_NAME,
    password: TEST_USER_PASSWORD,
    lockUntil: Date.now() + 1000 * 60 * 5, // The account is locked for 5 minutes
  };
  usersService.findOne.mockResolvedValueOnce(lockedUser);
  await expect(
    authService.validateUser(TEST_USER_NAME, TEST_USER_PASSWORD),
  ).rejects.toThrow(UnauthorizedException);
});

In the test code above, an object lockedUser is first defined, which contains the lockUntil field we need. Then, it is used as the return value for findOne, achieved by usersService.findOne.mockResolvedValueOnce(lockedUser);. Thus, when the validateUser method is executed, the user data within it is the mocked data, successfully allowing the second test case to pass.

Unit Test Coverage

Unit test coverage (Code Coverage) is a metric used to describe how much of the application code has been covered or tested by unit tests. It is typically expressed as a percentage, indicating how much of all possible code paths have been covered by test cases.

Unit test coverage usually includes the following types:

Line Coverage: How many lines of code are covered by the tests.
Function Coverage: How many functions or methods are covered by the tests.
Branch Coverage: How many code branches are covered by the tests (for example, if/else statements).
Statement Coverage: How many statements in the code are covered by the tests.

Unit test coverage is an important metric to measure the quality of unit tests, but it is not the only metric. A high coverage rate can help to detect errors in the code, but it does not guarantee the quality of the code. A low coverage rate may mean that there is untested code, potentially with undetected errors.

The image below shows the unit test coverage results for a demo project:

For files like services and controllers, it's generally better to have a higher unit test coverage, while for files like modules there's no need to write unit tests, nor is it possible to write them, as it's meaningless. NestJS modules are primarily configuration files that define the structure of your application by connecting controllers, services, and other components together. They don't contain actual business logic to test, but rather serve as wiring instructions for the dependency injection system. Testing modules would only verify that NestJS's core functionality works correctly, which is already tested by the NestJS team themselves.

The above image represents the overall metrics for the entire unit test coverage. If you want to view the test coverage for a specific function, you can open the coverage/lcov-report/index.html file in the project's root directory. For example, I want to see the specific test situation for the validateUser method:

As can be seen, the original unit test coverage for the validateUser method is not 100%, and there are still two lines of code that were not executed. However, it doesn't matter much, as it does not affect the four key processing nodes, and one should not pursue high test coverage unidimensionally.

Writing E2E Tests

In the unit tests, we demonstrated how to write unit tests for each feature of the validateUser() function, using mocked data to ensure that each feature could be tested. In e2E testing, we need to simulate real user scenarios, so connecting to a database for testing is necessary. Therefore, the methods in the auth.service.ts module that we'll be testing all interact with the database.

The auth module primarily includes the following features:

Registration
Login
Token refresh
Reading user information
Changing password
Deleting users

E2E tests need to test these six features one by one, starting with registration and ending with deleting users. During testing, we can create a dedicated test user to conduct the tests and then delete this test user upon completion, so as not to leave any unnecessary information in the test database.

beforeAll(async () => {
  const moduleFixture: TestingModule = await Test.createTestingModule({
    imports: [AppModule],
  }).compile()
  app = moduleFixture.createNestApplication()
  await app.init()
  // 执行登录以获取令牌
  const response = await request(app.getHttpServer())
    .post('/auth/register')
    .send({ username: TEST_USER_NAME, password: TEST_USER_PASSWORD })
    .expect(201)
  accessToken = response.body.access_token
  refreshToken = response.body.refresh_token
})
afterAll(async () => {
  await request(app.getHttpServer())
    .delete('/auth/delete-user')
    .set('Authorization', `Bearer ${accessToken}`)
    .expect(200)
  await app.close()
})

The beforeAll hook function runs before all tests begin, so we can register a test account TEST_USER_NAME here. The afterAll hook function runs after all tests end, so it's suitable to delete the test account TEST_USER_NAME here, and it also conveniently tests the registration and deletion functions.

In the previous section's unit tests, we wrote relevant unit tests around the validateUser method. Actually, this method is executed during login to validate if the user's account and password are correct. Therefore, this e2E test will also use the login process to demonstrate how to compose e2E test cases.

The entire login test process includes five small tests:

describe('login', () => {
    it('/auth/login (POST)', () => {
      // ...
    })
    it('/auth/login (POST) with user not found', () => {
      // ...
    })
    it('/auth/login (POST) without username or password', async () => {
      // ...
    })
    it('/auth/login (POST) with invalid password', () => {
      // ...
    })
    it('/auth/login (POST) account lock after multiple failed attempts', async () => {
      // ...
    })
  })

These five tests are as follows:

Successful login, return 200
If the user does not exist, throw a 401 exception
If password or username is not provided, throw a 400 exception
Login with the wrong password, throw a 401 exception
If the account is locked, throw a 401 exception

Now let's start writing the e2E tests:

// login success
it('/auth/login (POST)', () => {
  return request(app.getHttpServer())
    .post('/auth/login')
    .send({ username: TEST_USER_NAME, password: TEST_USER_PASSWORD })
    .expect(200)
})
// if user not found, should throw 401 exception
it('/auth/login (POST) with user not found', () => {
  return request(app.getHttpServer())
    .post('/auth/login')
    .send({ username: TEST_USER_NAME2, password: TEST_USER_PASSWORD })
    .expect(401) // Expect an unauthorized error
})

Writing e2E test code is relatively straightforward: you simply call the interface and then verify the result. For example, for the successful login test, we just need to verify that the returned result is 200.

The first four tests are quite simple. Now let's look at a slightly more complicated e2E test, which is to verify whether an account is locked.

it('/auth/login (POST) account lock after multiple failed attempts', async () => {
  const moduleFixture: TestingModule = await Test.createTestingModule({
    imports: [AppModule],
  }).compile()
  const app = moduleFixture.createNestApplication()
  await app.init()
  const registerResponse = await request(app.getHttpServer())
    .post('/auth/register')
    .send({ username: TEST_USER_NAME2, password: TEST_USER_PASSWORD })
  const accessToken = registerResponse.body.access_token
  const maxLoginAttempts = 3 // lock user when the third try is failed
  for (let i = 0; i < maxLoginAttempts; i++) {
    await request(app.getHttpServer())
      .post('/auth/login')
      .send({ username: TEST_USER_NAME2, password: 'InvalidPassword' })
  }
  // The account is locked after the third failed login attempt
  await request(app.getHttpServer())
    .post('/auth/login')
    .send({ username: TEST_USER_NAME2, password: TEST_USER_PASSWORD })
    .then((res) => {
      expect(res.body.message).toContain(
        'The account is locked. Please try again in 5 minutes.',
      )
    })
  await request(app.getHttpServer())
    .delete('/auth/delete-user')
    .set('Authorization', `Bearer ${accessToken}`)
  await app.close()
})

When a user fails to log in three times in a row, the account will be locked. Therefore, in this test, we cannot use the test account TEST_USER_NAME, because if the test is successful, this account will be locked and unable to continue the following tests. We need to register another new user TEST_USER_NAME2 specifically to test account locking, and delete this user after the test is successful. So, as you can see, the code for this e2E test is quite substantial, requiring a lot of setup and teardown work, but the actual test code is just these few lines:

// login three times
for (let i = 0; i < maxLoginAttempts; i++) {
  await request(app.getHttpServer())
    .post('/auth/login')
    .send({ username: TEST_USER_NAME2, password: 'InvalidPassword' })
}
// test if the account is locked
await request(app.getHttpServer())
  .post('/auth/login')
  .send({ username: TEST_USER_NAME2, password: TEST_USER_PASSWORD })
  .then((res) => {
    expect(res.body.message).toContain(
      'The account is locked. Please try again in 5 minutes.',
    )
  })

Writing e2E test code is relatively simple. You don't need to consider mock data or test coverage. It's sufficient if the entire system process runs as expected.

Whether to Write Tests

If possible, I generally recommend writing tests. Doing so can enhance the robustness, maintainability, and development efficiency of the system.

Enhancing System Robustness

When writing code, we usually focus on the program flow under normal inputs to ensure the core functionality works properly. However, we might often overlook some edge cases, such as abnormal inputs. Writing tests changes this; it forces you to consider how to handle these cases and respond appropriately, thus preventing crashes. It can be said that writing tests indirectly improves system robustness.

Enhancing Maintainability

Taking over a new project that includes comprehensive tests can be very pleasant. They act as a guide, helping you quickly understand the various functionalities. Just by looking at the test code, you can easily grasp the expected behavior and boundary conditions of each function without having to go through each line of the function's code.

Enhancing Development Efficiency

Imagine, a project that hasn't been updated for a while suddenly receives new requirements. After making changes, you might worry about introducing bugs. Without tests, you would need to manually test the entire project again — wasting time and being inefficient. With complete tests, a single command can tell you whether the code changes have impacted existing functionalities. Even if there are errors, they can be quickly located and addressed.

When Not to Write Tests?

For short-term projects and projects with very fast requirement iterations, it's not recommended to write tests. For example, some project meant for events that will be useless after the event ends doesn't need tests. Also, for projects that undergo very fast requirement iterations, I said that writing tests could enhance development efficiency, but that's based on the premise that function iterations are slow. If the function you just completed changes in a day or two, the related test code must be rewritten. So, it's better not to write tests at all and rely on the testing team instead because writing tests is very time-consuming and not worth the effort.

Conclusion

After explaining in detail how to write unit tests and e2E tests for NestJS projects, I still want to reiterate the importance of testing. It can enhance the robustness, maintainability, and development efficiency of the system. If you don't have the opportunity to write tests, I suggest you start a practice project yourself or participate in some open-source projects and contribute code to them. Open-source projects generally have stricter code requirements. Contributing code may require you to write new test cases or modify existing ones.

Reference Materials

NestJS: A framework for building efficient, scalable Node.js server-side applications.
MongoDB: A NoSQL database used for data storage.
Jest: A testing framework for JavaScript and TypeScript.
Supertest: A library for testing HTTP servers.

DEV Community: woai3c

Analysis of Key Technical Principles for a Visual Drag-and-Drop Component Library - 4

SVG Components

Drawing a Five-Pointed Star with SVG

Other SVG Components

Dynamic Attribute Panel

Data Sources (API Requests)

Component Linkage

Event Monitoring

Event Triggering

Component Loading on Demand

Step 1: Extraction

Step 2: Packaging

Step 3: Dynamic Loading of Components

Other Small Optimizations

Image Mirroring

Real-Time Component List

Conclusion

Analysis of Key Technical Principles for a Visual Drag-and-Drop Component Library - 3

18. Combining and splitting multiple components

Selection area

Movement and rotation after combination

Scaling after combination

An unworkable solution (feel free to skip)

A workable solution

Restoring child component styles after splitting

19. Text component

20. Rectangle component

21. Lock component

22. Shortcuts

23. Grid lines

24. Another implementation method for editor snapshots

Summary

References

Analysis of Key Technical Principles for a Visual Drag-and-Drop Component Library - 2

14. Drag Rotation

Drag Rotation

Zoom In and Out

Solution

Automatic Snapping

Solution

Cursor

Solution

15. Copy, Paste, Cut

Copy Operation

Paste Operation

Cut Operation

Right-Click Operation

16. Data Interaction

Method One

Method Two

17. Publishing

Lazy Loading

Publish by Version

References

Analysis of Key Technical Principles for a Visual Drag-and-Drop Component Library

1. Editor

2. Custom Components

3. Drag and Drop

From Component List to Canvas

Moving Components on the Canvas

4. Deleting Components, Adjusting Layer Hierarchy

Changing Layer Hierarchy

Deleting Components

5. Zoom In and Out

1. Wrap each component in a Shape component, which contains 8 small dots and a <slot> for placing the component.

2. When clicking on a component, display the 8 small dots.

3. Calculate the position of each small dot.

4. When clicking on a small dot, zooming operations can be performed.

6. Undo, Redo

Undo

Redo

7. Snapping

Markers

Snapping

Optimization

8. Component Property Settings

9. Preview, Save Code

10. Binding Events

Adding Events

1. Wrap each component in a `Shape` component, which contains 8 small dots and a `<slot>` for placing the component.

Listening for `webhook` Events