Structure, cycle de vie et regroupement du projet

Thomas Steiner

Structure d'un projet de mini-application

Comme pour les langages de balisage, les langages de style et les composants, avec la mini-appli la structure du projet, les détails tels que les extensions de fichier ou les noms par défaut varient. L'idée générale est toutefois la même pour tous les fournisseurs de super applications. La structure du projet se compose toujours des éléments suivants :

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

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

Une mini-application doit être enregistrée auprès de la super-application en appelant la méthode App() définie globalement. En se référant à la structure de projet décrite ci-dessus, cela 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 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 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, comme 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 du structure de projet auparavant, cela se produisait dans index.js ou other.js respectivement.

/* 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, il 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, s'ils choisissent explicitement de ne pas le faire, ne touchent jamais aux paramètres de compilation. Fichiers traités obtenus sont signés, chiffrés et empaquetés dans un ou plusieurs (sous)packages, qui sont ensuite importés vers les serveurs des fournisseurs de super-applications. Les sous-packages sont destinés au chargement différé. Par conséquent, une mini-application n'a pas besoin d'être téléchargée en une seule fois. Les détails de l'emballage sont censés être confidentiels et ne sont non documentées, mais certains formats de package comme le format wxapkg de WeChat ont été la reverse-engineered.

Remerciements

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