Mini Program Host Environment

We refer to the environment provided by MiniApp to Mini Programs as the host environment. Mini Programs leverage the capabilities provided by the host environment to accomplish tasks that regular web pages cannot achieve.

In the previous chapter, we explained the types of files involved in a Mini Program. Let's combine this knowledge with the MiniApp Official Demo project to understand how these files work together.

Rendering Layer and Logic Layer

Firstly, let's briefly understand the runtime environment of a Mini Program. The runtime environment of a Mini Program consists of the rendering layer and the logic layer. DLT templates and CSS styles work in the rendering layer, while JS scripts work in the logic layer.

The rendering layer and logic layer of a Mini Program are managed by two separate threads. The rendering layer's UI is rendered using WebView, while the logic layer runs JS scripts using the JsCore thread. Since a Mini Program can have multiple pages, there are multiple WebView threads in the rendering layer. Communication between these two layers is mediated by the client (referred to as Native in the following sections), and network requests from the logic layer are also relayed through Native. The communication model of a Mini Program is shown in the following diagram.

For detailed documentation on the rendering layer and logic layer, refer to the Mini Program Framework.

Programs and Pages

Before opening a Mini Program, the client downloads the entire Mini Program code package locally.

Following that, the pages field in the app.json file indicates all the page paths in the current Mini Program:

{
  "pages": ["pages/index/index", "pages/logs/logs"]
}

This configuration indicates that the MiniApp Official Demo project has two pages defined, located at pages/index/index and pages/logs/logs. The first page listed in the pages field is the home page of the Mini Program (the page displayed when the Mini Program is opened).

The client loads the code for the home page and uses the underlying mechanisms of the Mini Program to render the page. After the Mini Program starts, the onLaunch callback of the App instance defined in app.js is executed:

App({
  onLaunch: function () {
    // Executed after the Mini Program starts
  },
});

The entire Mini Program shares a single App instance, and this instance is accessible to all pages. For more event callbacks, refer to the documentation on Registering an App.

Next, let's briefly see how a page in a Mini Program is written.

You can observe that pages/logs/logs includes four types of files. The client first generates a page based on the configuration in logs.json. The top color and text can be defined in this JSON file. Next, the client loads the DLT structure and CSS style for this page. Finally, the client loads logs.js, which roughly contains:

Page({
  data: {
    // Data for rendering on the page
    logs: [],
  },
  onLoad: function () {
    // Executed after the page is rendered
  },
});

Page is a page constructor that generates a page. When generating the page, the Mini Program framework renders the final structure based on the data and index.dlt. This results in the appearance of the Mini Program that you see.

After rendering the UI, the page instance receives an onLoad callback, where you can process your logic.

For more detailed documentation on the Page constructor, refer to Registering a Page.

Components

Mini Programs provide a variety of basic components to developers. Developers can use these components like building blocks to create their own Mini Programs.

Similar to HTML's div, p, and other tags, in Mini Programs, you only need to use the corresponding component tag name in DLT to display the component on the UI. For example, if you want to display an image, you can write:

<image src="/images/api_normal.png" />

When using components, you can also pass values to the component through attributes, allowing the component to be displayed in different states. For example, if you want to enable lazy loading for an image, you need to declare attributes like data-src (actual image URL), lazy-load (whether to enable lazy loading), and src (placeholder image URL):

<image
  data-src="/images/api_normal.png"
  :lazy-load="false"
  src="/images/img_5222.png"
/>

The behavior of components is also made available to developers through events. For instance, you can handle image loading success or failure using bindload and binderror functions in JS:

<image
  src="/images/img_5222.png"
  bind:binderror="imageError"
  bind:bindload="imageLoad"
/>

Of course, you can also control the external style of components using style or class attributes to adapt to various UI dimensions.

API

To allow developers to easily utilize the capabilities provided by the Mini Program SDK, such as accessing device information and local storage, Mini Programs provide a wide range of APIs.

For example, to get the user's location:

dlt.getLocation((res) => {
  var latitude = res.latitude; // Latitude
  var longitude = res.longitude; // Longitude
});

To use the scanning capability:

dlt.scanCode({
  onlyFromCamera: false,
  scanType: '',
  callback: (res) => {
    this.setData({
      scanInfo: res.data,
    });
  },
});

Keep in mind that most API callbacks are asynchronous, so you need to handle asynchronous logic appropriately.

For more API capabilities, refer to the Mini Program API.

With this chapter, you now have a basic understanding of how a Mini Program runs. After developing a Mini Program, the next step is to publish it. In the next chapter, you will learn what preparations are required before publishing.