Mpx is an enhanced mini program framework that aims to improve the mini program development experience. With Mpx, we can develop deep production performance optimized mini programs with the most advanced Web development experience (Vue + Webpack). Mpx has the following excellent features:

• Data Response feature (Watch /computed)
• Enhanced template syntax (dynamic component/style binding/class name binding/inline event function/bidirectional binding, etc.)
• Deep performance tuning (native custom components/setData based on dependency collection and data changes)
• Webpack compilation (NPM/circular dependencies /Babel/ESLint/ CSS precompilation/code optimization, etc.)
• Single-file component development
• State Management (Vuex specification/multi-instance/mergable)
• Cross-team Packages
• Logic reuse capabilities (Mixins)
• Scaffold support
• Full support for the applet’s own specification
• Alipay small program support

Design ideas

At present, the mainstream small program frameworks in the industry mainly include WePY, MPvue and Taro, all of which translate other syntax specifications into small program syntax specifications, which are called translation frameworks. Unlike the above three, Mpx is an enhanced framework based on the applets syntax specification. We use the excellent syntax features of Vue to enhance the applets, rather than allowing users to develop applets directly using Vue syntax. This design is based on the following considerations:

• Translation frameworks do not support all the syntactic features of the source framework (such as dynamic features in the Vue template or dynamically generated JSX in React), and users may encounter unexpected errors and uncertainty when developing with the source framework syntax
• The technical specifications of small programs themselves are constantly updated and advanced. Many new technical specifications cannot be supported or require high support costs in the translation framework, while for the enhanced framework, as long as the new technical specifications do not conflict with the enhanced features, they can be directly supported

The technical implementation

When small programs were first launched, they did not support custom components, so they could not carry out componentized development. WePY and MPVue have done a series of work to support this key feature, greatly improving the user’s development experience and efficiency. Componentization support in WePY and MPvue is componentization encapsulation based on compilation. Component templates written by the user are compiled as part of the template in Page, data defined in the component is compiled as Page data, and data updates to the component are also called path-mapped to Page. This at the time of the technical conditions are great technical solution, but the scheme in complex small program application performance problems, the reason is that the amount of data that will be very big, the scenario page and each component’s local update actually will become the global update of the page level, more components in the page of a large performance overhead.

After the launch of the applets custom component, we confirmed through performance tests that the applets custom component supports partial updates at the component level and has good update performance. Since custom components were the latest technical standard at that time, no small program framework in the industry was supported, and we had complex small program development requirements in the business, so we started the design and development of the Mpx framework based on small program custom components.

Page vs. Component setData performance

Description of performance measurement standards: Local update: The document contains 1000 nodes. It takes 1000 times for one node to be updated. Global update: there are 5 nodes in the document, and the data of more than 1000 independent updates of 5 nodes is tested in the iPhone7 wechat small program environment

Data response and performance optimization

As the most core feature of Vue, data response is widely used in our daily development, which can greatly improve the front-end development experience and efficiency. In the early stage of framework design, the earliest consideration is how to add data response feature to small program development. For the implementation of data response, we introduced MobX, a well-known open source project that implements pure data response capabilities. With MobX and mixins, we built a responsive data management system in the early days of the applet component creation, which looked at all the data (data/props/computed) in the applet component and based on the setData of the change-driven view and the watch callbacks registered by the user. Implement the data response programming experience in Vue. At the same time, we implement a Vuex specification data management store based on MobX encapsulation, which can easily inject components for global data management. In order to improve the experience of cross-team development, we add the feature of multi-instance merging to store. Different teams maintain their own stores and can merge other or public stores to generate new store instances when needed. We think this is a more flexible and convenient cross-team data management mode than Modules in Vuex

As a data response development framework taking over the small program setData, we attach great importance to the rendering performance of Mpx. According to the performance optimization suggestions mentioned in the official documents of small programs, setData is the most important for the performance of small programs. There are two main directions for setData optimization:

