Today, I will bring you a tool juggle that uses JSON data to build pages. This project is reorganized and open source based on an internal development tool of the company. It’s not fully functional yet, but the basic rendering engine works fine. To see a demo of the demo, you can see through JSON rendering and become: juggle. Isjs. Cn/report. HTML…

GitHub

Github.com/adminV/jugg…

Origin:

Internally, our working mode was relatively primitive before the launch of this tool. When new requirements came, we would develop based on a unified project template. If existing components met the requirements, we would Copy the code to a new page for development. Even if the two pages are 90% similar, they need to be developed from scratch. The development time includes finding components, debugging components, connecting with new data, and self-testing, etc. In an optimistic case, the development time is about 3 hours. After the completion of development, QA students will test according to the new page, and the test time will also need 4 hours. That is, a page copy + modify + test time takes 1 day. When such development speed is faced with extremely frequent demand iterations, such as the launch of ABtest multi-demand, 5+ requirements are launched in one day, there will be a bottleneck, and the increase of manpower cannot be improved in a qualitative way. The earliest solution proposed by CTO is to refer to the report rendering page of big data platform, make the page component and template, and realize the flexible configuration and construction of the page. The ultimate goal is to be able to achieve visual drag-and-drop layout of the page, handing some simple requirements to the PM or operations. After the tool is online, the effect is very good. If all the existing components are changed, it only takes 10 minutes to build a page, including 30 minutes to test. Because the components are already there, the tests need only be simple validation. In this way, the whole development cycle is shortened to one hour, and the purpose of component management and reuse is achieved.

Solution:

Define your goals first and why:

  1. Reduce repetitive development costs, custom components shared by multiple pages, multiple projects, and a common repository for maintenance.
  2. Delegate simple tasks to PM or operations.
  3. To improve development efficiency, the previous development time of a new page is only 10 minutes using configuration generation.
  4. Improve test efficiency, do not need to conduct in-depth test when components are not upgraded, just need simple smoke, and facilitate future integration of E2E tests.

After determining the overall direction, we carried out the technical selection, which is highly similar to the demand of Ali’s flying ice. However, as the material development of flying ice is not quite the same as imagined, eventually gave up. I think of the material as a very flexible element that I can re-wrap based on existing component libraries or develop components from scratch. So we decided to develop a new set of tools based on our own understanding. Internal maintenance of materials, dynamic use of materials in the page for page building, bearing multiple pages on a basic page, so that the page configuration.

After a clear goal to clear the first version of the goal to achieve, abstract look at our daily development of the page, can be divided into the following categories:

  1. Active pages feature rich animation styles.
  2. Input page features form verification, input item verification.
  3. The output page features one-way requests and no user operations.
  4. Landing page features more entrance, more programs, less interaction.

Just recently, there are a lot of activity pages, main venue, sub-venue and brand landing pages on various e-commerce platforms. This open source tool is aimed at achieving the fast configuration of the landing page.

The landing page is made up of different components, divided into the following three categories according to the purpose of components:

  1. Collection container-level components, such as drop-down list containers, expand containers, TAB toggle containers, sidebar containers, etc
  2. Block block-level components that display the smallest units of data, such as multi-row content blocks, left-right content blocks, Flex bisected content blocks, etc
  3. Public Public components, such as global prompt window, global header and footer, and global loading

The flip side of flexibility is specification. If a page is configurable, it meets the following requirements, which I call conventions:

  1. It is possible to place any component in the same place, requiring all components to accept the same parameters.
  2. Based on the first point, it is required that each component’s requirements for prop parameters should be uniform.
  3. Components should be hierarchical, container-level collections have the ability to host block-level components, and containers can be nested.
  4. Container components should have the ability to retrieve data autonomously, such as three tabs with separate interfaces and lists for each TAB.

After the rules of the page are made, we need to consider the specification of the page data. We divide the page data into two categories:

  1. Page layout data, what components is the first part, what components are included, and have a source that returns the layout data
  2. Page business data, again, the premise of reuse is specification, we keep the simplest data structure with the back-end convention interface to ensure its reuse.

With that in mind, take a look at the actual implementation.

Development steps:

The goal is clear, the scene is clear, and the project technology stack is determined. The development environment uses the modified @vue/CLI 4.0. This project does not rely on any Vue component library, I use the good Vant library to complete the demo as soon as possible. The vehicle for the page template is the report.html page. Used to host all page configurations. The page template file is a JSON file in the public/pageConfig directory. It is a JS file starting with config. The configuration parameters are mounted to window.pageconfig and passed down through the Vue instance. Of course you can use interfaces instead of files, I did this to make configuration maintenance easier.

Each time a new requirement is encountered, it is necessary to abstract it as a separate component as possible, both from a development and testing perspective. The Juggle tool doesn’t focus on components, just structure. So you can import components directly from the component library, or you can re-develop and encapsulate a new component based on the component library. All components are located in the/SRC/Components directory. Component types are block, Container, and public. Add component files in the corresponding directory to complete the development of new components. The second step will be a new component to register/SRC/HTMLS/main/report. Js entrance mixins. There are two simple steps to using this component in your configuration:

   {
       "templateId": "BlockFlexBox"."prop": {
         "dataKeyChain": "bannerList"."styleOptions":{}
       },
       "childItem": []}Copy the code

Note that the structure of juggle specifies the prop of the component, and all components accept only prop, childItem, and baseData. Prop: contains all internal variables. ChildItem: Contains all child components and renders baseData in order. That is, all parameters of the new component are contained under prop and disassembled inside the component.

Run locally:

Clone the project and execute the following commands

	$ npm install 
	$ npm run serve
Copy the code

Open the page to view: http://localhost:8080/report.html? pageCode=0001

Open source cooperation:

The project is currently just a simple rendering tool, and I hope it will become a more powerful and flexible development tool in the future. At present, we can think of the following big feature points that have not been implemented:

  1. Anti-cache of static configuration files
  2. Package components on demand and load them on demand
  3. Convention and management of global state
  4. Drag and drop layout background implementation
  5. To realize the above functions of the configuration of cross-cross-type pages, it takes a long time to sort out and analyze by virtue of personal strength, and the independent maintenance idea is single and will not be considered comprehensively. So I invite you to participate in the maintenance of this open source project. Just Fork into your own repository, implement the function points and submit the PR to me. Students who participate in the open source project will be included in the project personnel list.