In traditional front-end business development, component role positioning and evolution

In the traditional Web development process, the technical architecture of the front-end project can be divided into several steps. Generally, we first determine a basic technology selection, such as Vue or React, and then we choose functional component libraries, such as ElementUI or antDesign, and then according to the business needs, Secondary encapsulation of some customized business components, which basically completed our technical structure of the background system.

Then, in the process of continuous business development, we will abstract some public block modules according to actual needs. After accumulating over a long period of time, we can quickly build a new page through these business block components, thus greatly improving the development efficiency of the team.

However, in this scenario, we still need to take the initiative to create new pages, the process link is still very long. In view of this situation, we need to consider whether there is a more elegant way to abstract and regularize the development process state, so as to reduce the repeated page building process.

Some limitations of componentization

  1. For some teams, there are a lot of front-end projects, and we still need to introduce business components to each front-end project separately. This process itself will cause inefficiency.
  2. For some complex systems or cross-department development, pages between multiple systems may also share business components, which inevitably leads to the increase of communication and R&D costs. In many cases, we even have to make some compromises and consensus in team time to achieve business development.
  3. Some of my current work comes from different companies and industries, and there is a lack of rules for efficient circulation between different entities across industries, corporate entities or third-party communities.

Low/no code necessary and sufficient conditions

  1. Component flow: Currently, we lack cross-agent protocols for component flow, such as production, consumption, management, secondary packaging, choreography, and so on.
  2. Rich repository: A repository based on business components is a must for a low-code platform.
  3. Choreography: The primary capability of choreography is to make it easy for developers to design, build, and configure business components.
  4. Renderer: When our business developers finish developing a page, we need to provide a way for users to preview or publish, which requires a renderer to render and display the code we generate.
  5. Code generation module: After developing a project based on a low code platform, we need to deliver the source code package or project to facilitate our developers for production deployment or secondary development.

Some limitations of low code

Low code is the need for business, product, technology and so on, a certain amount of compromise between the parties, we can only solve 30% to 60% of the business scenarios, the final effect still needs to carry out business verification.

Low code practices -H5-Dooring

H5-dooring is an open source low-code platform launched late last year. Its main purpose is to make it easy for users to quickly build simple low-code projects. Since the second half of 2020, there have been 4,500 +stars on Github, with more than 50 enterprises and 1,000 + users generating pages based on H5-Dooring.

Three main implementation ideas for low code interaction

The first is a nailing appropriate layout by using the natural flow, its advantage is that this kind of development mode is more fit our traditional development process, its configuration flexibility is also very high, and were also more likely to do adaptation, relatively developed threshold slightly tall, but to no technology development experience of small white developer is not very friendly.

The second is our H5 – Dooring adopt the smart grid layout plan, its advantage is: can we go by dragging the developers to easily build a component and page, but the downside is that cannot go on some of the more complex component hierarchy, such as overlay, between layers or pictures or the flexibility between multiple components, Have very demanding scenarios.

The last one is the free layout solution, which is now widely adopted by many LowCode platforms, such as Yiqixiu, Luban, Byte Rubik’s Cube, etc. Its benefits are obvious, and its granularity is very friendly for business scenarios with custom requirements.

Overview of the overall architecture of H5-Dooring

The overall architecture of H5-Dooring consists of several modules: a material library, a layout canvas, a property panel, a function panel, and other extensibility capabilities.

Rendering: H5-Dooring’s page rendering is based on schema information and dynamically renders components. The layout method mainly uses the location information of components in the schema to dynamically calculate the grid position and render the entire page. In addition, components are also loaded on demand based on the schema component information, so it is not slow to load a complex page rendering.

Property panel, form design: H5-Dooring’s property configuration uses a dynamic configuration panel, which is internally implemented and resolved based on a set of DSL rules and supports flexible property Settings. In addition, we also package many commonly used form components to allow developers to build pages quickly.

Dynamic data source design: Many low-code platforms use static data source design, such as multiple business components using the same data source, often duplicating multiple copies of data, no longer associated with each other. H5-dooring supports dynamic data source design, which means that data can be dynamically loaded in a production environment for updates and replacements.

Generating module: Currently h5-Dooring supports building Dist and source packages. The implementation behind it is based on our base project, which allows our users to generate Zip packages of Dist and source projects online and make them available for download.

The future of visual architecture

The first point is to build engine optimization to enable us to do more functional extensions and enrich business component materials to meet more application scenarios.

The second point is offline. Many companies are limited by various network problems and need some local offline development. We may implement it through Electron in the future.

The third is an action system that reinforces the relationship between components to support the interaction and collaboration of our business components.

The fourth point is the intelligent construction of our monitoring system. We can analyze a user’s own preferences through the feedback system of user operations and user data, and then dynamically implement some personalized service capabilities.

The last point is cross-end requirements, which are also the rigid requirements of many front-end projects, and we will also think of some implementation schemes.