微信小程式開發06-一個業務頁面的完成

發表於2018-08-07
微信小程式

前言

接上文：微信小程式開發05-日曆元件的實現

github地址：https://github.com/yexiaochai/wxdemo

這裡來說一說我們的理念，我們也學習小程式開發有一週多了，從近期的使用上來說，小程式可以作為底層，但是缺少一個框架層，這個框架層需要提供：

① 元件庫

② 更好的程式碼組織方式，也就是讓我們可以做到輕鬆的元件化開發

我們從最開始到現在，都在沿著這個方向去分解小程式學習，其實小程式本身的東西差不多了，但是我們程式碼過程中有時候卻越高越複雜，多了很多封裝，其實這所有的複雜都是為了設定一個基本的架構，一個標準的開發模式，讓後面寫業務程式碼的同學能更高效的寫程式碼，經過一年多的發展，事實上這種較為成熟的框架已經有了，比如我們正在使用的：

https://tencent.github.io/wepy/

但是，可以看到小程式基本還是原生JS，這其實是個非常好的學習整理機會，所以我這邊一步步和大家對小程式進行了拆分，期望能形成一套還能用的雛形，幫助大家理解，所以我們繼續今天的學習吧，為了降低單頁面難度，我們將首頁進行下改造。

首頁

首頁做了一點改造，變成了這個樣式了：

這裡需要三個點選時間點，因為日曆元件，我們昨天就做好了，而他這個出發日期事實上就是我們日曆元件的selecedDate，處理這塊邏輯：

點選時候我們彈出我們的日曆，這個時候我們日曆模組釋放一個事件顯示日曆：

PS:template不與頁面級別WXML共享一個作用域，所以我暫時都採用的include引入

顯然，這裡的日曆這樣擺設有點醜，我們這裡將其封裝成一個彈出層，所以我們這裡再做一個容器類元件，專門用於裝載頁面樣式用：

但是這裡也引起了其他問題，因為引入了shadow-dom概念，我的樣式不能重用，元件內部樣式與外部是不能通訊的，但是這裡是頁面級別容器，內容的樣式肯定是來源頁面的，這裡沒什麼問題，所以我們這裡顯示的是正確的，但是我這裡想做一個出格一點的操作，我想用樣式將這裡日曆月標題換個位置：

而日曆元件和外部是不能通訊的，我們這裡該如何處理呢，我這裡想了兩個方案：

① 設定一個全域性使用的元件庫樣式，讓所有元件繼承，但是不知道這裡對效能是否有影響，因為這樣的話體積不會太小

② 小程式設計了可以傳入元件的方法，比如我們這裡的日曆元件我們可以這樣改變其樣式

具體各位去github上檢視，總而言之，我們的頁面變成了這個樣子了：

PS：這裡發現一個不知道是不是坑點的點，我們這裡屬性傳遞的是一個date物件，但是到了元件層之間變成了物件，不知微信底層做了什麼：

好像變成了一個空物件，這裡可能發生的情況是，經過傳遞的日期物件會被某種特殊處理，但是具體發生了什麼事情就不知道了，這個卻引起了我們不小的麻煩，這裡大概去翻開了一下原始碼：

極有可能，小程式本身就不支援date屬性的傳遞，我們的日曆元件能跑起來的原因是什麼，我這裡都有點疑惑了……

而且就算以物件方式傳遞到元件的date型別都會變成莫名其妙的東西：

這個特性有點令人抓不住頭腦了，這裡根據探查，很有可能Component將date物件傳入WXML解釋時候，自動轉為了日期字串了，所以我們這裡看上去是物件的東西其實是字串，這裡的建議是：跟元件的date傳遞，暫時全部使用字串代替，以免自我麻煩，然後我們先將之前的日曆操作全部變成字串，再為我們的前後按鈕加上事件：

雖然看上去噁心了一點，但是總是不會出什麼明顯的問題，忍一忍吧……日期部分基本結束了，還有些小的限制沒有做上，比如哪些時段能選，哪些不能，這塊就有待各位發現吧，我們這裡畢竟是學習，做細了很花功夫，我們接下來做出發目的地選擇部分。

資料請求

城市列表

城市列表這裡看起來需要新開一個頁面，但是我這裡想做在一個頁面中，考慮篇幅，我們使用彈出層容器元件看並且儘量削弱一些特性，幾天下來別說寫的還有些累……

這個又作為首頁的一個模組而存在：

首頁呼叫程式碼：

這裡我們開始有資料請求模組了，小程式使用這個介面請求資料，這裡比較尷尬的是他要設定域名白名單：

而我們使用的是測試賬號沒有可以設定的地方，所以我們還是去申請個小程式賬號吧…配置成功，我們繼續程式碼：

可以看到資料請求已經回來了，但是我們一般來說一個介面不止會用於一個地方，每次重新寫好像有些費事，加之我這裡想將重複的請求快取起來，所以我們這裡封裝一套資料訪問層出來

資料快取（持久層）

之前在瀏覽器中，我們一般使用localstorage儲存一些不太更改的資料，微信裡面提供了介面處理這一切：

我們這裡需要對其進行簡單封裝，便與後面更好的使用，一般來說有快取就一定要有過期，所以我們動態給每個快取物件增加一個過期時間：

這個類的使用也非常簡單，這裡舉個例子：

這個時候我們開始寫我們資料請求的類：

首先還是實現了一個抽象類和一個業務基類，然後開始在業務層請求資料：

接下來是實際呼叫程式碼：

資料便請求結束了，有了這個類我們可以做非常多的工作，比如：

① 前端設定統一的錯誤碼處理邏輯

② 前端打點，統計所有的介面響應狀態

③ 每次請求相同引數做資料快取

④ 這個對於錯誤處理很關鍵，一般來說前端出錯很大可能都是後端資料介面欄位有變化，而這種錯誤是比較難尋找的，如果我這裡做一個統一的收口，每次資料返回記錄所有的返回欄位的標誌上報呢，就以這個城市資料為例，我們可以這樣做：

這裡就會輸出以下資訊：

如果對資料要求非常嚴苛，對某些介面做到欄位層面的驗證，那麼加一個Validates驗證即可，這樣對介面的控制會最大化，就算哪次出問題，也能很好從資料分析系統之中可以檢視到問題所在，如果我現在想要一個更為具體的功能呢？我想要首次請求一個介面時便將其資料記錄下來，第二次便不再請求呢，這個時候我們之前設計的資料持久層便派上了用處：

這個時候第二次請求時候便會直接讀取快取了

接下來便可以回到我們的頁面渲染邏輯了，這個時候就變得非常簡單了：

然後我們這裡為元件繫結事件等就比較簡單了，大家可以自己看github，於是我們首頁的功能便完成了：

經過一個多星期的學習，我們慢慢的完成了我們的首頁，好像也就幾個元素，但是後面的一切卻不簡單啊，我們明天繼續完成list頁面邏輯，便開始總結小程式開發

相關文章