By Hiyuki Dong

Mpx is an enhanced mini program framework dedicated to improving the development experience and efficiency of small programs. Currently, it supports the mini program ecosystem inside Didi, including Didi Chuxing Mini Program, Didi Chuxing Square Mini program, Qingju Bike, Dark Horse Motorcycle, Xiaoju Car Maintenance, Xiaoju Refueling, etc. Since the open source in November last year, Mpx has also absorbed many external developers to join, based on Mpx development drive away, good free street, flower memory and other small procedures.

For a long time, Mpx’s excellent development experience and strong stability have been unanimously recognized and praised by domestic and foreign developers, which is very in line with the original intention of Mpx design. But in the major manufacturers have launched their own small program platform, and each of the technical standards are not unified today, simply improve the development experience of a platform can not meet the appeal of the majority of small program developers, a set of code in the small program platform has become a realistic demand. In order to solve the pain point of small program development, Mpx released version 2.0, which ADAPTS all the small program platforms (wechat, Alipay, Baidu, Toutiao, QQ) that have been published in the industry at present, and provides the ability to directly compile and output the existing micro channel small program to other platforms.

New features in Mpx2.0 include:

  • Fully supports all the small program platforms (wechat, Alipay, Baidu, QQ, Toutiao) that have been published in the industry;
  • Mpx small program cross-platform development, support to compile and output the existing Mpx wechat project to run in other supported small program platform, click to view details;
  • Cross-platform compilation of native components of small programs, supporting the compilation and output of existing wechat native components to other supported small program platforms for running;
  • Deep subcontracting optimization, accurate judgment of subcontracting resources in the compilation process, all subcontracting only resources (components, JS, external styles, external templates, WXS, image media, etc.) will be accurately output to the subcontracting directory;
  • WXS module is fully supported in the render function, click on the render function to view details;
  • Native capabilities such as template introduction, inline WXS, custom Tabbar, independent subcontracting, Workers, cloud development are supported to further improve native compatibility.

Compared with the mainstream small program cross-end framework in the industry, Mpx focuses more on small program development itself, and has the following advantages in small program development:

  • Enhancements based on the technical standards of the applets themselves, without heavy DSL conversions, will encounter fewer pits during development;
  • Fully compatible with native applets technical specifications, 0 cost migration native applets project;
  • Cross-platform development aims to cross small program platforms, and most of the differences are smoothen at compile stage, which greatly reduces the package volume increased by adaptation layer at run time.
  • Support the industry wechat small program component library (such as Vant, iView, etc.) to directly convert to other small program platform operation;
  • Great emphasis is placed on small program performance, providing deep setData and package volume optimization.

A more detailed introduction to Mpx can be found in the official documentation and this article.

Github：github.com/didi/mpx

Cross-platform development

As a core capability of version 2.0, Mpx’s cross-platform development capability allows users to directly compile and export existing applets to other supported applets platforms. As the proposer of the concept of applets, wechat applets have the most extensive ecological coverage, so we give priority to supporting the ability to compile wechat applets into other platform applets. Based on this capability, users can not only compile wechat Mpx project cross-platform, but also compile wechat’s native custom components to other small program platforms for running, which means that our cross-platform project can directly use some existing UI component library ecology in the community (such as Vant, iView, etc.). This greatly increases the scope of cross-platform development.

Design concept

The core design concept of Mpx framework is enhancement. Enhancement refers to the addition of the existing native capabilities of small programs to expand the development capabilities of small programs and improve the development experience and efficiency of small programs. This design philosophy gives Mpx greater certainty and predictability to developers, and lower learning and debugging costs. Based on this concept, Mpx has different enhancement adaptation in different applets, and provides different enhancement template instruction set according to the template instruction style of each platform, so that users in each applets can use the platform’s native capabilities in an enhanced way to the maximum.

We also follow the core design philosophy of enhancement in supporting THE cross-platform capabilities of Mpx. To put it simply, the cross-platform capability of Mpx is based on the multi-platform capability, adding a conversion layer during compilation and runtime. After the source platform code is converted to the target platform code, it is enhanced according to the existing target platform processing logic. At the same time, we also provide a set of perfect conditional compilation mechanism. Let the user implement the few things that the framework cannot transform.

Schematic diagram of Mpx cross-platform development process

The design idea of Mpx cross-platform capability is obviously different from other existing small program cross-platform frameworks in the industry. The main differences are as follows:

  • Mpx is based on the DSL of the applets themselves, rather than the DSL using the React (Vue) Web framework;
  • Mpx deals with platform differences primarily through compilation and runtime transformation, without providing additional differential-smoothing layers (base component libraries, etc.).

