This article was originally published at: github.com/bigo-fronte… Welcome to follow and reprint.

background

In daily project development, we may encounter some projects whose copywriting may change from time to time. Multiple pages have similarities, but there are differences in the same pages. For example, in some live events, the strategic logic remains the same, but the prize, background picture and banner are changed, which can also be called skin change. For example, the official website of some products will continue to add some sub-pages, but the style is unified, but will change the layout and copy. At this time, as a technology, we will think about how to reduce the development cost, avoid changing a copy to replace a picture to run a complicated online process? Wouldn’t it be a lot easier to make these changes configurable? I was working on a project with this scenario a while back and tried to make the page as configurable as possible. Here is a brief introduction.

I. Project Introduction:

The project is an official website project, most of which are static pages, analyzing requirements and summarizing the following points:

  • There are multiple sub-pages, similar UI templates;
  • Some pages will change frequently;
  • Later may add new pages, but the style is the same, the basic layout remains unchanged;

Second, the overall idea

Core idea: what need to configure can match all match. For the whole project, you can configure the menu bar, the different modules that a page contains. For a single page, you can configure images, copywriting, styles, links, and so on.

Three, implementation examples

Menu configuration

Example of top menu: The following figure shows the effect of the menu, including the first-level menu and the second-level menu.

The menu configuration JSON looks like this


export default {
menus: [{title: {  // First menu title
        default: 'products'.// Default copy
        langKey: 'tabLang001'.// Multilingual copywriting
      },
      footerShow: true.// Controls whether the footer is displayed
      children: [ // Secondary menu
        {
          title: { // Secondary menu title
            default: 'Real-time Audio Interaction'.langKey: 'tabLang002',},path: '/product/audio-call'.// Page routing
          openType: 1.// Whether a new page opens
          icon: 'tab-p2.png'.// The icon to the left of the title}]},]}Copy the code

The outermost layer is written as an array, which is convenient for expansion. After introducing the assignment value, we can traverse it according to our needs, and realize the personalized configuration of each item based on the judgment of whether the attribute of specific purpose exists.

Product series page configuration

Let’s have a look at the design first

It can be found that the style is similar and each product introduction page can be brought out. Let’s look at a larger picture of a particular page.

Looking at the code, we start with the product page. Although there are multiple pages, we can use one set of code, depending on how we configure each module as well.

Each module loads the corresponding configuration by defining the Name attribute of modules.

You can override the current style by writing the style directly in the configuration, or you can pass a value or string to load a different style by taking the class name written in the page.

Iv. Going further

Up to now, although we have realized configuration, it is localized. We can modify a copy directly, but we still need to go through the process of packaging and publishing. How to go one step further? Here, we use pear configuration platform developed by the company’s internal front-end architecture group to realize the online configuration of JSON configuration.

First we create a profile on the platform, then copy the local configuration data into it and publish it so that we have an online profile.

Then we introduce the corresponding package and API call online data.


import pearFetch from "@xxx/pear-fetch";


const configFetch = new pearFetch({
  bizType: "xxx".pearEnv: env === "prod" ? "prod" : "gray"}); .// Get the cloud data by the corresponding ID
const json = await configFetch.fetch({ id: xxxxxx }); .Copy the code

Distribute data to pages based on the key specified in JSON, such as the routing key.

Finally, in case the service stops or the network fails, the local JSON configuration is used.

import { PEAR_ID } from '@constant/pear';
import LOCALDATA from '.. /mock';

    async getJsonConfig() {
      try {
        const configFetch = new pearFetch({
          bizType: 'xxx'.pearEnv: this.nodeEnv === 'production' ? 'prod' : 'gray'});this.json = await configFetch.fetch({ id: PEAR_ID });
      } catch (err) {
        // Local data is in the backpocket
        this.json = LOCALDATA; }}Copy the code

The PEAR platform provides the ability to publish and modify configurations, so that if a document needs to be modified, it can be published directly in the cloud without the cumbersome project release process. The advantage is that it can be quickly updated online. Of course, in order to keep the copy synchronization, it is recommended to copy the latest configuration of the cloud to the local. Upgrade along with later versions.

conclusion

The above is a simple practice about page configuration, which improves the development efficiency on the whole, especially saves a lot of time for the later maintenance, and can even be handed over to the operation to maintain the configuration, we only need to check before release. Page configuration is really worth trying, it really smells good!

Welcome everyone to leave a message to discuss, wish smooth work, happy life!

I’m bigO front. See you next time.