谦喜彩票官网-谦喜彩票登录-谦喜彩票平台-点击进入

谦喜彩票官网

当前位置:谦喜彩票官网 > 工程范围 > 解决方案一 >

解決方案一

解決方案一

  後台管理系統在很多業務場景下都會用到,由于其面向人群的特殊性,我們一般不太關注其界面布局,樣式等,而在于功能的實用性。需求那麽多,悲傷辣麽大,我還想早點回家幹點什麽呢?前段時間一直在做一個商城的管理後台,積累了一些經驗,抽象出了大部分管理後台都會用到並且可以複用的東西,如權限設計,希望對後面需要搭建管理後台的童鞋有所幫助。

  既然要快速搭建、敏捷響應産品大大提出的需求,那麽我們希望盡量複用已有並且功能實用的東西。對于管理後台,第一大特點就是表單輸入賊多,手動輸入、下拉列表、級聯選擇、單選、多選圖片上傳、日期等等五花八門。因此,我們需要有基礎的表單組件可以讓我們複用,這樣可以節省很大一部分人力。其次是我們選擇的技術要能快速上手。于是我們想到了當前最爲流行的三個前端框架---angular,react,vue,三者都符合我們的技術選型。考慮到國內vue較爲流行,並且相對而言輕量、易于上手,因此主體采用vue,結合狀態管理vuex,路由管理vue-router,基礎組件庫element-ui。由于管理台對首屏的要求不高,因此我們可以搭建爲一個SPA(單頁應用)。

  PS:後面抽象出來的內容與具體技術無關,完全可以使用你所偏好技術,這裏我對抽象出來的方案用Vue進行了實現,詳情請看後台管理系統通用解決方案

  考慮到每個團隊都有一套自己熟悉的頁面結構搭建、構建和部署方式,這裏不做具體討論,但是有些建議:

  頁面使用的公共組件最好放在同一個目錄下,如果公共組件過多,最好在進行分類,因爲項目一旦大了的話,分類相當于索引,可以快速查看某個組件,便于維護。如:

  每個頁面的目錄結構最好包含數據源,業務組件,vuex配置文件等,這樣這個頁面調用了哪些接口、有哪些業務組件都一目了然,如:

  當然啦,有些接口很多地方都會使用,就不適合放到某個頁面下,可以單獨建一個models目錄(類似于公共組件那樣),專門放置公用接口來方便調用。

  3、構建構建如果使用webpack的話,強烈建議加上webpack的alias和extensions功能,它能讓你更優雅的加載模塊:

  有了上面的配置後,比如你要加載公共組件裏面組件或者或者models裏面的js,在任何地方你都可以直接像下面這樣寫,避免使用一長串的相對路徑:

  這裏實現了一套具有通用性權限設計方案,任何管理後台都可以按這個方案快速實現權限控制,粒度從頁面到組件,再到dom,可以說是360度無死角權限控制。

  可以看到,列舉出的傳統方案缺點較爲明顯。那該怎麽做呢?權限控制的本質是針對不同權限的人展示不同的頁面,組件,dom,再本質點就是操作dom的顯隱性。框架所提供的自定義指令功能就是讓我們手動操作dom的,既然不能使用內置判斷指令,爲什麽我們不自己定義一個權限指令呢?

  我們可以自定義一個權限指令,指令內部將第三方傳入的權限和事先從後台拿到的權限集合做對比,沒有權限則對第三方做隱藏或其他操作。特別的,如果第三方是頁面並且沒有訪問權限的話,做出相應提示或跳轉。這樣頁面、組件或者組件內元素在判斷權限時只需要提供所需權限給自定義指令即可。

  a.後台提供一個接口,前端調用該接口可以拿到當前用戶的權限集合,如{1001:true,1002:true},其中1001表示首頁的訪問權限,1002表示按鈕的訪問權限。

  b.定義權限和後台返回的權限控制數據的關系A,用于指令調用時傳參的語義化。如後台返回的權限數據{1001:true,1002:true},那麽關系A可以定義爲{MAIN_READ:1001,BUTTON_READ:1002};定義頁面路由和權限的對應關系B,用于頁面的訪問權限控制。如首頁路由爲/index.html,則關系B可以定義爲{‘index.html’:MAIN_READ}。

  c.從後台獲取所有的權限控制數據,包含頁面的,組件的和組件內部元素的,並且進行全局共享,比如放在window下,便于自定義指令獲取數據。

  d.定義全局自定義權限指令,由于各粒度的權限只需要判斷一次,不存在變動,因此權限的判斷邏輯將只執行一次,跟只執行一次的鈎子函數綁定。這裏有區分不同操作需求,一般情況下,權限驗證不通過做的是隱藏操作,但頁面的訪問則需要給出相應提示或跳轉。因此,對于傳入的權限參數,如果參數爲空,則認爲是需要判斷頁面訪問權限,獲取當前路由,通過關系B獲取頁面所需要的權限參數,由權限參數和關系A獲取到權限數據,如果後台返回的數據中沒有該權限則給出相應提示或跳轉。其他的情況則直接由傳入的權限參數和關系A獲取到權限數據,沒有權限則隱藏,或者做其他的操作,這裏權限驗證不通過或者通過所做的操作完全是可擴展的。

  e.給頁面各個需要權限控制的地方加上自定義指令,並傳入需要的權限參數,如某個按鈕,按照定義的關系A,則傳入BUTTON_READ;如果是頁面,則傳入空。

  優點: 實現了前端對頁面各粒度權限的統一控制,封裝權限處理邏輯到自定義指令中,與其他業務邏輯解耦,非常大程度上提高了代碼的可閱讀和可維護性。缺點:你發現缺點了一定要告訴我

  管理台實用性較強,一個頁面調用十幾個接口,這時候對獲取數據的封裝就非常重要了。傳統異步獲取數據底層用的是XMLHttpRequest,它的設計非常粗糙,配置和調用方式非常混亂,而且是基于事件回調的,遠沒有用Promise友好。而fetch(fetch---傳送門)的話,語法簡潔,更加語義化,並且基于標准的Promise實現,可以快樂的使用es7的async/await,擺脫回調地獄,寫異步代碼就跟寫同步代碼是一樣的。這裏要特別注意,fetch默認不會給你帶cookie到服務端,如需帶cookie,加上{credentials: include}。

  這裏特別要注意,接口必須有個標志告訴我們數據是正常的,我這裏寫的是iErrCode爲0表示正常,這裏使用者可自行定義。

  首先,雖然管理台在整個架構在是SPA,但也存在多頁的場景,比如詳情頁或者打印頁,需要打開新的窗口顯示,對這些頁面對應的組件定義,完全沒必要在首屏的時候加載,我們可以使用異步組件配合webpack的code split功能,實現路由懶加載(雖然是管理台,我們還是要有點情懷),提高首屏。這裏的原理是webpack把異步組件的定義單獨打包到一個js文件,並且在主js文件中插入代碼,代碼的內容是:當訪問的是懶加載的路由,如果該路由對應的組件沒有被定義,則加載原來單獨打包的裏面包含異步組件定義的js。

  其次,如果涉及到頁面曝光上報的話,我們可以將路由命名,然後在路由全局前置守衛裏面對這個命名進行上報。如:

  再次,管理台的大多數頁面一般是有一個固定的布局,但也存在布局完全不一樣的情況,這個時候就需要用到命名視圖了,代碼如下,具體請看命名視圖

  最後,最好使用vue-router的history模式,hash模式實在太醜了,而且不能通過url訪問指定頁面。

  由于管理台的實用性和功能性,必然涉及到非常多的接口,因此我們引入vuex進行狀態管理。一般情況下,我們都是把所有狀態挂在一個state下,但對有非常多頁面的管理台,不推薦這樣做,要不然我們的狀態樹就太大了,而且命名也會有問題,我們需要將狀態劃分模塊。強烈建議使用vuex的modules(傳送門 vuex modules)功能,並且加一個namespaced:true;這樣每個頁面對應的組件有一個store文件,裏面定義state,action,mutation,不容易導致混亂。

  除此之外,通常一個數據錄入頁面要承擔數據的修改和新增兩個功能,新增的話,需要我們提前准備好初始的業務對象state,修改就需要我們在拿到數據後,補上沒有返回的屬性,如果不補上的話,數據錄入很有可能會有問題,並且初始值要跟新增初始值保持一致。手動添加不存在的屬性並賦初值就太low了,而且極有可能漏掉某些屬性。我們可以定義一個文件存儲新增時需要的初始業務state,如果是修改,在拿到後台的數據對象後,遞歸遍曆該對象並賦值到初始state上,最終返回這個被遞歸賦值的初始state,代碼如下:

  對應頁面中常用的公共組件,如翻頁組件、Loading組件等,可以在new Vue之前進行全局注冊,這樣就不需要每次使用時候,進行一次局部引入。詳情請看基礎組件的自動化全局注冊

  (2)全局通信全局通信對管理台也是非常重要的,具體做法是new一個Vue實例作爲全局通信對象,並挂載在window下。比如在頁面上進行了一個操作,操作成功後給一個toast提示,很顯然,我們不能把toast組件加到每個頁面所對應的組件裏面,爲了只引入一次,我們可以把toast加入口vue文件裏面,並使用全局通信對象監聽,這樣在需要toast的時候,只需要觸發該事件就好。

  管理台涉及非常多的表單輸入,當然有非常多的輸入有效性驗證啦,最好再項目搭建的時候就提供這麽一個模塊,裏面全部是基礎的有效性檢查函數,比如isNumber,isInteger,isZero等等

  對組件的上移,下移,置頂,刪除在管理台也是很常見的,比如運營想把更優質的模塊排在更前面點,直接進行這些操作也是可以的,但是我感覺這樣非常生硬,一閃操作就完成了,體驗不好(我可是有情懷的開發),于是引入了vue的transition和transition-group,用transition-group來實現組件上移,下移,置頂,刪除的過渡效果,效果如下:

  element-ui中提供的基礎組件需要配合我們的業務場景進行使用,比如給input的左邊配置一個title,那麽就需要我們對element-ui進行再封裝。由于業務場景的複雜性,我們不能預測到所有的case,因此我們在封裝時,可以提供一些slot,供外界調用時進行個性化模板傳入。其次element-ui的基礎組件提供了大量的屬性,爲了能在調用時任何屬性都能用到,推薦在定義基礎組件時加上inheritAttrs: false,禁用特性繼承,不讓特性加到跟元素上,並把v-bind=$attrs加到element-ui的基礎組件上,這樣就跟調用沒封裝的element-ui一樣。

  如采用上述方案遇到問題,歡迎聯系、留言。或者有任何更好的實踐,歡迎探討,共同進步。

  彩蛋1:要是有哪位大神能猜出文章封面圖是在哪裏拍的,我一定要送只可愛的公仔給你


上一篇:解決方案一
下一篇:解決方案一
联系方式 联 系 人:谦喜彩票官网 手机: 谦喜彩票官网
座 机 :谦喜彩票官网 邮箱:谦喜彩票官网
地 址:谦喜彩票官网
Copyright © 2016-2020 谦喜彩票官网 版权所有!
织梦园模板网 技术支持