This design was adopted for the following reasons:

  • Mpx mainly aims to cross small program platforms. Currently, there are some similarities in the technical specifications of various program platforms. Most of the platform differences can be smoothen by compilation and run-time means, and the saved difference smoothing layer can further reduce the framework run-time volume.
  • The use of the applets’ own DSL as a benchmark allows users to use cross-platform capabilities directly in existing projects, as well as cross-platform outputs for native applets’ projects or components;
  • Combined with perfect conditional compilation support, this solution can satisfy users’ cross-platform needs while still allowing users to maximize the capabilities provided by each applets platform, fully continuing the core design philosophy of Mpx enhancement.

Method of use

The use of Mpx cross-platform development is very simple. Users only need to specify the source platform and target platform by passing in mode and srcMode parameters when MpxWebpackPlugin is created. When srcMode and mode are inconsistent, the framework will read the corresponding configuration to compile and convert the project at run time.

// Transfer from wechat to Alipay
new MpxWebpackPlugin({
  / / mode to specify the target platform, optional values are (wx | ali | swan | | qq tt)
  mode: 'ali'.// srcMode specifies the source platform. The default is the same as the target platform
  srcMode: 'wx' 
})
Copy the code

Difference of screeding

At present, the small program technical specifications of major manufacturers are generally consistent at the macro level, but there are many differences in technical details, which can be roughly divided into the following parts:

  • Template syntax/base component differences
  • Json Configuration Differences
  • WXS syntax differences
  • Page/component object differences
  • API call differences
  • The webview bridge differences

Among them, static differences in template syntax/basic components, JSON configuration and WXS are mainly converted by means of compilation. Errors will be reported in the compilation phase for those differences that cannot be converted. As for the differences between page/component objects, API calls and JS runtime in WebView Bridge, we mainly deal with them through runtime means, and the corresponding parts that cannot be converted will also be pointed out in the runtime error.

It is important to note that we do in our cross-platform conversion is not only a technical standard of convertible conversion mapping, for some of the target platform, ability does not exist in the us also means as much as possible through the compiler and runtime provides simulation and support, minimize the user need to pay the extra workload in the cross-platform development. Taking wechat to Alipay, which has the largest difference but the most realistic scenarios, as an example, Mpx simulation provides many capabilities supported by wechat but not supported by Alipay:

  • Component custom events
  • Intercomponent relationship
  • Gets the child component instance
  • observers/property observer
  • Inline WXS
  • External style classes

For the cross-platform conversion of native custom components, we provide a simple runtime injection to enable them to use the runtime transformation capabilities provided by the Mpx framework.

Conditional compilation

For the differences that cannot be erased by the framework, errors will be pointed out during compilation and operation. For these errors, we provide a perfect conditional compilation mechanism so that users can write patches of target platforms to repair them, and this capability can also be used to realize business logic with platform differences.

As mentioned above, Mpx decides whether and how to convert the project by reading mode and srcMode passed in by users. Mode and srcMode represent the target platform and source platform of the whole project construction respectively. Conditional compilation enables users to create files and code blocks in a project that declare their platform attributes (localSrcMode). In project construction, the framework will preferentially load files and code blocks with the localSrcMode declaration that matches the target platform of the project (localSrcMode===mode). These files and code blocks should be written according to the platform standard declared by the framework. Mpx does not do any compile and runtime cross-platform conversions.

Mpx provides conditional compilation in three dimensions: file dimension, block dimension, and code dimension, which users can use flexibly depending on the coverage of platform differences.

Performance optimization

The Mpx framework focuses on small program development, and we have made a lot of attempts and efforts to optimize performance, mainly in two areas:

  • SetData optimization at runtime
  • Package volume optimization at build time

SetData optimization

Data response is the core capability of the Mpx runtime enhancement, which enables users to use Watch and computed features in applets as in Vue, and to operate data-driven view updates with direct assignment rather than manually calling setData methods. In other words, the framework takes over setData calls in the applet.

Through the design principles and performance optimization suggestions of various program platforms, it can be known that setData is very important for the performance of small programs, and the two general directions of setData optimization are:

  • Minimize the frequency of setData calls
  • Minimize the amount of data transmitted in a single setData transmission

In order to realize the optimization of setData, we generate a render function for the template of each component in the template compilation process, which simulates the rendering logic of the template, accesses the data required for the next rendering during each execution, and records the data path visited for the next time as the function return value.

