頁面組件化
UI來自elementUI
還記得原先熟練地敲出這樣一個(gè)HTML文檔：
在這里我還是要推薦下我自己建的web前端開發(fā)學(xué)習(xí)群：731669587，群里都是學(xué)web前端開發(fā)的，如果你正在學(xué)習(xí)前端 ，小編歡迎你加入，今天分享的這個(gè)案例已經(jīng)上傳到群文件，大家都是軟件開發(fā)黨，不定期分享干貨（只有前端軟件開發(fā)相關(guān)的），包括我自己整理的一份2018最新的前端進(jìn)階資料和高級(jí)開發(fā)教程，歡迎進(jìn)階中和進(jìn)想深入前端的小伙伴。
jq時(shí)代
這是屬于jq的時(shí)代，直到后來我的膝蓋中了一箭，沒錯(cuò)，箭是Angularjs射出的，當(dāng)然這之間還有一些歷程，比如Backbone.js的出現(xiàn)再到Angularjs，從mvc模式到mvvm的過渡，不過這已經(jīng)是很久之前的事了。
現(xiàn)在是SPA（single-Page Web Application）或者M(jìn)PA（multi-Page Web Application）的時(shí)代了，去年最火的莫過于這三個(gè)框架了
spa-frame
如果你的項(xiàng)目還沒用到這些，那就不妨試試吧
JS模塊化
從無模塊時(shí)代，到萌芽時(shí)代，再到CMD/AMD，到現(xiàn)在的ES6標(biāo)準(zhǔn)
JS模塊化的簡單描述
JS模塊化的優(yōu)點(diǎn)有：
大文件分解功能單一的小文件，便于維護(hù)
功能按需加載，增加可復(fù)用性
文件異步加載，提高性能
管理文件依賴
減少命名沖突，變量污染
多人協(xié)作互不干擾
如果你遇到上述問題，是時(shí)候考慮一下使用模塊化解決了
CSS 演變
CSS是一個(gè)頁面的衣服，年代在變化，時(shí)尚在流行，從CSS，到CSS3，到Sass/Less/Stylus，到CSS Modules，再到PostCss， 以及CSS in JS，而你或許還光著大膀子，使用著css，為了兼容lowB瀏覽器，還不敢使用css3，好吧，如果你這樣，看我眼神→_→
以一個(gè)元素的圓角邊框的樣式的不同寫法
傳統(tǒng)的css，在沒有css3新加特性的情況下，實(shí)現(xiàn)一些特殊的效果，是比較復(fù)雜的；而css3本身是很好的，但是由于各大瀏覽器廠商呀，又得使用hack來兼容多瀏覽器；
CSS preprocessor技術(shù)，如sass，less，stylus等等預(yù)先處理css，編輯成我們想要的樣式，同時(shí)在css中加入了部分js語法，更加方便書寫css；
stylus和sass去除了‘{’，‘}’和‘；’，使用縮進(jìn)來代替層級(jí)關(guān)系，使css書寫更加簡便；
postCss不是一個(gè)預(yù)處理器，而是一個(gè)平臺(tái)，我們可以在上面直接添加我們想要對(duì)css文件處理的插件，就可以生成相應(yīng)的css，比如有了 Autoprefixer，你不再需要擔(dān)心前綴選擇了，有了Stylelint 可以檢測css中的錯(cuò)誤，使用cssnano壓縮css文件等等；
css-modules通過一個(gè)隨機(jī)固定的屬性來限制css的樣式作用域；
css in js 目前還處于爭議階段，這個(gè)改變的就是我們的頁面書寫習(xí)慣了，原先是以html元素為主，后添加樣式，而css in js 則正好相反，以帶有樣式的元素去構(gòu)建頁面，當(dāng)然css in js 也有不同的實(shí)現(xiàn)方式，有style，也有inline-style等等
css命名
總結(jié)了以前用到的幾種命名方式，根據(jù)項(xiàng)目的需求和未來擴(kuò)展具體使用不同的命名方式或者多種方式的組合
隨意命名
隨意命名給維護(hù)和擴(kuò)展帶來了非常大的不利，也給那些想看你代碼的人（同事或者爬客）帶來了小小的心理困擾
以功能模塊命名
例如：
登錄模塊：login
里面的元素命名都以login-**這種方式
公共模塊：
里面的元素命名都以pub-**這種方式
以功能模塊來命名，能清晰明了的知道該樣式是起什么作用的，但是代碼復(fù)用性差
姓氏命名法
姓氏命名法就是以父元素的完整類名為自己的類名前綴，例如：
新聞列表
new
--new-list
----new-list-con
------new-list-con-title
------new-list-con-img
------new-list-con-author
-------new-list-con-author-portrait
-------new-list-con-author-name
----new-list-nature
------new-list-nature-createTime
------new-list-nature-pageView
清晰明了的結(jié)構(gòu)，但是如果層級(jí)越深，類名就越長，當(dāng)然我們也可以簡寫，或者只取父元素和祖父元素的類名，另一個(gè)問題，頁面布局調(diào)整，就需要調(diào)整好多相關(guān)樣式，而且復(fù)用性極差
BEM命名
BEM即Block-Element_Modifier，Block是功能塊，Element是元素，Modifier是修飾符
菜單模塊.menu.menu-item.menu-item.active / .menu-item_active
BEM是一種很好的規(guī)范，我們從名字上就能看出來這個(gè)類名的作用，但是也很容易被濫用，很容易會(huì)被寫成B-E-E-M，類名太長，這樣就不合適了
oocss
oocss是把css看成一個(gè)單獨(dú)的css樣式，更寬泛的說，本身css就是oocss，因?yàn)槊恳粋€(gè)樣式都可以獨(dú)立出來，不過這樣并沒什么用，下面是一個(gè)按鈕的例子：
// 未經(jīng)處理的css
.btn{
display:inline-block;
font-size: 16px;
color: #fff;
line-height: 1.5;
border: 1px solid #ccc;
border-radius: 2em;
background-color: #eee;
}
// oocss處理
.inlineBlock{
display:inline-block;
}
.fontSize16{
font-size: 16px;
}
.border1{
border: 1px solid #ccc;
}
.whiteColor{
color: #fff;
}
.grayBgColor{
background-color: #ccc;
}
.submitBtn{
line-height: 1.5;
border-radius: 2em;
...
}
oocss的特點(diǎn)是把樣式分解為小的樣式，通過小的樣式之間的組合來渲染元素，這樣樣式的復(fù)用性很強(qiáng)，但是元素上寫了太多的類名，也著實(shí)不美觀
ooscss
ooscss是oocss和scss的組合，接著上面的例子，我們可以這樣改進(jìn)：
// ooscss處理%inlineBlock{
display:inline-block;}%fontSize16{
font-size: 16px;}%border1{
border: 1px solid #ccc;}%whiteColor{
color: #fff;}%grayBgColor{
background-color: #ccc;}.submitBtn{
@extend %inlineBlock;
@extend %fontSize16;
@extend %border1;
@extend %whiteColor;
@extend %grayBgColor;
line-height: 1.5;
border-radius: 2em;
...}
ooscss通過繼承來實(shí)現(xiàn)元素類名的減少化，當(dāng)然實(shí)際開發(fā)中，也不會(huì)出來這么分離的類，因此ooscss對(duì)于組件化開發(fā)還是比較友好的
布局
布局由原先的Table（原始時(shí)代，慶幸沒經(jīng)歷過）到Float + Position布局，之后是使用百分比和Rem實(shí)現(xiàn)的自適應(yīng)布局，典型的有Bootstrap；之后是@media實(shí)現(xiàn)的響應(yīng)式布局，到現(xiàn)在流行的Flex布局，以及Grid布局.
Ajax
ajax的出現(xiàn)可以說對(duì)前端是一次關(guān)鍵的轉(zhuǎn)折，提出了一種新的開發(fā)方式；數(shù)據(jù)請(qǐng)求的發(fā)展也兩年由于復(fù)雜業(yè)務(wù)的邏輯實(shí)現(xiàn)，使得傳統(tǒng)的Ajax使用起來比較繁瑣，比如callback hell；因此出現(xiàn)了Promise，可以通過鏈?zhǔn)秸{(diào)用的方式來實(shí)現(xiàn)callback，我以為這樣的改進(jìn)已經(jīng)最好的了，直到我看見Es6的Generator/yield 和 async/awite，WTF，像寫同步代碼一樣寫異步請(qǐng)求，可以這么簡潔，其實(shí)就是語法糖而已，但是這個(gè)糖比較甜(*^▽^*)
打包
就說幾個(gè)目前使用比較多的工具：
Gulp：基于流的自動(dòng)化構(gòu)建工具，相對(duì)于百度的Fis，就類似于sublime和ide的區(qū)別吧，而對(duì)比Grunt，Grunt 運(yùn)用配置的思想來寫打包腳本，Gulp 是用代碼方式來寫打包腳本，并且代碼采用流式的寫法，即gulp.task()，對(duì)于項(xiàng)目開發(fā)還是推薦Gulp，輕量，靈活；隨著模塊化和SPA應(yīng)用的項(xiàng)目越來越多，全新的webpack3（webpack2其實(shí)剛出世沒多久）或許是更好的選擇；
Webpack：Webpack 是一個(gè)打包工具，能將多個(gè)資源模塊打包成一個(gè)或少數(shù)文件；而Gulp/Grunt自動(dòng)化構(gòu)建工具并不能把所有模塊打包到一起，也不能構(gòu)建不同模塊之間的依賴圖，Webpack通過loader 和 plugin可以做一部分 gulp／grunt 能做的事，但是插件還是不如 gulp／grunt 的插件豐富；Webpack最復(fù)雜的地方就是配置了，這個(gè)多踩幾個(gè)坑，就好了啦。最近又看到了Parcel，零配置哦，對(duì)于新晉小將，抱著觀望的態(tài)度，為何不去嘗試一下呢
狀態(tài)管理
隨著前端從隨意化到工程化的演變，其特征更加的表現(xiàn)為：視圖組件化、功能模塊化與狀態(tài)管理，或許狀態(tài)管理你并沒有在使用，但是為了以后項(xiàng)目的擴(kuò)展，還是預(yù)留一下接口；在項(xiàng)目比較小的時(shí)候，我們經(jīng)常把一些數(shù)據(jù)放在localstorage中，其實(shí)這就是簡單狀態(tài)共享，而當(dāng)項(xiàng)目復(fù)雜起來之后，再使用localstorage就顯得不那么得心應(yīng)手了，我們就需要引入一個(gè)專門管理狀態(tài)的一個(gè)框架，首先這個(gè)框架的特點(diǎn)得有：
狀態(tài)能夠被不同組件之間共享。（早期的React中使用Props一層一層地傳遞或者通過公共父節(jié)點(diǎn)來傳遞。vue使用單向數(shù)據(jù)流的方式）
狀態(tài)能夠在任意地方被訪問和修改
狀態(tài)的修改應(yīng)該被記錄
有以下幾個(gè)狀態(tài)管理的框架，可以應(yīng)用于項(xiàng)目中：
Flux : 一種前端代碼思想， 寸志：圖解 Flux
Redux：React的好基友， Read Me · Redux
MobX：Redux的替代者， Introduction | MobX
Vuex：Vue的好基友， 狀態(tài)管理 — Vue.js
編輯器
我的編輯器改變之路，個(gè)人喜好
總結(jié)
在前端技術(shù)迅速變化的時(shí)代，要做的就是，把握現(xiàn)在，擁抱未來。
2018，你需要懂這些了
