很多時(shí)候 我們閱讀文檔的時(shí)候 都是先把 tutorial 看一篇 把代碼跑一篇 然后跟著 documentation 一章一章的閱讀 這是我以前的做法 也是我以前覺得比較好的一個(gè)做法 畢竟我又看了 有親手做了一次?
這個(gè)心理暗示知道我看了一本 <React.js 小書> 這本 ReactJs 的入門小書我才知道 我以前看文檔的方法都錯(cuò)了 因?yàn)槲铱赐曛?只是到其中的語言語法和函數(shù) 具體應(yīng)該什么時(shí)候用 為什么用 還能優(yōu)化嗎 這三個(gè)問題 我都沒有思考過 我只是把別人的代碼套到業(yè)務(wù)邏輯上 然后就沒有自己的思考了
前端框架涌現(xiàn) 面對(duì)這么多的庫(kù)和框架 我們只有對(duì)這些庫(kù)和框架解決的問題有深入的了解和思考之后 我們才能得心應(yīng)手的使用它們 并且對(duì)新出來的框架也不會(huì)太過迷茫 因?yàn)榇蟛糠值目蚣芩鼈兘鉀Q的問題都是以同一個(gè)問題
例如要實(shí)現(xiàn)一個(gè)點(diǎn)贊功能 我們先把 baseline 的結(jié)構(gòu)搭建出來 然后得思考問題了:讓這個(gè)結(jié)構(gòu)具備一定的可復(fù)用 實(shí)現(xiàn)簡(jiǎn)單的組件化? 接下來 狀態(tài)改變->構(gòu)建新的 DOM 元素更新頁面 接著抽象出公共的組件類 優(yōu)化代碼 優(yōu)化性能
組件化可以幫助解決前端結(jié)構(gòu)的復(fù)用性問題 整個(gè)頁面可以由這樣不同的組件組合嵌套構(gòu)成?
一個(gè)組件有自己的顯示形態(tài)行為 組件的顯示形態(tài)和行為可以由數(shù)據(jù)狀態(tài)( state) 和配置參數(shù)(props)共同決定 數(shù)據(jù)狀態(tài)和配置參數(shù)的改變都會(huì)影響到這個(gè)組件的顯示狀態(tài)
當(dāng)數(shù)據(jù)變化的時(shí)候 組件的顯示需要更新 所以如果組件化的模式能提供一種高效的方式自動(dòng)化的幫助我們更新頁面 那也就可以大大的降低我們代碼的復(fù)雜度 帶來更好的可維護(hù)性
經(jīng)過以上的鋪墊和思考 然后再去讀文檔的內(nèi)容就會(huì)理解的透徹了
還有一本<Build Your Own AngularJs> 這本書也是一本不可多得的書 多讀幾遍 一定會(huì)對(duì)前端框架的架構(gòu)有更深的理解
同時(shí) 發(fā)現(xiàn)問題 思考問題 優(yōu)化代碼 這個(gè)步驟來閱讀文檔 不失為一個(gè)很好的方法
