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

笑在秋風中發表於2018-06-12
APP

前言

從小程式的釋出，到現在已經有一年多的時間了，從當時信誓旦旦的要替代APP，到近期實現了APP和小程式互跳的功能，定位也悄然變為APP的一個補充，都是現實給逼的，就像當時解除安裝了摩拜和美團的APP，覺得只用小程式就行的同事，最後都又把APP裝了回來，為什麼呢？因為小程式只是實現了原有APP的部分功能，最後發現還是APP用著方便，畢竟現在手機記憶體基本都是32g起，一個APP也佔不了多少地方。

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

技術棧

微信小程式官方文件已經很詳細了，經過多次的更新，目前小程式已經支援自定義元件，引入其他開發者的外掛和外部的資源，還有了一套小程式的語言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+weappx開發小程式遇到的坑以及解決方案

這個問題其實是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最終會把所引用的元件程式碼，都打包到一個主頁面中的,所以在主頁面引入模板即可

  1. 第一種方法可以解決這個問題，並且還節省了程式碼量，但這屬於wepy和原生小程式混寫，後面又發現另一種解決辦法

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

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

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

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

2. 向子元件傳類似Object.key這樣的值

正常傳值

// 資料
 data = {
    textMsg1: 'text1',
    textMsg2: {
      text: 'text2'
    },
  }
 // 元件
<child :msg="textMsg1"></child>
複製程式碼

介面展示

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

傳物件中的值

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

介面展示

wepy+weappx開發小程式遇到的坑以及解決方案
沒有報錯但是值也無法傳遞，這個問題也是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,但是

wepy+weappx開發小程式遇到的坑以及解決方案
我們檢視編譯後的程式碼

 <view class="containers">
    <view>我是子元件</view>
    傳遞來的資料：{{$child$msg}}
</view>
<view class="containers">
 <view>我是子元件</view>
  傳遞來的資料：{{$child$msg}}
</view>
複製程式碼

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

wepy+weappx開發小程式遇到的坑以及解決方案
相信大家已經明白了，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也會看到

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

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.引入庫比較多，導致專案體積過大

總結

總的來說，如果專案比較簡單，不建議採用，直接採用原生小程式去開發效率反而更高；如果專案較大時間又比較近，需要多人合作，可採用此框架，開發效率還是比較高的，質量也是可以的；如果時間充足對質量也要求比較高，那還是採用原生小程式去開發，現在小程式已經比較完善了，沒必要再用第三方的框架去開發。

相關文章