banner
阿珏酱

阿珏酱

乘上与平常相反的电车,去看看那未曾见过的风景
twitter
github
facebook
bilibili
zhihu
steam_profiles
youtube

Mini Program Architecture

Tips: When you see this prompt, it means that the current article has been migrated from the original emlog blog system. The publication time of the article is too long, and the formatting and content may not be complete. Please understand.

Mini Program Architecture

Date: 2019-5-17 Author: Ajue Views: 1708 Comments: 4

I don't know how everyone writes mini programs. A few months ago, when I was writing a WeChat mini program, I created my own architecture, or framework.

The original architecture of WeChat mini program is like this:

├── app.js
├── app.json
├── app.wxss
├── pages
│   │── index
│   │   ├── index.wxml
│   │   ├── index.js
│   │   ├── index.json
│   │   └── index.wxss
│   └── logs
│       ├── logs.wxml
│       └── logs.js
└── utils

Why not use the original WeChat way of writing?
A mini program is similar to a mobile app, and both have a tabBar, right? The tabBar in WeChat official is globally configured in app.json. It is fine for general development, but when it comes to a complex tabBar, the official native tabBar cannot be implemented or dynamically loaded. For example, the camera and video recording function in a video app.
This means that we cannot use the tabBar provided by the official. We need to create our own.
At first, I kept the original structure and just created my own tabBar. So all the page code was written in one file, with only the first screen displayed by default and the others hidden. When switching pages, the corresponding page would be displayed and the others hidden, and the data would be dynamically rendered. But there was a problem. If it was a small project, there was no big problem. However, if it was a large project with a large amount of code, it would be difficult to maintain all the code in one file in the later stage. So this method was eventually abandoned.

Later, I changed the way of switching pages to navigation (wx.switchTab, etc.), and put the code of different pages into different files. However, there was still a problem. The switching would cause a flash, as if reopening a webpage, and the tabBar would be re-rendered, causing a flash. So this method was also abandoned.

Therefore, a new architecture was born:
All the files under /pages/index/ were defined as entry files, including js entry, css entry, and view entry. The files of different pages were still placed in different locations for easy management. A new folder called "template" was created to store the code between different pages. The structure of the template was the same as the official one.
The app.js in the root directory is used to store global functions, which can be called by other pages using getApp().

JS Entry File#

const app = getApp();
var index_js = require("../../template/index/index.js");
var types_js = require("../../template/types/types.js");
var Global_Data = [];
Page({
    data: {
        active: 0,
        show: {
            index: true,
            types: false,
            course: false,
            user: false
        }
    },

    onLoad(options) {
        this.setData({
            Global_Data: index_js.getData()
        })
    },

    // Bottom nav switch
    tabbar_onChange(event) {
        var key = '';
        this.data.show = {
            index: false,
            types: false,
            course: false,
            user: false
        };
        console.log(event)
        switch (event.detail) {
            case 0:
                key = 'index';
                Global_Data = index_js.getData();
                break;
            case 1:
                key = 'types';
                Global_Data = types_js.getData()
                break;
            case 2:
                key = 'course';
                Global_Data = index_js.getData();
                break;
            case 3:
                key = 'user';
                Global_Data = index_js.getData();
                break;
        }
        this.data.show[key] = true;
        console.log(Global_Data)
        this.setData({
            show: this.data.show,
            Global_Data: Global_Data
        })
    },
});

WXML Entry File#

<!-- Entry file -->
<import src="/template/nav" />

<block wx:if="{{show.index }}">
    <import src="/template/index/index" />
    <template is="index" data="{{Global_Data}}" />
</block>

<block wx:elif="{{show.types}}">
    <import src="/template/types/types" />
    <template is="types" data="{{Global_Data}}" />
</block>

<block wx:elif="{{show.course}}">
    <import src="/template/course/course" />
    <template is="course" data="{{Global_Data}}" />
</block>

<block wx:elif="{{show.user}}">
    <import src="/template/user/user" />
    <template is="user" data="{{Global_Data}}" />
</block>

<template is="nav" data="{{active}}" />

<view style='height:50px;'></view>

CSS Entry#

@import "/template/user/user.wxss";


.container {
  height: 100vh;
  background-color: #fff;
}

.tag,
.button {
  margin-right: 5px;
}

.van-card__footer {
  margin-top: 5px;
}

Structure of Sub-pages#

JS#

const app = getApp();
var index_data = {
    banner: [
        '//img4.mukewang.com/szimg/5c4a74c009dea3b500000000.jpg', '//img2.mukewang.com/szimg/5c734d880939299918000600.jpg', '//img4.mukewang.com/szimg/5c63e89209f9f17d00000000.jpg'
    ],
    imageUrl: 'http://img1.sycdn.imooc.com/szimg/5c6bdb3e08e4674a06000338-360-202.jpg',
    tabs_active: 0
};
// app.alert('aa');
// Need to expose interfaces, otherwise they cannot be called
module.exports = {// Used to return global data
    getData: function() {
        return index_data;
    },
    myfunction: function (){
        app.alert('aa');
    }

};

CSS and WXML can be written as usual. If the WXML needs to be reused, continue to separate the common parts in the current directory and import them using the template tag.
This method can achieve fast page switching without flashing and good file division for management.
This method is a combination of the failures of the previous two methods, and it was born by combining them.
Since the project was not fully completed in the end, I was called to develop other projects, so there may be some omissions in the details. If there are any new developments in the future, I will update it.

image

User Comments:

image Ordinary people have many troubles 1 year ago (2020-02-17)
Is the framework interface different between WeChat mini program and QQ mini program? I heard that if you slightly modify a WeChat mini program, it can be used for QQ mini program.

image Ajue 1 year ago (2020-02-20)
@Ordinary people have many troubles: I'm talking about architecture, not framework. It sounds so profound.

image VPS234 Host Evaluation 2 years ago (2019-09-11)
This is similar to Vue in mini program development. It feels relatively simple. [#aru_1]

image Ajue 2 years ago (2019-05-17)
New progress? It doesn't exist. I've been waiting for more than a month to publish it.

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.