截止目前為止，自己開發(fā)過不下十款小程序。算是有些經(jīng)驗，其實對于一個熟悉了前端開發(fā)的工程師，小程序的入門會非常簡單，無非是要多熟悉些API和小程序的開發(fā)工具。本質(zhì)上和寫一個H5頁面沒有什么區(qū)別。

抽象化

做的越多，就越覺得其實每個小程序都差不多。慢慢的就能夠抽出一些通用的代碼，作為公用模塊。但是小程序的一個限制就是，代碼必須在項目的根目錄下。這個是由于小程序框架的限制，如果在根目錄之外，require模塊的時候，會找不到對應的文件，因為路徑會解析失敗。

這樣帶來的問題就是，需要借助其他方法來做到模塊甚至頁面的復用。A、B兩人獨自開發(fā)一個項目，A、B共用的模塊C。兩個人開發(fā)還好，如果有四五個人，項目也很多，各自拷貝C模塊就違背了軟件開發(fā)的DRY原則。C模塊的迭代會導致代碼管理很混亂。因此需要設(shè)計合理的框架來滿足開發(fā)需求。

按照流行的套路，把生產(chǎn)環(huán)境與發(fā)布環(huán)境隔離。我們需要新開辟一個空間，專門在這個地方寫代碼，然后需要用到的公共組件都從同一個地方取，并且生成最終可以在小程序上運行的代碼。這樣，對于公共組件，我們就可以只用維護一份代碼。

 

實現(xiàn)

具體實現(xiàn)起來會遇到一下幾個問題

 

1、require路徑解析問題。

common目錄下的代碼最終會構(gòu)建到每個項目中，如App1/common。App1/pages/index/index.js 需要依賴common目錄下的模塊，就需要寫很長的相對路徑（小程序只支持相對路徑）。所以我們建立一個規(guī)則，凡是依賴common目錄下的模塊，就直接寫common/xxx.js，由構(gòu)建工具來解析路徑。

2、組件依賴問題

組件之間的依賴用相對路徑

3、wxml與wxss的同步問題

由于小程序不像vue一樣，三個文件整合在一起，而是分開了。但使用組件的時候，需要將這三部分分別require/import一次，顯得有點繁瑣，尤其是依賴的組件有點多的時候。依賴構(gòu)建工具，一旦發(fā)現(xiàn)組件下有wxml與wxss文件則自動同步到項目下，并且在項目的wxml注入相應的依賴。

4、頁面級的復用

調(diào)用組件的方式還是太繁瑣，有時候我們需要直接復用頁面。直接從common目錄下拷貝一個頁面到項目中，并自動在app.json插入配置。

{
  "pages":[
    "pages/index/index",
    "pages/common/common" // auto insert
  ]
}