wepy+weappx開發小程序遇到的坑以及解決方案

前言

從小程序的發佈，到如今已經有一年多的時間了，從當時信誓旦旦的要替代APP，到近期實現了APP和小程序互跳的功能，定位也悄然變爲APP的一個補充，都是現實給逼的，就像當時卸載了摩拜和美團的APP，以爲只用小程序就行的同事，最後都又把APP裝了回來，爲何呢？由於小程序只是實現了原有APP的部分功能，最後發現仍是APP用着方便，畢竟如今手機內存基本都是32g起，一個APP也佔不了多少地方。

技術無止境，人生莫等閒，開啓正文。

技術棧

• 微信小程序

• WePY

• weappx

微信小程序官方文檔已經很詳細了，通過屢次的更新，目前小程序已經支持自定義組件，引入其餘開發者的插件和外部的資源，還有了一套小程序的語言wxs,據官方文檔的說法在IOS上的運行速度比JavaScript要快2~20倍，組件和API也是愈來愈完善。

WePY是騰訊一團隊出的一個小程序組件化開發框架，第一次更新是在2016.11.23，比小程序的發佈時間2017.1.9還早，也就是說小程序在騰訊內測的時候，某個喜歡Vue大佬用了以後，發現這玩意開發起來不夠爽呀，連組件都不支持，而後這個大佬就拉了一幫人，說兄弟們咱弄個框架出來吧，讓你們能用類Vue的開發方式去開發小程序，而後你應該懂了，若是你會Vue，上手這個那是分分鐘的事，它支持組件 Props 傳值，自定義事件、組件分佈式複用Mixin、計算屬性函數computed、模板內容分發slot等等。

weappx是一個小程序的狀態管理框架，wepy和原生小程序均可以使用， API和Dva，Vuex挺像，可是比它們兩個要簡單的多，Dva已經把APi的數量精簡到6個，它更狠才4個API就能上手，API雖然少但做爲狀態管理框架，該有的功能都是有的，開發起來仍是至關的爽的，詳細的介紹請看文檔，相比Dva如今的9000多個star，weappx的50多個star顯的有點寒酸，若是用了以後以爲挺不錯的童鞋，都star下，精神上支持下做者。

遇到的坑以及開發注意點

1. repeat標籤嵌套兩級以及以上組件傳值給自組件傳值問題

這個問題實際上是wepy的一個bug，在github上已經有好多人提過Issues，官方並無給出解釋，通過本身的摸索，有兩種解決方式：

1. 對於純組件用小程序原生的模板template代替

子組件中第二層循環採用此寫法，直接使用template

<template wx:key="{{index}}" wx:for="{{item.giftBoxs}}" wx:for-item="giftBoxsItem" data="{{...giftBoxsItem}}" is="indexMoItem"></template>
複製代碼

在主頁面中引入此模板

<import src="../../components/giftIndex/indexMoItem.wxml"/>
複製代碼

wepy最終會把所引用的組件代碼，都打包到一個主頁面中的,因此在主頁面引入模板便可

2. 第一種方法能夠解決這個問題，而且還節省了代碼量，但這屬於wepy和原生小程序混寫，後面又發現另外一種解決辦法

對於第二層循環要傳的值，用repeat標籤包裹一層

<repeat for="{{ [item] }}" key="item.orderNo" index="index" item="itemval"> <giftItem :itemval="itemval" ></giftItem> </repeat>
複製代碼

已經在wepy的Issues中作了回答，並有一個老鐵點了贊，應該是幫他解決了這個問題

2. 向子組件傳相似Object.key這樣的值

正常傳值

// 數據
 data = {
    textMsg1: 'text1',
    textMsg2: {
      text: 'text2'
    },
  }
 // 組件
<child :msg="textMsg1"></child>
複製代碼

界面展現

傳對象中的值

<child :msg="textMsg2.text"></child>
複製代碼

界面展現

沒有報錯可是值也沒法傳遞，這個問題也是Issues中提的比較多的,可採用下面方法解決

<repeat for="{{ [textMsg2.text] }}">
   <child :msg="item"></child>
</repeat>
複製代碼

3. 小程序開發工具變慢

在開發過程城中，隨着項目文件的愈來愈大，會發現小程序的開發工具愈來愈慢，甚至一個跳轉都要等幾秒鐘才能跳轉過去，這個時候須要把小程序打包出來的文件dist文件夾刪掉，而後從新打包，會快不少，wepy也提供了命令，直接運行 npm run clean 也能達到一樣的效果。

4. 小程序在手機上預覽，出現卡頓現象

