Structure, cycle de vie et regroupement du projet

Thomas Steiner

Structure du projet de la mini-application

Comme précédemment pour les langages de balisage, les langages de style et les composants. Avec la structure de projet de mini-application, les détails tels que les extensions de fichier ou les noms par défaut varient. L'idée globale est cependant la même pour tous les fournisseurs de super-applications. La structure du projet comprend toujours:

  • Un fichier racine app.js qui initialise l'application mini.
  • Un fichier de configuration app.json qui correspond à peu près à un fichier manifeste d'application Web.
  • Un fichier de feuille de style commun facultatif app.css avec des styles partagés par défaut.
  • Un fichier project.config.json contenant des informations sur la compilation.

Toutes les pages sont stockées dans des sous-dossiers individuels dans un dossier pages. Chaque sous-dossier de page contient un fichier CSS, un fichier JS, un fichier HTML et un fichier JSON de configuration facultatif. Tous les fichiers doivent être nommés comme le dossier parent, à l'exception des extensions de fichier. Ainsi, la mini-application a simplement besoin d'un pointeur vers le répertoire dans le fichier app.json (le fichier manifeste) et peut trouver toutes les sous-ressources de manière dynamique. Du point de vue d'un développeur Web, les mini-applications sont donc des applications multipages.

├── 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

Cycle de vie de la mini-application

Une mini-application doit être enregistrée auprès de la super-application en appelant la méthode App() définie de manière globale. En se référant à la structure de projet décrite précédemment, cela se produit dans app.js. Le cycle de vie de la mini-application se compose essentiellement de quatre événements: launch, show, hide et error. Les gestionnaires de ces événements peuvent être transmis à la méthode App() sous la forme d'un objet de configuration, qui peut également contenir une propriété globalData contenant les données qui doivent être disponibles dans le monde entier sur toutes les pages.

/* 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",
});

Comme d'habitude, les détails individuels varient, mais le concept est le même pour WeChat, Alipay, Baidu, ByteDance et Quick App.

Cycle de vie des pages

À l'instar du cycle de vie de l'application, le cycle de vie de la page comporte également des événements de cycle de vie que le développeur peut écouter et auxquels il peut réagir. Ces événements principaux sont load, show, ready, hide et unload. Certaines plates-formes proposent des événements supplémentaires tels que pulldownrefresh. La configuration des gestionnaires d'événements s'effectue dans la méthode Page() définie pour chaque page. Pour les pages index ou other de la structure de projet avant, cela se produisait respectivement dans index.js ou other.js.

/* 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",
  },
});

Processus de compilation

Le processus de création des mini-applications est éliminé par le développeur. En arrière-plan, il utilise des outils du secteur tels que le compilateur Babel pour la transpilation et la minimisation et le CSS Transformer postcss. L'expérience de compilation est comparable à celle de Next.js ou create-react-app, où les développeurs, s'ils choisissent explicitement de ne pas les modifier, ne modifient jamais les paramètres de compilation. Les fichiers traités résultants sont enfin signés, chiffrés et empaquetés dans un ou plusieurs (sous)packages, qui sont ensuite importés sur les serveurs des fournisseurs de super-applications. Les sous-packages sont conçus pour le chargement différé. Il n'est donc pas nécessaire de télécharger une mini-application en une seule fois. Les détails du packaging sont censés être privés et ne sont pas documentés, mais certains formats de package tels que le format wxapkg de WeChat ont fait l'objet d'une rétroingénierie.

Remerciements

Cet article a été lu par Joe Medley, Kayce Basques, Milica Mihajlija, Alan Kent et Keith Gu.