Structure, cycle de vie et regroupement du projet

Thomas Steiner

Structure d'un projet de mini-application

Comme précédemment pour les langages de balisage, les langages de style et les composants. Avec la structure de mini-projet d'application, les détails tels que les extensions de fichier ou les noms par défaut varient. Toutefois, l'idée générale est la même pour tous les fournisseurs de super-applications. La structure d’un projet se compose toujours de:

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

Toutes les pages sont stockées dans des sous-dossiers individuels d'un dossier pages. Chaque sous-dossier de la page contient un fichier CSS, un fichier JS, un fichier HTML et un fichier JSON de configuration facultatif. Tous les fichiers doivent porter le même nom que le dossier dans lequel ils se trouvent, à l'exception des extensions de fichier. Comme cela, la mini-application a simplement besoin d'un pointeur vers le répertoire du fichier app.json (le fichier de type 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 de plusieurs pages.

├── 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 globalement. Comme indiqué dans la structure de projet décrite précédemment, cette opération se produit dans app.js. Le cycle de vie d'une mini-application comprend essentiellement 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 des données qui doivent être disponibles mondialement 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 de la page

Comme pour le 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 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 précédemment, 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 indépendant du développeur. En arrière-plan, elle utilise des outils du secteur tels que le compilateur Babel pour la transpilation et la minimisation, ainsi que le transformateur CSS postcss. L'expérience de compilation est comparable à celle de Next.js ou de create-react-app, où les développeurs choisissent explicitement de ne pas modifier les paramètres de compilation. Les fichiers traités qui en résultent 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 même temps. 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 de rétro-ingénierie.

Remerciements

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