How to develop a plug-in (stamp here) is not too much to explain and relatively simple. However, when the business system needs to be operated by multiple plug-ins, how to deal with the relationship between plug-ins and plug-ins, how to deal with the relationship between plug-ins and small programs, once the number of plug-ins increases, the research and development system will become extremely complicated. When the plug-in model is often used to do business support, each plug-in development may be behind a department, or a company, so cross-team or cross-enterprise collaborative development is very difficult.

How to plug-in small program

Plug-in development is very similar to applets development in that the code of applets can be ported directly into plug-ins, with only a few points to note in development:

  1. Take a closer look at the API limitations of the plug-in.
  2. Licensing related needs to use the plug-in function page, with applets developed together.
  3. Development mode uses plug-in development mode instead of applets development mode.
  4. Plug-in review requires development documentation.

(Note: documentation is very important, and the community not mentioned is also explained, as long as it is a small program on the business, there must be a way to achieve in the plug-in)

Basic specifications for multi-plug-in access

Why do we need to set the basic specification of the plug-in, that is, the plug-in access requirements (this content, is often small programs will have requirements).

Volume 1.

First of all, it is important problem of “volume”, the small size limit is 20 MB, at the same time limit is 2 MB each subcontractor, the volume of a plug-in is calculated to each reference to package, so the plugin volume must be within 2 MB (minimum), but often we have to be preset in the late development plan, small program will reach the limit, And the upper limit for the size of the plug-in, as well as the expected number of plug-in connections. Also need to consider is that if the plug-in is in the form of a component access, then generally put in the main package, then the volume of the component plug-in must be well limited, it is recommended to connect to the main package plug-in within 100KB as far as possible.

Parameters of 2.

Then need to define the main program made available to the plug-in “argument list”, generally need to contain data with appId, mobile, openId, timestamp, signs and debug, contains the user information and encryption signature, switch and the environment (note: Because it involves tuning multiple plug-ins, the environment switch needs to be changed to runtime, which is important).

3. The basic library

Then we also need to define the modality base library version, currently recommended at 2.11.1.

4. Version update

[XXX plug-in name] [Version number] 1.0.2a: New XXXXXX function F: repair defects of XXXXXX U: update and optimize XXXXX flow U: update and optimize XXXXX flowCopy the code

(Note: there are of course more specifications to define, including server-side interface specifications, pressure requirements, account synchronization processes, orders, etc.)

Allocation of plug-in function modules

First of all, if there is a plug-in component in the main package, in order to ensure the size of the main package and the first loading experience, we can move the secondary content in the plug-in component to the subcontract plug-in. In principle, we can make sure that the main package is as small as possible.

Then, if for business reasons, we have the concept of main plug-in and sub-plug-in, then we can expose some basic capabilities in the main plug-in, such as login authorization, user information, network request, data statistics and other basic functions, thus reducing the size of the total plug-in.

If the plug-ins are completely unrelated, they can only manage their own, but the same main program can expose some basic functions, such as encryption and decryption libraries, routing processing, and so on.

Basic ability expansion of plug-ins

There are some basic capability limitations in the plug-in, so you can extend the plug-in through the small program Bridge. The scheme diagram is as follows:

Plug-ins interact with each other

The interaction between plug-ins is as well documented as jumping to other plug-in pages, loading other plug-in components, and calling other plug-in methods. It is suggested that a message communication object can be exposed, and multiple plug-ins can share message communication (EventEmitter can be used), as follows:

const xxPlugin = requirePlugin('xxPlugin') // Get the exposed object of the xx plug-in

xxPlugin.EventEmitter.off('getUserInfo') // Remove the repeat listener
xxPlugin.EventEmitter.on('getUserInfo'.() = > {
  xxPlugin.EventEmitter.emit('setUserInfo', {
    mobile: 'xxxx',})})Copy the code

