Front-end early chat conference, a new starting point for front-end growth, jointly held with the Nuggets. Add wechat Codingdreamer into the conference exclusive push group, win at the new starting line.
The 14th | front-end growth promotion, 8-29 will be broadcast live, 9 lecturer (ant gold suit/tax friends, etc.), point I get on the bus 👉 (registration address) :
The text is as follows
This is the third session – front page set up a special luo Chen lecturer sharing
To introduce myself
I graduated from Zhejiang University of Technology in 2014. I have done.NET, written Java and played database before joining the big family of front end in 2015. I’ve seen the front-end transition from jQuery -> Angular -> React/Vue, experienced salary cuts, layoffs, and the founding and dissolution of a subsidiary. In January 2019, I formally joined Zhengcaiyun Co., LTD., responsible for front-end infrastructure related to “Luban” system construction, as an ordinary front-end typing engineer.
Build system topic introduction
The completion of business requirements is our own work, demand review -> development -> test -> online, after the online, is the next round of demand review -> development -> test -> online, 3 years, 5 years, 10 years have passed, what have you learned? Requirements review, development, it’s just brute force. So how to solve business problems elegantly, which involves the topic we are going to discuss today — building systems.
The business scenario
Technology is used to serve the business, there is no business scene of technology construction, are playing rogue. Let’s take a look at the business scenarios for building the system:
The above scenarios are real, in our company, the demand for portal sites is very large, and many portal sites are very similar, which means that as long as the visual specifications remain consistent, front-end components, components, modules and even templates can be reused in large quantities; In addition, the volume of demand raised by the operation is small, with many small functions, so the priority of demand cannot be raised naturally, and the operation itself is powerless, which ultimately leads to the loss of traffic and users. For the front end, repeated business requirements, for their own growth has no value at all, gradually numb, from the small target set at that time one hundred million more and more far away, become a ruthless coding machine.
The business case
The following are the portals of our company. The top, head navigation, banner, product category, shortcut entry and so on are extremely similar, which makes it possible to reuse components/modules and is also one of the prerequisites for the existence of the building system.
Let’s look at another example. The red box in this figure is filled with modules for which the operation/product wants to manually configure data. It takes up almost 70% of the page content, so you can imagine how painful it is for the operation to have their needs not solved in time.
What does the build system look like
Our building system is divided into three main function modules, one data module and one permission module:
- Site management: Site this thing, for ease of understanding, you can think of as a business classification, each type of business corresponds to a site (classification)
- Page management: this is the core function of the construction, the specific function can be seen in the following four consecutive screen recording (Figure 2 ~ figure 5).
- Component management: A page uses many components, and different pages use different versions of the same component. That’s why component management exists.
- Data Kanban: Data is the most intuitive way to show whether a system adds value and is being used effectively.
- Authority: authority is divided into two parts: one part is the control of menu and operation authority, the other part is the control of the system’s own data authority, that is to restrict the user’s visible scope of data, data authority is particularly important, if anyone can edit data, it is very dangerous.
Architecture diagram
The deployment of
How will the setup system be deployed? Some of you may wonder: how the hell can you deploy this, test, pre-release, production environment each set. You’re only half right. Here’s a question for everyone: Are pages in different environments the same? It’s the same one! No, three pages that look the same!! At this point, we have a mental expectation that we will only do one page build and it will work in three environments. So how do you do that? Put the staging system itself on an environment, preferably a separate server for the production environment (O&M VPC in the picture), and then connect this server to the other three business environments (test/staging/ Pro environment on the left). In other words, generate pages on the staging environment. We then synchronise the pages to test, pre-ship, and production environments through the “publish” operation to meet our expectations.
Having said so much above, we should also have a certain impression of building, and then we will enter the main topic of this sharing.
How to configure data
JSON Schema
When you think of data, what do you think of? String, Number, Boolean, but today I’m going to talk about JSON. Specifically, I’m going to talk about JSON Schema. So please think about this question. JSON constraints?
The answer is: constraints. JSON Schema is a standardized/normalized JSON data. So how do YOU define JSON Schema, and that’s what I’m going to talk about. Let’s start with a simple example.
A simple example
This is a very common form that includes an input box, a dropdown box, and a switch. The included elements include: label (theme color, account), placeholder, Type (input, switch), data (drop-down box options), key (field name), value (field value). All of this is relevant to our JSON Schema definition.
To rearrange the definition of the property, take one of the “theme color” drop-down boxes as an example:
You can see that we use a piece of JSON data to describe a specific page element, which is what the JSON Schema is designed to achieve.
Of course, in addition to the page element definition, the page also needs to have initial data, the definition of initial data is much simpler, something like this:
Extension type
We can also define input as String and switch as Boolean. These are all categories defined by the scene. There is no fixed expression, as long as you make sure the definition is reasonable. And easy to understand. In addition, there are some common things in ordinary business:
conclusion
In normal coding, the most common complex types we use to define data are Object and Array, while the most common basic types of objects and arrays are String and Number, which can also be extended types.
Let’s take a look at how JSON Schema relates to our business
The business scenario
Let’s go back to the portal where we just mentioned that the red box department is the part of the operation/product that wants to manually configure the data, so the question is, how can they configure the data, and how does the data configuration relate to our JSON Schema?
Turn business into data
As a first step, we need to turn the business scenario into objective data, taking a small piece as an example:
From the left side of the picture, you can see that this is a shortcut for each province. The data corresponding to this small page is shown on the right side of the picture:
Very common and very easy, right? So let’s move on to step two:
Turn data into definitions
We have mentioned a number of type definitions above, so let’s introduce these definitions into our business scenario.
I can see the data, which is of type Array and includes the “place name”, “icon”, “link”, and “Description” fields. Let’s take the two fields of place name and icon as examples:
- Name: label = name, key = addressName, type = String;
- Icon: label = icon, key = icon, type = Select, data = {icon1: icon1, icon2: Icon2}.
Then, when we integrate them, we get something like this on the right.
Formalize the definition into a structure
We’ve been able to convert a page module into a simple JSON Schema fragment, and we can do the same for other modules, whether it’s Object, Array, or even two-dimensional Array, and then, We put together each of the JSON Schema fragments. Of course, definitions are not enough. The page also needs data, so we can come up with a complete JSON Schema structure:
visualization
Finally, you can write a format function that fits your own page design according to your visualization needs, and convert this JSON Schema data into a form, table or other form. The following figure is the configuration page of operation data rendered by converting JSON Schema for your reference:
conclusion
Architecture and extension
Construction system is one of the front-end engineering systems, we can build different scale of construction system according to different business scenarios: component level, component level, template level, even application level; From the perspective of setting up scenarios, it can be a single page, a whole business link, a marketing campaign, or even the entire middle stage; From the perspective of terminal types: PC, H5, Native, small programs and so on; In order to ensure the stability of the system and the output of high quality and high performance pages, we also need the support of some other capabilities: the disaster recovery strategy of our own system, for example, what kind of bottom-saving solution is needed when the page is lost, how to recover the data is lost, and how to roll back when the release fails; At the specification level, we need a complete development lifecycle of scaffolding, constraints, and specification components; From the output level, we need to ensure that the output page performance is relatively considerable, so it involves the page performance detection, which is a complete system. Our performance detection system is called “Baice”, which is horizontally connected with the building system to provide the ability of building page performance detection. When it comes to pages, data comes in: BFF layers, data sharing, Ajax request aggregation, and so on.
All of the above mentioned, no matter a small point or a big direction, as long as you grasp the pain point of the business, design a set of general feasibility plan for it, and implement it into a set of system to feed the business, it is a qualitative breakthrough, but also a big step towards productization and intelligence. Remember: one small step for you, one giant leap for business.
Get in the bowl, we’re hiring!!
For the latest recruitment information of the team, please scan the qr code below and follow the wechat public account of “Zhengcai Cloud Front-end Team”. We are looking forward to your joining us.
Please send your resume [email protected]
