如鹵煮之前說的那樣,隨著業(yè)務(wù)和界面的增加,代碼回變得越來越難以維護。碰到此類問題,第一件想到的事情就是一個字“分”。但如何分呢?這個問題鹵煮考慮了許久。鹵煮做的微信開發(fā),一個線上的點餐項目,它包含如下功能:點餐,會員中心,優(yōu)惠,砍價,呼叫等等十幾個,這些功能里面,每個功能里面進去會有相關(guān)的若干界面??梢韵胍?,如果把所有的界面業(yè)務(wù)代碼放在一個文件里面,整個項目會變得異常的臃腫最后奔潰。鹵煮考慮的是將每個功能里面的若干界面的代碼放到同一份js里面,這樣,當(dāng)用戶使用其中一個功能的時候只需要加載一個js而不是十幾個界面代碼。當(dāng)我們需要從一個功能里面的界面切換到另外一個功能模塊里面的界面時,我們運用requirejs的異步加載方式,異步載入需要加載的文件。這樣便解決了代碼耦合和臃腫的問題了。值得一提的是我們結(jié)合界面的原則是根據(jù)業(yè)務(wù)需求來的。鹵煮舉個例子:在點菜功能里面有若干界面,但點菜功能不一定會需要會員卡功能界面,所以,我們在寫點菜功能文件的時候,是不需要把會員卡界面業(yè)務(wù)包含進去的。
在渲染功能上,鹵煮沒有做何改變,沿用的是underscore的template方法渲染。由于界面的業(yè)務(wù)已經(jīng)分開,那么html結(jié)構(gòu)也對應(yīng)的可以分開。不必要一開始就將不必要的html代碼放入我們的主體文件中。鹵煮加載html模板的原則是跟js有些一樣的,方法則是用ajax講html以文本的形式下載下來,然后渲染到界面中去。在require的時候,我們會去服務(wù)器拉去對應(yīng)的模板文件,也就是說我們實現(xiàn)不同大功能之間的跳轉(zhuǎn)需要請求兩個文件,一個是xx.js,另外一個是xx.html。實際開發(fā)過程中,你不需要自己去調(diào)用這些文件,使用route.myNavigate方法,框架會自動幫助你去下載js和html文件:
在使用Salut的時候需要按照既定的一些目錄規(guī)則來創(chuàng)建文件結(jié)構(gòu)。我們的項目大致分為若干目錄:
construction:配置文件以入口文件
css:樣式文件
fonts:字體文件
img:存放路徑
js:存放所有基礎(chǔ)架構(gòu)js和業(yè)務(wù)代碼以及模板文件
node:運行測試項目node文件(實際開發(fā)中請無視)
page_main.html:主題html文件
run.js: node文件,運行即可將項目跑起來
js文件夾下面又分了若干文件夾,存放了不同的js文件
base:salut的核心代碼
core:backbone和zepto等底層代碼
plugins:若干插件
tpl:模板文件
use:每個功能的業(yè)務(wù)代碼文件
config:配置文件
map.html:需要用到的地圖文件
page_main.html是整個項目的html,如果沒有其他特殊的業(yè)務(wù)需求,所有的單頁面都在此html中實現(xiàn),不會有url的跳轉(zhuǎn)。它的最外層是一層div包裹著的,作為最外層的容器。然后是用require引入的入口js的文件:
1 2 3 4 5 6 |
< body > <!-- 最外層容器 --> < div id="pageWindow"></ div > <!-- 引入require 載入入口文件 --> < script data-main="construction/app" src="construction/require.js"></ script > </ body > |
我們看到,只要當(dāng)界面一開始加載,然后開始引入了app.js文件,在app.js中,我們會判斷當(dāng)前界面的地址,配置好require的默認配置,引入自定義配置,開始拉取對應(yīng)的界面業(yè)務(wù)代碼下來:
Salut的命名有自己的一套規(guī)則:主要體現(xiàn)在文件命名上:在命名業(yè)務(wù)文件上采用大寫字母開頭,而在命名html文件上規(guī)則是tpl加小寫字母開頭的對應(yīng)js業(yè)務(wù)文件。在為每個節(jié)目注冊路由時,路由的名稱為大寫字母開頭,界面名則為小寫字母開頭,但名稱都是一樣的。每次你建立一個新功能的時候,必須去config里配置這個功能模塊文件的名字和里面對對應(yīng)的界面名稱的關(guān)系,在github的例子中你會看到。這樣做的原因就是js沒有讀取本地文件的能力,所以你必須把其他功能文件中的界面寫在配置文件里面,這樣,當(dāng)需要去load另外一個界面的時候,才知道我們是需要加載哪一個js。
Salut并沒有改變backbone的路由規(guī)則,它沿用了之前的hash做法,在backbone源碼中,你可以看到有多種方式實現(xiàn)路由推動事件,他們是hash、pushstate、和定時函數(shù)。Salut的初衷也是分界面,每一個路由對應(yīng)著每一個界面,在地址欄中改變hash值(#號后面那部分,對應(yīng)不同界面)從而跳轉(zhuǎn)不同的界面。這個鹵煮在之前的博文中已經(jīng)講到過了,這里就不再提。路由的名稱是和界面模塊的名稱有關(guān)系的,在命名規(guī)則里面我們也已經(jīng)提到過了。
Salut在構(gòu)建類似以上提到的類似微信app的應(yīng)用時非常適合,也非常簡單。它對于中小型的app應(yīng)用來說是比較合適的。學(xué)會規(guī)則后幾乎只要簡單的配置就能完成加入一個界面到項目中的工作。鹵煮自己考慮后續(xù)把requirejs這樣的模板加載文件替換掉(已經(jīng)寫完),最后把backbone底層框架也換調(diào),把他做成一套完全自主的js框架。不過這是一條比較漫長的道路了。鹵煮已經(jīng)把相關(guān)的文檔上傳到了github上,里面有一整套demo,注釋也寫得比較詳盡。
SalutJS的github地址