NavigateTo (wx. NavigateTo, wX. NavigateTo, wX. NavigateTo, WX. When you use a Bridge in a plug-in, you may encounter limitations on the WX scope. You can bind the WX scope when the plug-in calls the Bridge.

Syndication mode between multiple plug-ins

When developing a plug-in, you can debug a single plug-in in plug-in development mode. However, if multiple plug-ins are involved and need to be coordinated, you can only load multiple plug-ins for testing in small program mode. You can integrate into the development version of the main program for integration testing by providing a plug-in development version number. The ability to switch between run-time environments becomes very important, so that the same code can be used to debug the formal and test environments without having to package them frequently.

It is worth mentioning that in multi-team development, plug-in developers often do not have the development authority of small programs, so they cannot achieve rapid integration debugging and modification. It is recommended that each plug-in developer develop a model small program, keep the running environment consistent with the main program, can greatly improve the development and debugging time.

The story of R&D

One day, I suddenly received a demand from the boss, saying that we need to quickly access all our business into a small program of a big factory. It is very important and urgent. Ok, let’s do it. The big factory has put forward a lot of requirements to access it in the form of small program plug-ins. Ok, let’s look at a wave of documents first. After initial contact and communication, I was deeply impressed by the large factory’s requirements and standardization, which was indeed much higher than our daily acceptance standards.

After many heated discussions, we decided to divide all business modules into three plug-ins for the access party in the first phase of requirements. Why split into three? Don’t give it a second thought. In the early stage, architecture was not considered too much, and there was no special reason. Because there were too many business contents, all the codes were placed in the same plug-in, which could not be put down completely, so they were divided into three according to business. Because of the demand, our home plug-in needs to be in the form of components, into the small program home page, the other two are separate plug-in business. Often contact with new content, early development is to read the document, when reading the requirements of the document, it seems to see that the size of the home plug-in must be limited to 500KB (cry, read wrong, in fact, the real requirement is 100KB), so we plan to put heavy business in the rest of the plug-in, as far as possible to make the home plug-in light. After understanding the general content, go to go to go…

After several days of hard work, the content of the three plug-ins has been basically developed, so the question is, how do we ensure that the interaction between the plug-ins is stable? Is it enough if it’s theoretically possible? After some thinking, let’s do a small test program, so easy. After a few operations, we loaded all three of our plugins, but found that the preview did not work and the size was severely over the limit. So again, each plug-in is made into a separate subcontract introduction. In fact, there were some strange points in the operation process. Obviously, the size of the single plug-in uploaded did not exceed 2MB, but when the preview after integration showed that the size of the plug-in exceeded 2MB. At that time, there was no in-depth study, which might be caused by the difference between the compiled code and the code amount at runtime.

When the delivery time came, we provided the plug-in development version number to big factory r&d and made the first connection. Unfortunately, it didn’t run at all. After investigation, there were several main problems. First of all, our home page plug-in was too big, and the main package set could not be completed. Then, the internal logic of our plug-in refers to each other and the plug-in name introduced by the small program is different, leading to the failure of the call. After some intense manipulation, we agreed on naming conventions for plug-in names, method names, parameter names, and so on. Then we also found that in the business module, because of the need to authorize the payment operation, then because of the plug-in’s permission limit, the plug-in function page (this in the development environment, need to load the development version of the small program in advance) is needed, so it is another operation, add the development permission to the relevant personnel. Of course, there are countless minor problems that can be ignored.

In the acceptance process, because the test standards of the big manufacturers are higher, various points need to be optimized are frequently fed back (this must be PUA). But then we found out that we really need to set the bar a little higher, otherwise all the small problems will be magnified by the high volume of traffic. Rather than waiting for user feedback, it’s better to address it early in the development phase.

It wasn’t until the project came online that we were able to breathe a sigh of relief. In the middle of this does optimize a lot of details, but the income is also considerable, according to the statistics at the beginning of the gray line during the flow of the whole small program in 300W+, so after the full opening is predicted to reach the level of 100 million, the same part of the flow scattered into the business content of each plug-in is relatively considerable. With such a high volume of traffic, what we need to do is make the experience better in later iterations and make the project more stable.

It is worth mentioning that in the later iterations, other business plug-in access parties also received small programs. Of course, we do not know what the plug-in architecture system behind them is, but from the development cycle, it can be reflected that our research and development efficiency is at least three times more than that. Maybe we are not much different in the technical implementation of plug-in development, but when it comes to the process and engineering of the whole plug-in research and development, it may be very different. We did spend a lot of time thinking about how we could iterate faster, how we could make projects more stable, how we could make development work less overtime.