preface
The front end often develops data statistical charts in the background of the business. For libraries with strong configuration like Echarts, it takes a lot of time to view documents. In most cases, statistical charts in a project only account for a small part. The product manager is obviously personalized to the design of the chart (today, he saw a style of chart and thought it was good, and then he wanted to copy it into his business), the same type of chart may have different styles, and the code has to be rewritten. Always give a person’s feeling is the development efficiency is low, product design efficiency is low.
We’ll start with a look at the process that a front-end might normally go through when developing various data charts, using Echarts as an example:
- Go to the Echarts website
- View the instance interface, refer to the similar legend to be implemented, find the appropriate instance to copy the required instance code
- Open the business project copy code and discover that dependencies need to be installed, either through script in HTML or through modules (in which case webPack may also need to be configured to address some dependency optimization issues)
- Finding details that don’t match the UI or product prototype, start looking for document configurations such as axis colors, scale colors, internal spacing, reminders, copywriting templates, etc
- When I made the second diagram, I found that it was a line diagram similar to the first one, but this time there were multiple lines in one diagram, and the UI changed a little bit in detail. Then I repeated step 4 above.
- Some time later, another business project needs to do data charting again. At this point, I thought I had done it before, and then I found the comparison chart of the old project, copied the similar code, and modified it. When I found the details inconsistent, I started step 4 again
Repeat steps 4 and 5 several times, and the configuration code itself is a lot of time. Two or three diagrams can make a hundred lines of code. After a few of these twists and turns, you might get a little familiar with the API, but still feel that each development is inefficient. And that’s where today’s share comes in.
plan
In view of the application scenario of data statistics chart of background project development in various businesses of the company, in order to solve the above two efficiency problems, I think of the following two directions to deal with:
- Abstract code reduces the amount of application code, and dumb configuration prevents every developer from spending time reading and re-reading documents — improving development efficiency.
- Unified chart usage style, reduce some degree of personalization, provide chart interface and corresponding component code — improve product design efficiency.
In simple terms, it encapsulates common chart components for use by teams, agrees on a common chart style, and provides visual interface documentation
Advantages:
- Focus only on the more core configuration, components that erase configuration details and improve development efficiency
- Improve the efficiency of product design and save the time of design selection
Disadvantages:
- Lack of flexibility (remove common parts, sacrifice flexibility, use commonness)
- Common chart component development has an investment cost
The implementation of
JS component library
Now that the purpose and direction are clear, the first thing that comes to mind is to do a component wrapper based on a tripartite chart library, install dependencies through NPM, and finally write documentation. Now called the JS component library solution, let’s consider an implementation and use process for this solution component library, using Echarts as an example
- Create a new code base and install echarts dependencies
- Create a new component (such as a line chart component)
- Encapsulate component parameters, callback methods, and so on
- To be compatible with VUE, Angular, and React, component code needs to be written in three compatible sets, or through code optimization and build processing, one set of code generates multiple framework components
- Versioning and publishing component libraries
- Write a web document and display examples on the web
- Use the component library for business system installation
- If the code needs to be upgraded or bug fixed, the component library needs to be modified, the new version needs to be created, and the business system needs to be reinstalled
Below is a schematic diagram of this scheme:
However, the above scheme brings some troubles and problems:
- Multiple frameworks may need to be compatible and component library development costs will increase
- Bug modification and library upgrade require version release, and each business system may need to update dependencies after a version, increasing maintenance costs
The Iframe solution
My initial starting point was to implement this scheme through iframe + postMessage, which is introduced below. The solution ultimately outputs each component as a static page, embedded in our business system via iframe, passing data, configuration, and event bindings via postMessage. Introduce first roughly develop and use flow, do analysis to its merit after that.
- Create a new code base and install echarts dependencies
- Create a new page component (such as a line chart component)
- Encapsulate component parameters, callback methods, and so on
- Package the output into static resource pages and publish it to the static resource server
- Write a web document and display examples on the web
- The service system does not need to install any dependencies. The Iframe configuration URL is used to import components and the postMessage is used to send configurations and data
- If the code needs to be updated or bug fixed, the component library is re-modified, static resources are packaged and updated, and the business system does not need to be reinstalled to rely on direct access to update. If there are similar components that change a lot, you can output a new version. For example, the old version is xxx.com/v1/bar.html and the new version can be defined as xxx.com/v2/bar.html without affecting each other
Below is a schematic diagram of this scheme:
Let’s compare the two schemes:
To optimize the
Stability:
One area of particular caution about Iframe is its stability. Since all business system diagrams point to the public diagram project and need to be accessed, if there is a problem, the impact can be significant. Since the business systems are decentralized, we need to conduct a round of testing when we release a new version of the public charting project, first ensuring that the new version does not affect the existing business systems. Therefore, in view of these two problems, on the one hand, we need to strictly guarantee the code quality of the public chart project, and pay special attention to the control of code merge permission and artificial review; On the one hand, a page menu can be added to the document website page of the public chart and embedded in all the relevant pages of the background business system through the same way of Iframe. Since our middle and background have unified access to the internal sso permission login system developed by the company, we can see the graphs and statistics related pages of the business system according to the current login user and his permission. Then we give a test user the permission to configure all the business, can view all the business related interface through the public chart system itself, so as to do the test acceptance.
Because of this, the public chart project itself not only provides the page components for the business back-end systems to use, but also brings together the data statistics interface of all business systems, becoming a real data market. Our solution at this point is a complete public chart data platter.
Resource size
In terms of static resource size, each HTML component only introduces a tripartite chart library and a small section of the component’s own JS code, without introducing any framework to reduce the file size as much as possible.
Iteration principle:
First, there is a cost of packaging. It is not to write all the component libraries at the beginning, but more to consider packaging when the development needs a certain kind of diagram. At the same time, we should not only consider the use of the current version, but also try to consider the universality and use of other projects in the future
Pure personalized configuration
Of course, in many cases we need to personalize our diagrams. Now that we have a public system, if we encounter a personalized diagram, why would we ask the business system to install Echarts dependencies and then write the configuration in the old mode? Therefore, a chart of pure personalized configuration is also provided inside the public chart project, that is, components without any redundant encapsulation. The configuration information needs to be written by the business side, and components are directly called and generated without any processing. This way we still don’t need to manage dependencies and still only care about configuration.
Interface optimization and conventions
How to use a unified style of chart, which requires product, design and RESEARCH and development to discuss and make a good agreement, this is the cost of investment
Multiple chart library support
Last week in the company internal sharing, I was asked if we can support multiple libraries. It does not rule out the case that we need more than one library later, or some chart library does not support the function we want to use, so we have dealt with it in the code architecture configuration, which has supported the situation that more than three parties chart inventory, you can see the github warehouse for details.
Some of the issues that Iframe schemes might be teased about
- Blocking parent page loading: Since the use of iframes within a single-page framework mostly creates nodes within the framework’s own life cycle, it does not block the business itself
- Security issues: Because our chart project is self-written and a purely static resource with no interface input and no business, there is no value to attack
- Poor performance: Since the performance problems of Iframe itself are negligible in PC scenarios, and there are no more than 10 charts in an interface in most cases, even if there are more than 10, it will not cause lag. With the caching strategy, charts can actually load quickly
The code shown
When business code uses components, it only needs roughly the following code, without installing any dependencies
Warehouse demo
Dashiren. Cn/public – char…
The warehouse address
Github.com/zimv/public…
conclusion
Based on the problem we need to solve, we can choose either solution, but I just happen to prefer Iframe. From finding problems to solving problems, from putting forward ideas to implementation, the above is all content, I hope to bring you some inspiration, today’s share is here.