Estrutura do projeto de mini app
Assim como com as linguagens de marcação, as linguagens de estilo e os componentes. Com a estrutura do miniprojeto de app também, os detalhes, como as extensões de arquivo ou os nomes padrão, variam. No entanto, a ideia geral é a mesma para todos os provedores de superapps. A estrutura do projeto sempre consiste em:
- Um arquivo raiz
app.js
que inicializa o mini app. - Um arquivo de configuração
app.json
que corresponde aproximadamente a um manifesto de app da Web. - Um arquivo opcional de folha de estilo comum
app.css
com estilos padrão compartilhados. - Um arquivo
project.config.json
que contém informações do build.
Todas as páginas são armazenadas em subpastas individuais em uma
pasta pages
. Cada subpasta de página contém um arquivo CSS, um arquivo JS, um arquivo HTML e um arquivo JSON de configuração opcional. Todos os arquivos precisam ser nomeados como a pasta que os contém, exceto as extensões
de arquivo. Assim, o miniapp só precisa de um ponteiro para o diretório no arquivo app.json
(o arquivo semelhante ao manifesto) e pode encontrar todos os sub-recursos dinamicamente. Da perspectiva de um desenvolvedor
Web, miniapps são apps de várias páginas.
├── 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
Ciclo de vida do miniapp
Um miniapp precisa ser registrado com o superapp chamando o método App()
definido globalmente.
Em relação à estrutura do projeto descrita antes, isso acontece em
app.js
. O ciclo de vida de um miniapp consiste basicamente em quatro eventos: launch
, show
, hide
e
error
. Os gerenciadores desses eventos podem ser transmitidos para o método App()
na forma de um
objeto de configuração, que também pode conter uma propriedade globalData
com os dados que precisam estar
disponíveis globalmente em todas as páginas.
/* 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",
});
Como de costume, os detalhes individuais variam, mas o conceito é o mesmo para WeChat, Alipay, Baidu, ByteDance e também para Quick App.
Ciclo de vida da página
Assim como o ciclo de vida do app, o da página também tem eventos de ciclo de vida que o desenvolvedor pode
detectar e reagir. Os eventos principais são load
, show
, ready
, hide
e unload
. Algumas
plataformas oferecem outros eventos, como pulldownrefresh
. A configuração dos manipuladores de eventos acontece no método Page()
definido para cada página. Para as páginas index
ou other
da
estrutura do projeto antes, isso aconteceria em index.js
ou
other.js
, respectivamente.
/* 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",
},
});
O processo de build
O processo de build de miniapps é abstraído pelo desenvolvedor. Nos bastidores, ele usa
ferramentas do setor, como o compilador Babel para transpilação e minificação e
o transformador CSS postcss (links em inglês). A experiência de build é comparável à do
Next.js ou do
create-react-app
, em que os desenvolvedores, se
optarem explicitamente por não fazer isso, nunca mexem nos parâmetros de build. Os arquivos processados resultantes
são finalmente assinados, criptografados e empacotados em um ou vários (sub)pacotes, que são enviados
para os servidores dos provedores de superapps. Os subpacotes são destinados ao carregamento lento. Dessa forma, um miniapp
não precisa ser baixado de uma só vez. Os detalhes da embalagem precisam ser particulares e não estão
documentados, mas alguns formatos de pacote, como o wxapkg
do WeChat, foram
revertidos (link em inglês).
Agradecimentos
Este artigo foi revisado por Joe Medley, Kayce Basques, Milica Mihajlija, Alan Kent e Keith Gu.