Skip to main content

Hybrid Development Mode

Based on visual application editing, WeDa supports developing and deploying applications via code to facilitate the migration and integration of applications built with the original model. Depending on the application type, it is divided into two methods: WEB and Mini Program.

WEB Micro-Apps Integration​

WeDa supports creating micro-app pages and introducing natively developed pages via code. In principle, it adopts the micro-frontend approach using single-spa, introducing purehtml pages to abstract away specific technology stack differences.

Before integration, ensure that documents and resources within the documents can be loaded normally via the browser's fetch api (resources must support cross-origin loading). Additionally, for resources such as images, JS, etc. in the documents, use full paths with host (e.g., https://a.com/js/main.js). If using relative paths, ensure the resources can be accessed under the application's hosted host (Note: this refers to the application's hosted host, not the micro-application documents' hosted host).

Access​

  1. Access requires providing an accessible html document, which must additionally declare a script and export the corresponding lifecycle:

    <!DOCTYPE html>
    <html lang="en">
      <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Purehtml Example</title>
      </head>
      <body>
        <div>Purehtml Example</div>
      </body>
      <script src="https://a.com/js/entry.js" entry></script>
    </html>

  2. Declare the lifecycle in the entry js

    ((global) => {
      // global.${pageid}
      global["purehtml"] = {
        /**
         * bootstrap is called only once during the micro-application's initialization. The next time the micro-application re-enters, the mount hook will be called directly without triggering bootstrap repeatedly.
         * Typically, we can initialize global variables here, such as application-level caches that won't be destroyed during the unmount phase.
         */
        bootstrap: () => {
          console.log("purehtml bootstrap");
          return Promise.resolve();
        },
        /**
         * Each time the application enters, the mount method is called. Typically, we trigger the application's rendering method here.
         */
        mount: () => {
          console.log("purehtml mount");
          return render();
        },
        /**
         * The method called each time the application switches out/uninstalls. Typically, we unload the micro-application's instance here.
         */
        unmount: () => {
          console.log("purehtml unmount");
          return Promise.resolve();
        },
      };
    })(window);

    const render = () => {
      document.querySelector("#purehtml-container").innerHTML =
        "Hello, page mount render";
      return Promise.resolve();
    };

    entry has no magic. The key point is that it needs to mount and register the micro-frontend application on the global window object, where purehtml is the page id (the page id generated when adding a micro-frontend page in the WeDa application). The micro-frontend application has three lifecycles: bootstrap, mount, and unmout, which are called when the micro-frontend page is loaded/unloaded. As shown in the example code, during loading, it modifies and updates the dom, displaying Hello, page mount render.

Mini Program Subpackage Integration​

A WeDa application can consist of one main module and multiple sub-modules. The sub-modules, operating in the Mini Program subpackage mode, combine with the main module to form a complete Mini Program application. Each main/sub-module can be either a low-code editing type or a code package type. The low-code editing type refers to modules generated through visual editing on the WeDa platform, while the code package type allows users to upload code packages developed using traditional development models.

Hybrid development mode requires clarifying the master-subordinate relationship. For each module, the low-code mode is considered a low-code editing application, while the code package is considered a native mini program application.

When the code package serves as the main module, it must contain complete Mini Program project code. The project structure should meet the system restrictions specified below, and the code requires no modifications.

When the code package serves as a submodule, it must contain an independent mini-program application directory, i.e., the miniprogramRoot directory. The entire project will be placed in the /packages/${subapp.name} path, so parts using absolute paths in original file references and route jumps may need adjustment, while relative path relationships within the package remain unchanged. Overall, the requirement is that the final transformed code package must follow the mini-program subpackage pattern, with an added app.json file declaring the page list within the package. For example: the content of app.json in subpackage sub would be

{
  "pages": [
    "pages/index/index",
    "pages/checkbox/index",
    "pages/switch/index",
    "pages/slider/index"
  ]
}

then the configuration will be added to the app.json of the generated complete mini-program.

{
  "subpackages": [
    {
      "root": "packages/sub",
      "pages": [
        "pages/index/index",
        "pages/checkbox/index",
        "pages/switch/index",
        "pages/slider/index"
      ]
    }
  ]
}

When using low-code editing for main/sub-modules, the system automatically generates relevant code. There's no need to overly concern about reference relationships; simply focus on the application's business logic and choose whether to navigate to pages in the main package or subpackage during page redirection.

Main-Sub Module Interaction​

WeDa application states are divided into global state and page-level state. The global state is shared across the entire application, while page-level states are independent per page. Therefore, when data interaction is required between main and sub-modules, the global state should be used for proxy storage. In low-code environments, you can obtain the app object to get/set its global variables. In code package type modules, you can use const { app } = getApp() to obtain the app object, enabling variable get/set operations and methods like data sources.

The page path for the main module is /pages/${page.id}/index, while for submodules it is /packages/${subapp.name}/pages/${page.id}/index. When handling routing jumps, the corresponding template addresses must be clearly specified.

Limitations​

  1. Each application consists of 1 main module and up to 5 sub-modules. When at least one low-code editing type module exists among the main/sub-modules, hybrid building can be performed on the WeDa platform.
  2. When the main module is of the code package type, it constitutes a complete mini-program application. After decompression, the root directory must contain a project.config.json file declaring the mini-program application root directory (miniprogramRoot). If undeclared, this defaults to the root directory. The root directory contains application-level files such as app.json, app.js, and app.wxss. Additionally, packages, common, app, materials, and lowcode are reserved directories. When generating applications jointly with low-code modules, files required for low-code functionality will be generated under these directories.
  3. When a submodule is of the code package type, it must constitute an independent mini-program application directory, i.e., miniprogramRoot. After decompression, the root directory contains application-level files such as app.json, and its content will be merged with the configuration of the low-code generated main module.
  4. Application-level low-code and variable management can only be performed in the main application. Low-code editing submodules can be viewed in the editor but cannot be defined, declared, added, modified, or deleted.