2020.3.28 front-end chat early in the third period theme “front-end visualization builds | intelligent building”
- Why we need to build
- Comparison effect before and after construction
- What are the problems encountered during the construction process and how to solve them
- What do you think after building the project output
- Establish the requirements of building for development
- The need for manpower
And for the open source built products that will be discussed in the activity, I have tried them and felt them from the user’s point of view. Here, I still organize my gains in QA style, because it’s more intuitive. (After all, videos and texts will be sorted later
1. Why is it necessary to build?
This problem is very simple, all to avoid repetitive work, improve efficiency, empower. There are two categories of build from the user’s point of view:
- NO CODE: Let operation, product and other non-developers can also produce pages through UI drag, click and select, and publish directly.
- LOW CODE: A new term in this contact — LOW CODE development, which simply means that developers of different levels can help complete some complex applications by submitting some options to directly generate components/selection templates.
2. Comparison before and after construction?
Here to eliminate some misunderstandings, because building the system is very human and resource consumption, 10 people team is expected to take a year to make the prototype, if there is no reasonable structure and planning, it is difficult to complete, for example, visual construction for visualization, efficiency is likely to decrease rather than increase. Materials are difficult to maintain, drag components are too ugly to be used, code generation is not as expected, and so on. As for the number of users served before and after the establishment, how much efficiency has been improved, there is no advertisement for lecturers here, and the PPT in the later stage will introduce it. Lecturers talked about the system is a long time to settle down, to build the system components, page usage are supported by data, clearly know which components used high frequency, how many pages generated. What are the problems with doing that? Let’s move on.
3. What are the problems encountered during the construction process and how to solve them
data
Some are landing pages, some are multi-terminal components, and even have supporting editors, etc., but how to avoid the problem of data, the output of static pages, components are different, how to constrain/manage data fields. There are two solutions. One is for the simple page used in operation, which may just change the banner or color. You can configure, modify the text and link by setting up the management background. For user permissions, you can also let the administrator through the background to configure. The other is asynchronously acquired data, which needs to be requested by the interface. The front-end data type can be standardized through the protocol descriptor JSON Schema, and the back-end data can be stored.
How is Schema regulated? Let’s take a look at Luo Chen’s share:
First we can extract the data from the business and then we can turn the data into definitions and then we can standardize the definitions into structures
)
- Scattered requests: The interface scenarios are complex and the requests are difficult to maintain
- Too many repeated requests: crushing page performance
- Heavy interface pressure: The same page requests the same service interface for multiple times
- Data model variability
- Three terminal isomorphic appeal
In order to solve the above problems, their team created a set of efficient and universal data request solutions: First, page model design pageData is the abstract description layer of the page, pageData can be resolved into real pages, including page level configuration and component level configuration
interface iPageData {
pageId: number; / / page id
pageConfig:{ // Page configuration
basic: iBasic; // Configure basic information
search: iSearch; // Search the configuration
share: iShare; // Share the configuration
}
userConfig:{ // User configuration
checkNewUser: boolean; // Whether you need to query the new person
},
componentConfig: iComData[] // Component configuration
}
Copy the codeComData is the core part of PageData, including template configuration, data configuration and component relations, followed by data source and data optimization strategy. Data source is the basic unit of the request model, describing a class of request actions.
The three-terminal engine collects and executes the initial state functions of each component before creating the component instance. The result of the function’s asynchronous return is used as the component’s initialization rendering data. The straight out side also performs component activation after the page comes out. (These are mentioned in the Vue SSR document and there is a tricky scene. In order to improve the direct output speed, can the primary and secondary interfaces be called separately? The primary interface is called on the outbound side and the secondary interface is supplemented on the client side. The second parameter of the initial state function is a callback function. Passing in the initial state data and executing it triggers the engine to render immediately. Therefore, it can be used for split rendering of the initial state data. Wait until you get to the client to do the execution and supplement the dynamic data.
Terminal seconds to open
Since the building system made by Moming team is used for marketing, there is a demand for opening terminal seconds. Let’s take a look at the traditional optimization measures first
- Page Bundle = Page Code + Page Info + Module Code x N
- Because Module Data varies, and Module Data changes frequency > PageBundle
- So separate the Page Bundle from Module Data and precache the Page Bundle
- Each Module initializes a separate asynchronous request for Module Data after rendering
The problem here is that due to the independence of modules, independent asynchronous request for data rendering will cause uncertainty and lag in rendering, and when the operation changes the module combination at any time, the change will lead to frequent failure of pre-cache. The combination of modules is also infinite, but the cache capacity is also limited contradictions. The optimization idea provided here is to analyze the priority of changes between different pages and modules first, and see which data changes the most!
)
- For the same Page Code on different pages, the Page Code is pre-cached and shared across pages
- For the same Module with the same Module Code on different pages, cache the Module Code and share it across pages
- Page Info Aggregation Page Data = Page Info + Module Data *N
- Module Data separate Page Code, Module Code, Page Data
- In the client container (App) to achieve the page and module pre-cache, trigger the pre-request when the user triggers certain behavior (behavior includes the user to pre-request when the pull down, background idle pre-request.
The process is as follows:
The deployment of
Luo Chen and his team used The Luban system. The problem they encountered in deployment was the same as multiple environment pages, and the press conference was tedious. The final solution was to build a generated page, deploy once, and synchronize three environments. The last one to share yi Pure big guy said massive deployment, for business services, to ensure that the service can not go wrong. This situation is very difficult for me to meet honestly, and it is very partial to the direction of operation and maintenance, you can go to see the relevant video or PPT.
Multi-branch development
The iceluna editor supports multi-branch development, and in the case of multi-person parallel development, there can be more than 20 branches, which cannot avoid conflicts when committing. In this case, it also provides a baseline synchronization mechanism in addition to resolving conflicts. A code commit conflict is resolved and the resolution status and bands are backed up to DB
Efficiency measurement system
How do you measure how much more efficient a build is? The iceluna team used the halsted software complexity measurement algorithm model to calculate the expected development time compared to the actual development time.
4. Requirements on development and manpower for construction
Different businesses have different requirements. Imgcook project prefers deep learning at the later stage of its business, and of course hopes that the front end will have this capability.
Vue /React + nodeJS is the standard configuration. Manpower requirements to build is very short of people, time and effort (small companies may not make the project, the company is cold.
5. Personal thinking
By the third session, more than 800 people had participated in the early chat. Although it was an online event, the discussion in the group was also very intense, with a discussion atmosphere that was not found in offline activities. It was obvious that QA sessions were asking a lot of questions that were very informative.
New terms are constantly popping up to refresh my cognition. You will find that in the construction system, cross-terminal has become standard, multi-person collaboration, page direct delivery (SSR), editor development, deep learning, artificial intelligence and other technologies are new fields.
I heard not only the technology, but also the way that our predecessors thought about the future, which raised our thinking levels. Listen to their ideas as leaders, or think in a way that is close to the design/product/back-end students. After all, we are not struggling alone in the company. This is also better in the work to achieve empathy, mutual understanding, learning. Miaojing lecturer said that the future development direction of the front-end, will gradually from low code to no code transition, become more intelligent, “matting boy” is likely to change into “adjustment engineer”, senior development has gradually evolved into a more challenging position, there is still a lot to learn. In other words, the weak are weaker and the strong are stronger. What do you want to do in this era of continuous development?
About the conference: front-end early chat conference goal to become useful, understand, copy to go front conference, plan to do 12 in 2020, jointly held by the front-end early chat and nuggets, the future front-end early chat conference schedule dynamic, data download please scan the code below the public number to follow:
