Gong Cheng, commonly used ID: Gcaufy, author of small program open source framework WePY, loves technology and open source. Joined Tencent in 2015, responsible for the development of Tencent mobile phone recharge related businesses. In 2018, I joined wechat Pay and was responsible for the development of small programs of wechat Pay merchant side business.
The introduction
Although this subject has been covered many times elsewhere, there is still much that is new. Because a lot of things are being done or want to be done. This sharing is mainly divided into the following parts:
The introduction of WePY
WePY user
The WePY users shown above are not the complete data. Since there is no way for WePY users to actively report their use of WePY, I have listed only the companies I know that use WePY, so the data is limited.
As far as I know, there is a small program called Tencent Vaccine, which is popular in friends circle recently. The front end uses WePY, and the back end uses TARS project, which is open source of Tencent. Wechat Pay also has a large number of small programs using the WePY framework.
The chat logs posted on the right are the feedback I collected from users in the WePY group. Judging from the feedback, there are many words of thanks, which show that the WePY framework can really help developers improve their development efficiency. Heh heh, I didn’t post any negative feedback from WePY because I was worried that one PPT page would not be enough to post 👀.
WePY data
The WePY project now has over 13,900 stars on Github. Compared with other front-end frameworks, Vue, React and other Star numbers may reach 10W+, but they are all international projects. Due to the micro program of wechat, WePY is a domestic project. It is quite good to have more than 13,000 stars. A high number of stars does not necessarily mean that WePY is a good framework, but it does mean that there is a lot of traffic in the small program area and that developing small programs is very promising. Developers need frameworks like WePY to help. That’s why Taro, MPvue, and other such excellent frameworks came along.
There are currently more than 1,300 issues. That means I wake up every day with more than 10 To-Do lists to deal with. Plus there are other things I have to deal with in the company every day.
Pull Requests currently number more than 320. That’s a pretty good AMOUNT of PR compared to other open source projects, and many thanks to the developers who contributed to WePY.
There are over 4000 users. The source of this data is my statistics. I set up a WePY communication group, which currently has more than 4000 people.
What is WePY
Compare a Web App to an applet. Web App and small program are similar in function. During the development of Web App, vue. js may be used as its core library and packaged with Webpack. In wechat small program, we can simply understand WePY as the combination of vue. js + Webpack in Web App.
The characteristics of WePY
What exactly does WePY help developers with their development? What are the features of WePY?
- Scaffolding: It provides the equivalent of vue-CLI scaffolding, generating simple demo projects with one line of command. Users can develop based on this demo, eliminating tedious configuration before starting the project.
- Compile packaging: Native development applets are missing many capabilities, such as LESS and SASS. Many users face this problem by doing a simple Gulp compilation. WePY has its own compilation and packaging ability. If you want to use LESS, SASS, NPM and so on, you can directly use WePY’s packaging tools to output the code that the small program can run.
- Core libraries: Core libraries are similar to Vue and React. The WePY core library contains some simple API packages to help with some things.
- Features and optimizations: In terms of development, WePY provides some syntactic sugar, which can easily implement some complex functions. In terms of performance, the applets themselves have some performance issues, and WePY smoothen the performance issues so developers don’t have to worry about performance.
- Reuse and extension: reuse, native small programs using NPM resources need to download and put the corresponding resources into the code directory, using WePY can directly install NPM package and use. Extension, in the compilation process, you can add and extend the compilation means, such as LESS, SASS, compiled plug-ins, etc.
- Multiterminal: With WePY, you can run a piece of code in applets, H5, and so on.
WePY planning
In August 2016, I took part in the internal test of small programs and started the work related to code conversion in October. In constant iteration, I found there was a lot more I could do. For example, the related work can be abstracted and provided to other developers. So in November, I refactored the code, discarded the Gulp compilation and rewrote it and opened it to Github 1.1.
Since open source, many people have paid attention to this project, indicating that many people have encountered corresponding problems. Therefore, I made more specific optimization, and reconstructed the compilation process again in version 1.1, and put forward two concepts of compiler and plug-in, which are convenient for users to extend.
Version 1.4 was released in January 2017, which added more optimizations to the overall development process and the experience of developers using the framework, including performance optimizations.
Version 1.6 began to consider the multiterminal problem: the multiterminal reuse of a set of code by applets.
Around November 17, Miniprogram launched native components. WePY itself was designed to solve the problem of small program components. After the native components were released, the usage scenarios for WePY were not as strong as before, so I began to think that a fully refactorized version of WePY was needed.
This refactoring was launched in February 2018. It is a new refactoring to solve problems related to native components of applets. But for various reasons, this version has not been officially released. Stay tuned!
How WePY works
I’m going to talk about how WePY is implemented technically.
WePY solves the problem
- Componentized development: Before the advent of native components for small programs, there was no good componentized development model for small programs. For example, if I implement a set of dialogs myself, someone else may have to make a copy of my code if they want to use it. Once COMPONentized, ALL I have to do is give it to him.
- NPM resources: Since the development of the Web, there are a lot of resources on the NPM library. But native applets don’t have the ability to use NPM resources, which WePY provides.
- Front-end engineering: The package build part mentioned earlier
- Performance optimization
- Friendly development experience: Experience optimization
- Cross-platform support: multi-terminal part
In general, WePY addresses the pain points of development.
WePY architecture
Above are the sections I wrote for the two cores: THE CLI and Core. Core is compiled through the CLI to generate code that runs on the applet side. CLI is divided into WEpy and Wepy-Web, which are responsible for wepy compilation and Wepy-Web compilation respectively. It is divided into compiler and plug-in two parts, compiler involves the current mainstream preprocessor, similar to Webpack loader. Plug-ins are things to do after compilation, similar to Webpack plugins. Core is divided into WEPY Core library, small program Core library and Wepy – Web Core library. Wepy – The Web core library has more Wepy Components and WEpy apis than applets. Some of the built-in components of the applets themselves, such as popovers, need to be wrapped in Wepy Components if they want to run multiple times. The applets native API needs to be wrapped through the WEpy API.
Web itself is also divided into many platform types, such as browser, wechat H5, QQ H5, these need to be adapted respectively, so wepy- Web is an adaptation layer.
On top of Core, there are user-wrapped components, such as reporting and asynchrony. There are also features such as user-made pop-ups, Toast, Imageloader, etc.
Throughout WePY, my code will output code that runs on the applet side through the CLI based on Core.
WePY compilation process
That’s how WePY builds.
Multifaceted implementation
In terms of multi-terminal implementation, the following problems are faced:
-
Development mode
The applets development model is in its own right, different from existing development models. Fortunately, WePY uses a VUe-like development syntax, which is very close to the Vue development pattern, so development pattern problems are very easy to solve with WePY.
-
Labels and Styles
Small program and H5 tag is not the same, but can directly do some simple conversion processing. For example,
converts to. The style applet has one RPX unit and converts RPX to PX directly /2 at 750 px. -
Template syntax
Applets have their own template syntax, such as < wX-if >, etc., parsing can do simple conversion.
-
modular
Small programs can use require natively, but H5 cannot. Fortunately, there are plenty of tools to learn from, such as WebPack and Browserify.
-
Built-in components and built-in apis
WePY itself uses vUe-like syntax, and to convert to Vue running on the Web side, the built-in components are written directly in Vue form and imported directly into the Vue component when used. The built-in API uses the JSSDK provided by WePY to simulate the API provided by wechat terminal and H5.
Therefore, multi-terminal implementation is completely feasible. Some of our projects fully utilize WePY for multi-terminal implementation.
ecological
On the left are some UI libraries on Github that you can use directly for secondary development while using WePY. On the right are development resources collected online, including development components, third-party modules, etc. Github has over 900 pages of WePY keyword results. According to user feedback, one of the reasons for users to choose WePY is that WePY has a long history and a relatively perfect ecology.
WePY planning
The existing problems in
The core problem with WePY right now is this
-
Static component compilation
The WePY project was rushed and took about a month to launch. It started out as a solution to the componentization problem. So it uses static component compilation, and when it compiles components, it simply statically replaces the components I wrote, injects the components I wrote into the page, and does some isolation related things. This leads to serious bugs in dynamic repeats. This is a design flaw that needs to be addressed.
-
Syntax parsing
XML is parsed using a problematic library, resulting in frequent errors in XML parsing. Js parsing is not designed to use the syntax tree parsing, but to use the re parsing. At present, only parsing and syntax injection are involved, which are relatively simple to implement, so the AST syntax tree is not considered for parsing, resulting in some code that is not written in accordance with the specification will have errors in parsing.
-
Class Vue grammar
From user feedback, people prefer to use Vue syntax rather than vUe-like syntax. There are some differences between the two.
-
Data binding performance optimization
Some optimizations and processing have been done in data binding. But these optimizations and processes are done with dirty data to help users reduce the number of setdates. But in hindsight, there’s still room for improvement.
-
Error handling mechanism
At present WePY error handling is relatively simple, there is no general error handling mechanism. Errors reported by users during use and compilation are difficult to trace and locate. I hope to be able to locate the file and code that reported the error.
-
Test case coverage
WePY currently has only the core library covered by test cases. The CLI part is too complex to do test case coverage. As a result, most of the current problems are CLI-related. The next version will be fully covered by test cases.
compile
Above is a comparison of the version 2.0 compilation. On the left is compilation for 1.0, and on the right is what 2.0 is doing. As mentioned earlier, the 1.0 compilation is to put the.wpy file into the CLI for compilation. The CLI itself involves compilers and plug-ins. In 2.0, file compilation will be changed to portal compilation, from App portal, dependencies will be resolved automatically through CLI, CLI also only plug-ins, all core functions will be implemented through plug-ins. Finally, in addition to the applets, there are Vendor files (which means that all NPM packages are packaged into this file), resource files, and files for the modules they reference.
pluggable
The core part of compilation is plug-in compilation by referring to Webpack. The concept of plugins refers to the diagram I made above: a fixed board with a fixed number of hooks, each of which can hang different things. It’s not clear what each hook puts in it, but each hook can do different things. I just specify the compilation process and implement the entire compilation process by writing different things in the hooks. So the entire compilation process becomes: configure initialization ➡️ core compilation ➡️ output file.
Plug-ins provide greater extensibility and reusability. All core functions rely on plug-ins. When users feel that a feature is not suitable, they can write a plug-in to replace the core function. Users can modify any part of the compilation.
Data binding V1
V1 data binding: back up data with a deep copy during initialization. For example, there is a click event, which modifies the data and enters the Apply process. Dirty data is obtained by deep comparison in the Apply process, and the dirty data is finally entered into setDate.
The picture on the right is relatively simple and easy to understand: Xiao Ming modified file B to get B+, and the teacher compared B+ and B to get the modified data. This is a synchronous process. When Xiao Ming asks Xiao Hong to modify C file, if the teacher is no longer available, Xiao Hong needs to take the initiative to ask the teacher to compare C file. That is, manually invoke the Apply process.
Data binding V2
Vue’s data binding mechanism is used in 2.0. Render Watcher is generated at initialization, and observers are added at each data initialization. When data is modified, the modified key-path is recorded and queued. All modification actions trigger Watcher. In a nextTick time the queue is emptied and setDate is performed in Render Watcher. The setDate segment sets the date according to the key-path of the record.
Compared with the story of Xiao Ming and his teacher, Xiao Ming would take the initiative to record the modified content and initiate notification when modifying files. Xiao Hong’s operation mode is consistent with Xiao Ming’s. When the teacher receives the notice, according to xiao Ming and Xiao Hong’s modification record, the content of the modification will be setDate processing.
This optimization does not require a manual call to Apply, nor does it concern the asynchronous process.
The quality of
The second version will first be used in internal projects, and then open source after internal practice. In addition, version 2.0 test case coverage should be fully covered.
Open Source experience sharing
specification
How to ensure the quality of open source projects?
The first is documentation specification. The Readme section is a brief description of what the project can do and a simple example of how to start the project. Readme should be simple so that everyone can see what he wants at a glance.
The second is CI. Putting the corresponding status on the Readme makes it easier for developers to use the project.
The third is the license.
There are contributer documentation, code specifications, Git specifications, and more.
Mocha and Istanbul were used for testing, TravisCI for integration, and NPM and LerNA for deployment.
Promote operation
Promotion and operation mainly rely on their own articles, do outside the chain. In addition, I tweeted my own articles on the official account and wechat group. Wechat group made a robot into the group code.
I have also done document monitoring. After the official documents are modified, I can immediately know what has been modified in the official documents. As well as the monitoring report, I will push the number of stars and issues of today’s project to my wechat every day.
The late maintenance
Post maintenance mainly includes document, issue, PR and new plan maintenance. In the picture on the right, the gray part is the issue that I did not label. The following closed is the issue that I have processed at the corresponding time point. If the issue is not closed, it indicates that it is still being processed.
WePY 2.0 is currently in private beta and will be released in public beta at the end of October.