滷煮在公司之初接觸到的是一個微信APP應用。前端技術採用的是Backbone+zepto等小型JS類庫。在項目開發之初,這類中小型的項目採用這兩種庫能夠知足基本的需求。然而,隨着迭代的更新和業務的增長,成堆的代碼被覆蓋到項目中去了,使得這樣一種技術架構方式變得異常的臃腫,不少界面變得異常的難以維護,所以滷煮打算重構公司前端架構。css
滷煮的想法是:採用異步模塊的加載方式,將不一樣微信菜單進入的界面分紅若干的模塊文件,這樣的好處是按照需求加載界面,並且每一個界面都單獨成模塊,便於維護和獨立開發。因而滷煮花了大概一個月的時間重構了前端。也就是從那時起以backbone的框架爲基礎,封裝成一套配置框架。就這樣,項目通過改良,變得比較容易維護,滷煮也從其中學到了若干經驗,積累了一些有用的代碼,最後逐步通過改進,在通過實踐的考驗(用此框架完成了其餘兩個中小項目),整理成了一套本身的小型框架出來,滷煮將之命名爲SalutJs。它剛剛誕生,它並不怎麼成熟,文檔寫得比較馬虎,具體得看開發實例,滷煮都放到github上去了。滷煮用它作過三個項目,但整體感受是比較不錯的,它很是適合作這樣的相似微信app中小型單頁應用。本篇博文就是向諸位分享滷煮的一些經驗和框架知識,但願可以幫助正在最相似web應用而不知道怎麼下手的諸君一些小小的幫助。html
如滷煮以前說的那樣,隨着業務和界面的增長,代碼回變得愈來愈難以維護。碰到此類問題,第一件想到的事情就是一個字「分」。但如何分呢?這個問題滷煮考慮了許久。滷煮作的微信開發,一個線上的點餐項目,它包含以下功能:點餐,會員中心,優惠,砍價,呼叫等等十幾個,這些功能裏面,每一個功能裏面進去會有相關的若干界面。能夠想見,若是把全部的界面業務代碼放在一個文件裏面,整個項目會變得異常的臃腫最後奔潰。滷煮考慮的是將每一個功能裏面的若干界面的代碼放到同一份js裏面,這樣,當用戶使用其中一個功能的時候只須要加載一個js而不是十幾個界面代碼。當咱們須要從一個功能裏面的界面切換到另一個功能模塊裏面的界面時,咱們運用requirejs的異步加載方式,異步載入須要加載的文件。這樣便解決了代碼耦合和臃腫的問題了。值得一提的是咱們結合界面的原則是根據業務需求來的。滷煮舉個例子:在點菜功能裏面有若干界面,但點菜功能不必定會須要會員卡功能界面,因此,咱們在寫點菜功能文件的時候,是不須要把會員卡界面業務包含進去的。前端
在渲染功能上,滷煮沒有作何改變,沿用的是underscore的template方法渲染。因爲界面的業務已經分開,那麼html結構也對應的能夠分開。沒必要要一開始就將沒必要要的html代碼放入咱們的主體文件中。滷煮加載html模板的原則是跟js有些同樣的,方法則是用ajax講html以文本的形式下載下來,而後渲染到界面中去。在require的時候,咱們會去服務器拉去對應的模板文件,也就是說咱們實現不一樣大功能之間的跳轉須要請求兩個文件,一個是xx.js,另一個是xx.html。實際開發過程當中,你不須要本身去調用這些文件,使用route.myNavigate方法,框架會自動幫助你去下載js和html文件:node
在使用Salut的時候須要按照既定的一些目錄規則來建立文件結構。咱們的項目大體分爲若干目錄:git
construction:配置文件以入口文件github
css:樣式文件web
fonts:字體文件ajax
img:存放路徑服務器
js:存放全部基礎架構js和業務代碼以及模板文件微信
node:運行測試項目node文件(實際開發中請無視)
page_main.html:主題html文件
run.js: node文件,運行便可將項目跑起來
js文件夾下面又分了若干文件夾,存放了不一樣的js文件
base:salut的核心代碼
core:backbone和zepto等底層代碼
plugins:若干插件
tpl:模板文件
use:每一個功能的業務代碼文件
config:配置文件
map.html:須要用到的地圖文件
page_main.html是整個項目的html,若是沒有其餘特殊的業務需求,全部的單頁面都在此html中實現,不會有url的跳轉。它的最外層是一層div包裹着的,做爲最外層的容器。而後是用require引入的入口js的文件:
<body> <!-- 最外層容器 --> <div id="pageWindow"></div> <!-- 引入require 載入入口文件 --> <script data-main="construction/app" src="construction/require.js"></script> </body>
咱們看到,只要當界面一開始加載,而後開始引入了app.js文件,在app.js中,咱們會判斷當前界面的地址,配置好require的默認配置,引入自定義配置,開始拉取對應的界面業務代碼下來:
Salut的命名有本身的一套規則:主要體如今文件命名上:在命名業務文件上採用大寫字母開頭,而在命名html文件上規則是tpl加小寫字母開頭的對應js業務文件。在爲每一個節目註冊路由時,路由的名稱爲大寫字母開頭,界面名則爲小寫字母開頭,但名稱都是同樣的。每次你創建一個新功能的時候,必須去config裏配置這個功能模塊文件的名字和裏面對對應的界面名稱的關係,在github的例子中你會看到。這樣作的緣由就是js沒有讀取本地文件的能力,因此你必須把其餘功能文件中的界面寫在配置文件裏面,這樣,當須要去load另一個界面的時候,才知道咱們是須要加載哪個js。
Salut並無改變backbone的路由規則,它沿用了以前的hash作法,在backbone源碼中,你能夠看到有多種方式實現路由推進事件,他們是hash、pushstate、和定時函數。Salut的初衷也是分界面,每個路由對應着每個界面,在地址欄中改變hash值(#號後面那部分,對應不一樣界面)從而跳轉不一樣的界面。這個滷煮在以前的博文中已經講到過了,這裏就再也不提。路由的名稱是和界面模塊的名稱有關係的,在命名規則裏面咱們也已經提到過了。
Salut在構建相似以上提到的相似微信app的應用時很是適合,也很是簡單。它對於中小型的app應用來講是比較合適的。學會規則後幾乎只要簡單的配置就能完成加入一個界面到項目中的工做。滷煮本身考慮後續把requirejs這樣的模板加載文件替換掉(已經寫完),最後把backbone底層框架也換調,把他作成一套徹底自主的js框架。不過這是一條比較漫長的道路了。滷煮已經把相關的文檔上傳到了github上,裏面有一整套demo,註釋也寫得比較詳盡。諸君若是有興趣,請關注一下。海納百川,有容乃大。Saultjs做爲初生的一套輕框架存在或多或少的問題,也因爲他的實踐經驗很少,要求它不斷的在實踐中不斷地進步完善。固然,憑藉滷煮一人之力,實在微不足道,爲此特將其開源,但願諸君爲它添磚加瓦,使得它更增強大。或者能夠提供本身的意見,也很是歡迎貢獻代碼。總而言之,滷煮在此並非推廣本身的框架,只是分享一下工做中總結起來的一些代碼工具而已。若是你什麼疑問,請發郵件到alberteinstein007@126.com或者在博客評論區留下你的意見,滷煮看到後會及時回覆的。
唔。。。。。凌晨一點半寫完,諸君能看到這裏給個推薦吧。
遇到問題或者建議加羣:461636182