前言
鹵煮在公司之初接觸到的是一個微信APP應用。前端技術采用的是Backbone+zepto等小型JS類庫。在項目開發之初，這類中小型的項目采用這兩種庫可以滿足基本的需求。然而，隨着迭代的更新和業務的增加，成堆的代碼被覆蓋到項目中去了，使得這樣一種技術架構方式變得異常的臃腫，很多界面變得異常的難以維護，因此鹵煮打算重構公司前端架構。
鹵煮的想法是：采用異步模塊的加載方式，將不同微信菜單進入的界面分成若干的模塊文件，這樣的好處是按照需求加載界面，而且每個界面都單獨成模塊，便於維護和獨立開發。於是鹵煮花了大概一個月的時間重構了前端。也就是從那時起以backbone的框架為基礎，封裝成一套配置框架。就這樣，項目經過改良，變得比較容易維護，鹵煮也從其中學到了若干經驗，積累了一些有用的代碼，最后逐步經過改進，在經過實踐的考驗（用此框架完成了其他兩個中小項目），整理成了一套自己的小型框架出來，鹵煮將之命名為SalutJs。它剛剛誕生，它並不怎么成熟，文檔寫得比較馬虎，具體得看開發實例，鹵煮都放到github上去了。鹵煮用它做過三個項目，但總體感覺是比較不錯的，它非常適合做這樣的類似微信app中小型單頁應用。本篇博文就是向諸位分享鹵煮的一些經驗和框架知識，希望能夠幫助正在最類似web應用而不知道怎么下手的諸君一些小小的幫助。
架構思路
如鹵煮之前說的那樣，隨着業務和界面的增加，代碼回變得越來越難以維護。碰到此類問題，第一件想到的事情就是一個字“分”。但如何分呢？這個問題鹵煮考慮了許久。鹵煮做的微信開發，一個線上的點餐項目，它包含如下功能：點餐，會員中心，優惠，砍價，呼叫等等十幾個，這些功能里面，每個功能里面進去會有相關的若干界面。可以想見，如果把所有的界面業務代碼放在一個文件里面，整個項目會變得異常的臃腫最后奔潰。鹵煮考慮的是將每個功能里面的若干界面的代碼放到同一份js里面，這樣，當用戶使用其中一個功能的時候只需要加載一個js而不是十幾個界面代碼。當我們需要從一個功能里面的界面切換到另外一個功能模塊里面的界面時，我們運用requirejs的異步加載方式，異步載入需要加載的文件。這樣便解決了代碼耦合和臃腫的問題了。值得一提的是我們結合界面的原則是根據業務需求來的。鹵煮舉個例子：在點菜功能里面有若干界面，但點菜功能不一定會需要會員卡功能界面，所以，我們在寫點菜功能文件的時候，是不需要把會員卡界面業務包含進去的。
html模板
在渲染功能上，鹵煮沒有做何改變，沿用的是underscore的template方法渲染。由於界面的業務已經分開，那么html結構也對應的可以分開。不必要一開始就將不必要的html代碼放入我們的主體文件中。鹵煮加載html模板的原則是跟js有些一樣的，方法則是用ajax講html以文本的形式下載下來，然后渲染到界面中去。在require的時候，我們會去服務器拉去對應的模板文件，也就是說我們實現不同大功能之間的跳轉需要請求兩個文件，一個是xx.js,另外一個是xx.html。實際開發過程中，你不需要自己去調用這些文件，使用route.myNavigate方法，框架會自動幫助你去下載js和html文件:
目錄結構
在使用Salut的時候需要按照既定的一些目錄規則來創建文件結構。我們的項目大致分為若干目錄：
construction:配置文件以入口文件
css：樣式文件
fonts：字體文件
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