Let’s look at a page first: the page address. It only took me five minutes to get this page up and running. Of course this is because I don’t need to think about any design or business, I just want to show you the features, but I believe this should give you the first glimpse of the power of our system. If you want to see the online page you can see here: 619 big push

Note that each TAB on the page displays different content, and the categories under the first TAB also display different content, and a TAB or category can have multiple different content.

As a comparison, we can try alipay’s cloud Butterfly building system. We can obviously see that the functions provided by Cloud Butterfly are impossible to build such a complex page. Of course, the example of Yunfengdie is not because he is the best in the industry, but because I found a more clear is this, and I have a friend in alipay told me that it is used a lot. In addition, After all, Alipay is a leader in the technology environment industry (they also say so), so it is relatively representative.

This is the first highlight of our scaffolding system: content nesting (or component nesting). This is a fundamental capability that we have taken into account from the beginning of the system design, and it needs to be supported not only at the editing stage, but also at the page execution level.

Build system

Sooner or later, the web pages you see may not be written by a bunch of front-end developers, but can be created by anyone. —- by Sam’s twin

I believe that we have more or less used some page building system, the ancient Dreamware is also an early group of page building practice, but he is more inclined to UI design, obviously no support for business functions. This is also understandable, put ten years ago can rarely have a front-end engineer this position, most of them are cut diagram, cut diagram and then let the back end to fill in the template, to carry out page access data loading.

The front-end page construction in the present era is obviously different from that time. As the front-end framework has gradually unified the development standard of the whole front-end, the development mode of the front-end project has also changed from the previous single page to the current single project system similar to mobile APP. The rendering of the page rarely goes through back-end services, but is computed and rendered by the front end in the browser. So we tend to call it a front-end application rather than a front-end page.

Technological changes often bring changes in product forms. Basically, Internet companies now uphold the purpose of rapid iterative growth, so no matter what stage of Internet companies, as long as they have marketing needs, they hope to have a page building system, because it can help us solve a lot of problems:

  • Operating products to create their own pages, efficient
  • No developer intervention, throttling
  • Builders can do according to their own needs, eliminating communication costs and possible miscommunication resulting in unsatisfactory final output

In addition to the above increase in output, because the components of the building system are relatively uniform and stable, it also eliminates some of the silly mistakes that developers may make in the process of implementing marketing pages (after all, people are always the biggest variable).

To sum up, building the system is now naturally a more interesting and in-depth topic in the front end.

features

Having said that, what are the differences between our building system and those on the market? Before I summarize the features of the various functions, I’ll throw out a conceptual summary:

From the beginning of the design, we were not focused on functionality, but on implementing the features of a front-end framework.

How to understand this sentence? Our front end of the page is built on the VUE framework, so vUE as a framework can meet almost all of our requirements in front end development, why? I can summarize the following points:

  • Componentization, which abstracts components through props
  • Components are nested to implement content concatenation
  • Render and update through state => UI mapping

Because for most general-purpose front-end pages, a page is a combination of elements, plus some style differences. The main update of the page is also changed according to the update of relevant data. Even if it is the response of the event, to a large extent, we can regard the event as changing one of our state, which then leads to the change of the page UI. This is also the principle of practice that currently prevails in the front-end framework.

On this basis, as long as we can accurately achieve the above basic functions, we can even consider that our system has reached the same level of expansion capacity as vUE framework.

Of course you can say that the core of VUE is responsive, and indeed it is, it is the core technology of the implementation of vUE framework. However, in the process of building products based on VUE, we do not care about its internal implementation, but more about its exposed API and capability. For example, vUE and React both have the ability to abstract components based on props. We think that this capability is similar, although their internal implementation methods are very different.

After knowing the core concept of our building system, we can talk about what features our building system has in the end:

  • Nesting of components
  • Intercomponent linkage

And on that basis, we can hold these imaginations:

  • Splicing basic components into a new component that can be configured for use by other users
  • Complex interaction between components, such as a button in one component that hides another

You can see that when you edit the TAB form, you can select what to use under each TAB, and you can select other components.

Don’t underestimate this ability, a basic ability to bring unlimited imagination to a product.

In addition, we have actually achieved the ability of linkage between components, but it has not been reflected in the product, because the product has not found a good expression for users to use this function. To put it simply, the operator cannot understand the connection between components, and the product cannot come up with a good way to reduce learning costs, so it is not open for the time being. But again, the more basic capabilities, the more room for product design.

Today, I will introduce this product without going into details. The overall architecture of our building system is actually very complex, including:

  • Component access interface system
  • Component version, Runtime version, and page version maintenance
  • A component publishing tool similar to NPM with integrated native component development debugging capabilities
  • How does a component maintain its props and generate forms based on component features at edit time
  • How do I access each page
  • . A series of features designed to improve usability and efficiency

These will be shared gradually in the future. Meanwhile, during the development, we have implemented a set of tools to generate forms through JSON-schema, which will be open source soon.

Finally, we have recently developed a pre-render feature that further improves the first comment experience and reduces the white screen time during load JS files, making the page experience more than a notch up. The link is below so you can experience it yourself:

  • Before optimization
  • The optimized

It is recommended to view in the mobile terminal, after all, there is no optimization on the PC terminal.

The original address