In some cases, developers need to divide the Mini App into different subpackages, package them into different subpackages at build time, and load them on demand when they are used.

When you build a Mini App subpackage project, the build outputs one or more subcontracts. Each MiniApp that uses a subpackage must contain a master package. The so-called main package, that is, the default startup page/TabBar page is placed, and some all subcontracts require the use of common resources/JS scripts; Subcontracting, on the other hand, is divided according to the developer's configuration.

When the Mini App starts, the main package is downloaded by default and the page in the main package is started, and when the user enters a page in the subpackage, the client will download the corresponding subpackage and display it after the download is completed

1. Use subcontracting

1.1 Configuration Method

Suppose the directory structure of a Mini App that supports subcontracting is as follows:

The developer declares the project subcontracting structure by subpackages field in the app.json subpackages field:

In subpackages, each subpack is configured with the following:

Field	Type	Description
root	String	The subcontracting root directory
name	String	A subpackage alias that can use
pages	StringArray	The path of the package page, relative to the
independent	Boolean	Whether the subcontract is a standalone subcontract

1.2 Packaging Principles

• After subpackages are declared, they are packaged according to the subpackages configuration path, and directories outside the subpackages configuration path are packaged into the main package
• The main package can also have its own pages, i.e. the outermost pages field.
• The root directory of the subpackage cannot be a subdirectory within another subpackage
• The tabBar page must be in the main package

1.3 Citation Principles

• packageA cannot require packageB JS files, but can require JS files within the main package, packageA;
• packageA cannot import packageB's template, but can require templates within the main package, packageA
• packageA cannot use packageB's resources, but can use resources within the main package, packageA

2. Independent subcontracting

Stand-alone subcontracting is a special type of subcontracting in a Mini App that can run independently of the main package and other sub-packages. When entering the MiniApp from the standalone subpackage page, you do not need to download the main package. The main package will not be downloaded until the user enters the normal subpackage or the main package page.

Developers can configure certain pages with some functional independence into standalone subpackages as needed. When the Mini App is launched from the ordinary sub-package page, you need to download the main package first; Standalone subcontracting can run without relying on the main package, which can greatly improve the startup speed of the subcontracting page.

There can be multiple independent subcontracts in a Mini App.

2.1 Configuration Method

Suppose the Mini App directory structure is as follows:

The developer declares the corresponding subpack as a standalone by defining the 'independent' field in the 'subpackages' field corresponding to the 'subpackages' field in 'app.json'.

2.2 Limitations

Stand-alone subcontracting is a type of subcontracting. All restrictions of normal subcontracting are in effect for standalone subcontracting. Plug-ins and custom components in stand-alone subcontracting are handled in the same way as ordinary subcontracting.

Also, when using standalone subcontracting, be aware of:

• Standalone subpackages cannot rely on the contents of the main package and other sub-packages, including js files, templates, ftss, custom components, plug-ins, etc. (js files, custom components, and plug-ins are not subject to this restriction when using subcontracting asynchrony).
• App.ftss in the main package are not valid for standalone subpackages, and you should avoid using styles from app.fts in the standalone subpackage page;
• Apps can only be defined in the main package, and apps cannot be defined in separate subcontracts, resulting in unpredictable behavior;
• The use of plugins is not currently supported in standalone subcontracting.

2.3 Notes

2.3.1 About getApp()

Unlike normal subcontracting, when a standalone subcontracting runs, the app is not necessarily registered, so getApp() does not necessarily have access to the app object:

• When the user starts the Mini App from the standalone subpackage page, the main package does not exist, the App does not exist, and the call getApp() gets undefined. When the user enters the normal sub-package or the main package page, the main package will be downloaded and the app will be registered.
• When the user jumps from a normal package or a page within the main package to a standalone package page, the main package already exists, and the real app can be obtained by calling getApp().

Because of this limitation, developers cannot implement independent subcontracting and global variable sharing for other parts of the Mini App through app objects.

Returns a default implementation when the app is undefined. When the main package is loaded and the app is registered, the properties defined in the default implementation are overwritten and merged into the real app.

Sample Code:

• Independent subcontracting

• In app .js

2.3.2 about the app lifecycle

When you start a Mini App from a standalone subpackage, the 'onLaunch' and the first 'onShow' of the App in the main package are called the first time you enter the main package or other normal subpackage page from the standalone subpackage page.

Since apps cannot be defined in standalone subcontracts, listening for the Mini App lifecycle can be done using 'ft.onAppShow', 'ft.onAppHide'. Other events on the app can be listened to using 'ft.onError', 'ft.onPageNotFound'.

3. Sub-package pre-download

Developers can configure the possible subpackages that may be pre-downloaded by the framework when entering a page of the Mini App, so as to improve the startup speed when entering the subsequent subpackage page. For stand-alone subcontracting, you can also pre-download the main package.

Sub-package pre-download is currently only supported for use by configuration, and is not supported for completion by calling APIs.

3.1 Configuration method

The pre-downloading subpacking behavior is triggered when a page is entered and is controlled by adding a 'preloadRule' configuration to 'app.json'.

In 'preloadRule', 'key' is the page path and 'value' is the pre-download configuration to enter this page, each configuration has the following items:

Field	Type	Required	The default value is	Description
packages	StringArray	Yes	None	Pre-download the root or name of the subpackage after entering the page. APP represents the main package.
network	String	No	wifi	Pre-download under the specified network, the optional value is: all: unlimited network wifi: pre-download