出現這種狀況有多方面的緣由，若是你以前用過原生小程序開發過項目，那麼直接點擊開發工具上的預覽按鈕，而後用手機掃碼預覽是一個常見的操做，可是在使用wepy過程當中，你使用npm run dev 命令後，是出於開發環境，dist文件夾中的代碼並無進行壓縮，優化，因此手機預覽的時候會顯得很慢，運行 npm run build打成生產包預覽，能夠解決。

5. 數據更新了，UI視圖沒有更新

這個也與開發環境和生成環境有關係，這種狀況出現的比較少，在開發選擇地址模塊的時候，在開發工具上選擇地址後，並改變了model中的數據，可是視圖並無更新，這種現象只在開發環境中出現，生產環境一切正常。

6. 個別手機樣式錯亂

出現這種問題，是由於wepy腳手架中並無配置樣式自動補全，須要本身手動配置，在wepy.config.js添加下面代碼便可，插件地址

module.exports.plugins = {
    'autoprefixer': {
      filter: /\.wxss$/,
      config: {
        browsers: ['last 11 iOS versions']
      }
    }
  }
複製代碼

7. 通一個頁面屢次使用同一個組件數據傳遞問題

同一個頁面屢次使用同一個組件，要爲這個組件起不一樣的名字，這個官方文檔有介紹，

須要注意的是，WePY中的組件都是靜態組件，是以組件ID做爲惟一標識的，每個ID都對應一個組件實例，當頁面引入兩個相同ID的組件時，這兩個組件共用同一個實例與數據，當其中一個組件數據變化時，另一個也會一塊兒變化。
複製代碼

這個與wepy的組件機制有關，

// data
data = {
    textMsg1: 'text1',
    textMsg3: 'text3',
    textMsg2: {
      text: 'text2'
    },
}
// 組件
 <child :msg="textMsg1"></child>
 <child :msg="textMsg3"></child>
複製代碼

按照正常的邏輯，最終顯示結果確定是text1和text3,可是

咱們查看編譯後的代碼

<view class="containers">
    <view>我是子組件</view>
    傳遞來的數據：{{$child$msg}}
</view>
<view class="containers">
 <view>我是子組件</view>
  傳遞來的數據：{{$child$msg}}
</view>
複製代碼

在開發工具中的AppData中咱們能看到

相信你們已經明白了，wepy中的組件其實就是把組件中的代碼copy到引入的頁面中，組件中使用的變量，名字被改爲$+組件名字+變量名字，在組件引用頁中的data其實就是一個對象，對象的屬性值，後面會覆蓋前面，頁面渲染過程，大體以下

data = {
}
// 渲染第一個組件
data.$child$msg = 'text1'
// 渲染第二個組件
data.$child$msg = 'text3'

複製代碼

將第二個組件註釋掉，第一個就會顯示正常

咱們給組件起不一樣的名字後顯示就能如預期那樣渲染

// 掛載組件
components = {
    child1: Child,
    child2: Child
};

<child1 :msg="textMsg1"></child1>
<child2 :msg="textMsg3"></child2>

// 編譯後
<view class="containers">
 <view>我是子組件</view>
  傳遞來的數據：{{$child1$msg}}
</view>
<view class="containers">
 <view>我是子組件</view>
  傳遞來的數據：{{$child2$msg}}
</view>
複製代碼

咱們能夠看到顯示正常了，查看data也會看到

8. weappx中更改state數據報錯

在使用weappx過程當中，只能在mutations中更改state中的數據，若是在其餘地方更改數據就會報錯，Uncaught (in promise) TypeError: Cannot assign to read only property 'count' of object '#'，這句話的意思是，count爲只讀屬性，不能進行設置，若是一個頁面要使用其餘model中的數據，最好是深度clone一份，以避免無心中修改數據，出現上述錯誤

使用感覺

1.採用類Vue語法，對於新手比較友好，上手比較快, 但還須要學習小程序的api，框架不是很完善，有很多坑要填

2.使用狀態管理框架,集中管理邏輯代碼，實現不一樣頁面狀態的共享，提高開發效率

3.代碼結構清晰，接口，邏輯代碼和靜態頁面分離，便於多人合做和後期的維護

4.引入庫比較多，致使項目體積過大

總結

總的來講，若是項目比較簡單，不建議採用，直接採用原生小程序去開發效率反而更高；若是項目較大時間又比較近，須要多人合做，可採用此框架，開發效率仍是比較高的，質量也是能夠的；若是時間充足對質量也要求比較高，那仍是採用原生小程序去開發，如今小程序已經比較完善了，不必再用第三方的框架去開發。