Structure, cycle de vie et regroupement du projet

Thomas Steiner

Structure du 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. 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.
  • 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.
  • 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 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 qui les contient, à l'exception des extensions de fichier. Ainsi, la mini-application n'a besoin que d'un pointeur vers le répertoire dans le fichier app.json (fichier semblable au 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 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 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 des données qui doivent être disponibles globalement 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

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 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, comme pulldownrefresh. La configuration des gestionnaires d'événements se fait dans la méthode Page() définie pour chaque page. Pour les pages index ou other de la structure de projet avant, cela se produit 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, 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, s'ils choisissent explicitement de ne pas le faire, ne touchent jamais aux paramètres de compilation. Les fichiers traités qui en résultent sont finalement signés, chiffrés et empaquetés dans un ou plusieurs (sous-)paquets qui sont ensuite importés sur 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 informations sur le packaging sont censées être privées et ne sont pas documentées, mais certains formats de package, comme le format wxapkg de WeChat, ont été remaniés.

Remerciements

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