1. Minimize the frequency of setData calls
2. Minimize the amount of data in a single setData transfer

In order to achieve the above two optimization directions, we did the following work:

• The static template of the component is compiled into the executable render function, and the template data dependency is collected by the Render function. Only when the dependent data in the Render function changes, the setData of the small program component will be triggered. At the same time, an asynchronous queue is used to ensure that setData will be performed at most once in a tick. This mechanism is very similar to Vue’s render mechanism, which greatly reduces the frequency of setData calls;
• During the process of compiling the render function from the template, we also recorded the output of the data path used in the template. Every time we need setData, we will diff the data based on these data paths and the data of the last time. Only the changed data will be setData through the data path. This ensures that the amount of data transmitted per setData is minimal and that unnecessary setData operations are avoided, further reducing the frequency of setData. Based on the above optimization, we have greatly reduced the frequency of calling small program setData and the amount of data passed, which is significantly better than the plan of tracking full data in the first version of Mpx.

Mpx setData optimization

The above data is obtained by the relatively complex small program after the fixed interaction process

Schematic diagram of Mpx data response mechanism

Compile build

We hope to use Webpack, the most powerful and ecologically perfect compilation and construction tool, to achieve the compilation and construction of small programs, so that users can get advanced and powerful engineering development experience in Web development. Those who have used Webpack know that Webpack generally packages a series of fragmented modules used in a project into one or several bundles, while the file structure required by small programs is very discrete. How to mediate the contradiction between the two has become our biggest problem. A very straightforward idea is to walk through the SRC directory and add each.mpx file to the Webpack as an entry. There are two main problems with this:

1. MPX files that are not used in the SRC directory will also be compiled and exported, and will eventually be packaged into the project package by small programs, meaninglessly increasing the package size.
2. For.mpx files under node_modules, we don’t think traversing node_modules is a good choice.

In the end, we adopted a method based on dependency analysis and dynamic entry addition for implementation. Users only need to configure an entry file app. MPX in Webpack configuration, and loader will parse the paths declared in the PAGES domain and usingComponents domain in JSON when parsing. Add these files to the Webpack build system by dynamically adding entries (note that this is adding entries, not dependencies, because only entries can generate separate files, satisfying the discretized file structure of the small program), and perform the process recursively. Until all used in the whole project. MPX file all join in, in front of the output, we use the CommonsChunkPlugin/SplitChunksPlugin ability to reuse module extraction into a bundle of external, to ensure that the resulting package does not contain duplicate module. We provide a Webpack plug-in and a.mpx file loader to do this. Users simply add it to the Webpack configuration to package small programs in the same way as they package Web projects. There are no pre and post operations to support the full ecosystem of Webpack itself.

Mpx compilation and construction mechanism process diagram

Current situation and Future

At present, THE Mpx framework has been widely used in Didi, supporting the implementation of didi Chuxing, Qingju Bicycle, Jietu motorcycle, marketing, car clothing and other businesses in small programs. The online operation is stable, and a lot of positive feedback has been received. In the future, we will continue to follow the latest technical standards of wechat and Alipay while continuing the iterative optimization of the framework, and at the same time will be adapted on more small program platforms. As our original intention and focus is to enhance the small program development experience, Mpx does not support cross-H5 or even cross-native, but such demands do exist in real business. In the future, we will make some attempts on cross-end based on Mpx. Meanwhile, we will continue to maintain and upgrade Mpx. Because cross-ends mean limited flexibility and lack of capability, we wanted to offer users a second option.

Mpx and the industry mainstream small program framework comparison

conclusion

If you focus on the development experience and product performance, and focus on small programs, then Mpx is a good choice. Finally, I would like to thank the open source community for a steady stream of excellent projects that have provided us with unlimited inspiration and great technical help.

Github: github.com/didi/mpx

Use documentation: didi.github. IO/MPX /

User communication: Click me into the group