プライマー
「アプレット」 過去6ヶ月間では、ほとんどのヒアリ最もホットな語の一つでなければなりません。テクノロジースタックアプレットは、最も魅力的なポイントは、このような小さなプログラムの集まりのような小さなプログラム専用の入り口の流れ、他ならない、アプレットを検索します。小さな手続きの波の下では、内部またはアリ協力企業かどうか、徐々にアプレットの行のビジネスのフロントエンド技術スタックを推進してきました。
アプレットは、新しいエコロジーとして、開発が開始されますと、一般的なフロントエンド技術スタックは、大きな差があります。それでは、どのフロントエンドエンジニアリングをアプレットとそれを組み合わせますか？
小さなプロジェクトへの痛みの研究開発プログラムの観点から
（A）疼痛ポイント
（1）第一段階 - ビルディングブロック
遠くのネイティブアプレットフロントエンドエンジニアリングおよびエンジニアリングの違い。公式文書は、唯一の方法を開発するために、基本的な文法アプレットを使用する方法をお教えします。タイトなタイムスケジュールのビジネス面では、最も重要なタスクは、H5アプレットにプロジェクトを移行することです。唯一のアプリケーション、ページ、コードを整理するコンポーネントの方法と公式文書によると、全体のアプレットのApp純度を保ちます。この場合、プログラムのライフサイクルも小さく要求データ処理、表示、相互作用に限定されます。
同時に、周囲の生態系のアプレットはまた、急速に湧きされています。オンライン確保し、ビジネス機能の急速な発展を確保するために、我々はアリモックツール--Datahubの私たちのフロントエンドの国際チームの開発プロセスの迅速なアクセスを持っている、アリババも問題はオンライン追跡することができることを保証するために監視を統一フロントエンドにアクセスします。しかし、内部のフロアプランは、おそらく小さなパーティの開発者プログラムでは、不均一なアリのチームアプレット、この分化がさらに明白です。
（2）第二段階 - 標準
この間、アリは、標準化プロセスを促進支援の強力なIDEのプラグイン-、アリ内部開発および統合開発プロセスの三者、開発者を向上させるための小さなプログラムです。ウォレットアリ（国際版と同様のアリペイ）のパートナー国は、また、統一された世界標準のアプレットになりました。
（3）第三段階 - エンジニアリング
小さな手続きの規格を統合した後、開発者はまた、フロントエンドエンジニアリングに移動することができます。近いフロントエンド技術スタックに、アプレットのチームをしてみましょう。特定のサービスモジュールに含むことミニUI、独立した機能部品と同じであってもよいです。複雑なプロジェクトのアプレットの場合、小さなエンジニアリングプログラムを整理するSubAppの方法を確立することができます（下記参照）。
（B）小規模プロジェクト・プログラム
より近いフロントエンドエンジニアリングモードの小さな日常の発展にプログラムを作成するには、次のように小さなプログラムを支援するいくつかの重要なエンジニアリングプロジェクトが必要です。
（1）状態管理
状态管理使小程序有了数据流，让小程序真正的“活”起来。最原始的小程序多个Page之间、Page和App之间数据难以共享。借助状态管理，Page和App之间的数据可以打通。
在状态管理中，我们使用herculex。而小程序官方将来也会推出官方的脚手架。如果只是想借助状态管理而不想让它管理更新Data，也可以使用Redux和Mobx。只不过万变不离其宗，小程序使用状态管理后，结合小程序自身的特性，会有一些神奇的效果。
1.利用页面保活更新数据
小程序如果两个Page都打开过，在一定的时间内两个页面都会保活。如果有两个Page同时监听一个Store Data，用户操作，更新了可视页面Store Data，而在非可视页面内的Store Data会被静默更新，触发渲染。这样非可视页面重新出现时，其实用户已经看到了新的数据源渲染的页面。
2.优化更新数据
小程序官方文档中，有提到小程序性能优化，而小程序定制的状态管理工具herculex已经帮开发者做掉了this.setData操作，开发者不用关心。
（2）Mock方案
我们利用Datahub方案，Mock小程序的底层接口。
Datahub方案，在小程序的IDE开发环境下，可以通过npm run datahub先启动Datahub，接口层通过my.request方式请求到Datahub平台。
在小程序中使用Datahub有下列几个优点。
使用Datahub方案，Mock数据源不会被依赖跟随构建打包。
场景切换，场景数据可共享，可以一键切换任意返回结果。
Mock数据可以多人共享。
（3）监控
小程序官方提供了监控的能力，my.reportAnalytics
这对业务来说非常重要，建议在代码中加上my.reportAnalytics监控。按照码以内部的业务经验来说，需要my.reportAnalytics所需要的地方如下：
接口报错，try-catch
全局App onError
关键用户行为，包括重要区块曝光与点击
其他关键业务模块
如果是上报错误的话，建议可以采用Error格式上报
（4）国际化
多语言
使用：通过小程序App初始化中取得容器App语言信息，完成多语言选择，并保持在全局数据中。在需要地方，完成语言取用。
（5）扩展
组件库
按照业务的需要，可以自己定义一套类似mini-ui的组件，通过npm包的形式进行复用。
SubApp
针对非常复杂的小程序，想对业务进行隔离但是又有共同的数据，可以将小程序中分割出不同的App模块。用SubApp的形式来组织。
（三）小程序生态建设
我们将小程序扩展到上图中的生态，基本小程序也能有接近前端工程的能力。
对小程序未来的预测
团队中很多业务都是基于小程序的，我们团队认为小程序有以下两个高潜价值方向。
（一）跨端生态
小程序作为一个统一标准的技术，为各个业务线和各个客户端上的应用能力互通打下了基础。理想情况下，一套应用代码，可以部署到各个支持标准小程序的客户端上。能较好地解决目前各个客户端上技术栈不同导致的壁垒问题。如我们可以使用除H5以外的方案在其他不同客户端上进行业务的开发，可以更好地将我们的业务进行多端外投。在小程序方向的技术建设上各个团队也容易达成共识和形成共建合力。
（二）外部生态
对于三方开发者，以小程序这样轻量化的上层应用开发方式，可以快速地挖掘一批用户日常的应用，通过这些贴合生活的应用，如“记账”、“商品扫码价格查询”等，来快速地聚合吸引一批用户。