Projektstruktur für Mini-Apps
Wie bei den Markup-, Stil- und Komponentensprachen variieren auch bei der Mini-App-Projektstruktur Details wie die Dateiendungen oder die Standardnamen. Der Grundgedanke ist jedoch für alle Super-App-Anbieter gleich. Die Projektstruktur besteht immer aus:
- Eine Stammdatei
app.js, die die Mini-App initialisiert. - Eine Konfigurationsdatei
app.json, die in etwa einem Manifest der Webanwendung entspricht. - Eine optionale gemeinsame Stylesheet-Datei
app.cssmit freigegebenen Standardstilen. - Eine
project.config.json-Datei mit Build-Informationen.
Alle Seiten werden in einzelnen Unterordnern in einem pages-Ordner gespeichert. Jeder Seitenunterordner enthält eine CSS-Datei, eine JS-Datei, eine HTML-Datei und eine optionale JSON-Konfigurationsdatei. Alle Dateien müssen mit Ausnahme der Dateiendungen den Namen des übergeordneten Ordners haben. So benötigt die Mini-App nur einen Verweis auf das Verzeichnis in der app.json-Datei (der manifestähnlichen Datei) und kann alle Unterressourcen dynamisch finden. Aus der Sicht eines Webentwicklers sind Mini-Apps also mehrseitige Apps.
├── app.js # Initialization logic
├── app.json # Common configuration
├── app.css # Common style sheet
├── project.config.json # Project configuration
└── pages # List of pages
├── index # Home page
│ ├── index.css # Page style sheet
│ ├── index.js # Page logic
│ ├── index.json # Page configuration
│ └── index.html # Page markup
└── other # Other page
├── other.css # Page style sheet
├── other.js # Page logic
├── other.json # Page configuration
└── other.html # Page markup
Mini-App-Lebenszyklus
Eine Mini-App muss bei der Super App registriert werden. Dazu wird die global definierte Methode App() aufgerufen.
Gemäß der oben beschriebenen Projektstruktur geschieht dies in app.js. Der Mini-App-Lebenszyklus besteht im Wesentlichen aus vier Ereignissen: launch, show, hide und error. Handler für diese Ereignisse können der App()-Methode in Form eines Konfigurationsobjekts übergeben werden. Dieses kann auch eine globalData-Property enthalten, die Daten enthält, die global auf allen Seiten verfügbar sein sollen.
/* app.js */
App({
onLaunch(options) {
// Do something when the app is launched initially.
},
onShow(options) {
// Do something when the app is shown.
},
onHide() {
// Do something when the app is hidden.
},
onError(msg) {
console.log(msg);
},
globalData: "I am global data",
});
Wie üblich variieren die einzelnen Details, aber das Konzept ist für WeChat, Alipay, Baidu, ByteDance und Quick App identisch.
Seitenlebenszyklus
Ähnlich wie beim App-Lebenszyklus gibt es auch beim Seitenlebenszyklus Lebenszyklusereignisse, auf die der Entwickler warten und reagieren kann. Diese Hauptereignisse sind load, show, ready, hide und unload. Einige Plattformen bieten zusätzliche Ereignisse wie pulldownrefresh. Die Einrichtung der Event-Handler erfolgt in der Page()-Methode, die für jede Seite definiert ist. Bei den Seiten index oder other aus der Projektstruktur vorher würde dies jeweils in index.js oder other.js geschehen.
/* index.js */
Page({
data: {
text: "This is page data.",
},
onLoad: function (options) {
// Do something when the page is initially loaded.
},
onShow: function () {
// Do something when the page is shown.
},
onReady: function () {
// Do something when the page is ready.
},
onHide: function () {
// Do something when the page is hidden.
},
onUnload: function () {
// Do something when the page is closed.
},
onPullDownRefresh: function () {
// Do something when the user pulls down to refresh.
},
onReachBottom: function () {
// Do something when the user scrolls to the bottom.
},
onShareAppMessage: function () {
// Do something when the user shares the page.
},
onPageScroll: function () {
// Do something when the user scrolls the page.
},
onResize: function () {
// Do something when the user resizes the page.
},
onTabItemTap(item) {
// Do something when the user taps the page's tab.
},
customData: {
foo: "bar",
},
});
Der Build-Prozess
Der Build-Prozess von Mini-Apps wird für Entwickler abstrahiert. Im Hintergrund werden Branchentools wie der Babel-Compiler für die Transpilierung und Minimierung und der PostCSS-CSS-Transformer verwendet. Die Build-Umgebung ist mit der von Next.js oder create-react-app vergleichbar, bei der Entwickler die Build-Parameter nur dann ändern, wenn sie dies ausdrücklich tun. Die resultierenden verarbeiteten Dateien werden schließlich signiert, verschlüsselt und in einem oder mehreren (Unter-)Paketen verpackt, die dann auf die Server der Super App-Anbieter hochgeladen werden. Unterpakete sind für das Lazy Loading gedacht, sodass eine Mini-App nicht auf einmal heruntergeladen werden muss. Die Verpackungsdetails sind vertraulich und werden nicht dokumentiert. Einige Paketformate wie das wxapkg-Format von WeChat wurden jedoch rückwärts-entwickelt.
Danksagungen
Dieser Artikel wurde von Joe Medley, Kayce Basques, Milica Mihajlija, Alan Kent und Keith Gu geprüft.