At runtime, the framework creates a Render Watcher at each component creation. This watcher tracks the render function, executes the render function asynchronously when the render dependency data changes, and gets the data path returned by the render Watcher in the render Watcher callback. Diff comparison is made between these paths and the last cached data, and the minimum necessary data is obtained after the unchanged data is filtered out. Finally, setData is called to send the minimum necessary data to the real applet rendering layer to update the view.

Based on this mechanism, when data changes, only the part of data that the current rendering depends on changes will trigger the execution of the Render Watcher asynchronously, and only the part of data that has actually changed will be sent to the rendering layer by setData after each execution. In this way, users can operate data freely according to business needs without paying attention to setData call optimization. The framework can automatically make the optimal setData call in the program, which not only improves user development experience but also improves program performance.

In version 1.x, WXS logic could not be executed in rendering functions, and components containing WXS might be degraded to the mode of full set data. In version 2.0, we translated WXS modules into JS executable codes and injected them into JS bundles. Rendering functions containing WXS could also access and execute WXS logic normally.

SetData optimization schematic diagram

Package volume optimization

Similar to the run-time takeover of setData, Mpx takes over the resource management of the project at compile time. Thanks to the powerful plug-in mechanism of Webpack, Mpx developed a deeply customized Webpack plug-in to complete the packaging and construction of small programs based on Webpack. Users can develop applets using Mpx with unrestricted access to modern Web development capabilities such as NPM dependencies, the latest ES features, and CSS preprocessors. At the same time, Mpx has done a lot of work on package volume optimization, which allows users to focus on business development without having to spend too much time on package volume management. Here’s what we’ve done:

  • The packaged build effort is based entirely on dependency analysis, and any resources that are not referenced will not appear in DIST;
  • The construction of NPM components and pages is completely packaged on demand based on dependency analysis, without copy of the entire miniprogram_dist directory, and without the need to build NPM. The user experience and package volume are better than the NPM support scheme of wechat small programs themselves.
  • Optimize common module extraction and code compression based on webpack capabilities;
  • Perfect subcontracting support, subordinate analysis of all resources, output all subcontracting only resources to subcontracting directory.

Subcontracting, as the core means of optimizing package volume in wechat mini program (similar to asynchronous loading on demand), has been fully supported by Mpx. In order to accurately mark resources for subcontracting only, we split the dependency collection steps for the main package and subcontracting into serial processing at build time, processing the main package first and then the subcontracting. In the main package during processing, the main package page referenced in all non js resources (components, external style, external templates, WXS, image media, etc.) are recorded, when dealing with the subcontract, for reference of the subcontract the js resources are checked, if be cited the main package will be output to the main package, or tag to the subcontract only output to subcontract directory of resources.

For JS module resources, we provide an auxiliary function in the build configuration generated in the scaffold to facilitate the configuration of the subcontracted bundle. After this configuration, the public module subcontracted only will be exported to the subcontracted bundle directory, and the other public modules will be normally added to the main bundle.

In cross-platform development, we recommend that users define subcontracting using mpX-provided packages so that when switching to applets that do not support subcontracting, they are automatically demoted to synchronous packages.

Schematic diagram of subcontracting construction

Gradual migration

Mpx provides good incremental migration support, and for developers using native or other applets frameworks, it is not expensive to gradually introduce Mpx in an incremental way.

In version 2.0, we further improved the native compatibility of Mpx, followed up with the latest technical capabilities of various applets, such as custom Tabbar, independent subcontract, subcontract preloading, workers, cloud development, etc., and made up for some of the missing support in version 1.x. Thanks to this, is to use native small program developed by developers, the migration of Mpx costs almost to zero, the user only need to replace the corresponding page component constructor for Mpx createPage/createCompnent, can use Mpx provides various enhance ability.

For developers using other frameworks, Mpx also provides a local build mechanism that allows users to build output from specific pages and components separately into native components that can be integrated into the original project either manually or by scripting the output.

The future planning

As the infrastructure of didi’s mini program ecosystem, we will maintain and update the Mpx framework for a long time to ensure that the latest technology features of each mini program platform are supported at the first time. At the same time, we will further improve the basic capabilities of the framework, which are currently on the agenda to be supported, including:

  • i18n
  • Ts support
  • Unit test support

In terms of cross-platform capabilities, we will continue to improve and update the miniprogram based on community feedback and suggestions, as well as the standardization process.

Finally, if you’re focused on small programs, the development experience, and product performance, then Mpx is your best bet.