原文地址:Thinking in Reacthtml
今天在翻閱 React 文檔,看到一篇名爲「Thinking in React」的文章以爲寫的很好。文章介紹瞭如何使用 React 構建一個應用,並非手把手教你如何構建 ,而是在教你應該如何思考 🤔。其中的一些點是我以前未曾考慮到的,所以在這裏作一個總結:react
Step 1 講的就是如何劃分 UI 爲 React 組件,其中談到一個觀點:組件化
Their Photoshop layer names may end up being the names of your React components!ui
以 Photoshop 圖層名稱命名 React 組件,我作過 UI 設計的工做,我以爲這種思路是很連貫的,在圖層命名時,你率先須要思考的一個問題是「這是什麼」,以把某個控件和其餘控件區分開來。所以當使用 React 開發時,組件的顆粒度就已經有了一個大致的劃分。設計
我特別喜歡 React 的組件化思想,將一個頁面拆分紅不一樣的組件,在將一個組件打散爲不一樣的小組件就像樂高同樣很是有秩序感,但我一開始常常會面臨的問題是,「決定組件顆粒度的大小」。一般狀況下,問題出在我是否須要對某個組件進一步拆分?個人經驗是思考「這個組件有 3 個以上的 DOM 元素組成,而且須要複用嗎?」這個問題,若是是,則說明須要從父組件拆分出來,變爲獨立的組件;code
文章建議構建 React 應用時,應該先將全部的數據都以 props
的方式傳遞,而後再去思考什麼樣的數據應該更改成 state
。整個文檔特別強調 state
的最小必要性原則,並給出了判斷的指南:component
state
;state
;props
或 state
計算獲得嗎?若是能夠,不要設置爲 state
;我想應該不少人據說過這些判斷條件,但彷佛不多人去討論爲何咱們要保障 React 應用內的 state
是最少限度的?這勾起了個人好奇。htm
通過一番探索,我得出的結論是,咱們之因此要讓組件只保留必要的 state
數據,是由於「state 會破壞 React 單向數據流的機制」。blog
讓咱們站在組件的角度思考,組件的 UI 應該是數據的反射,一個好的組件應該傻瓜的只根據接收的數據變化,不用操心其他的任何事情。可是一旦組件內部出現了 state
事情就不同了,組件變得不在單純,而且擁有了本身改變數據,而後再按照數據變化的特性。而當這樣的組件增多時,咱們想要找到「數據」和「UI」的映射關係就很是複雜了,這使得咱們不容易理解應用的更新邏輯,在發生錯誤時,沒法第一時間定位到問題發生的地點。開發
所以,經過保障 state
只在必要時被定義,或者將 state
經過各類方式妥善的管理,就是打造強壯 React 應用的關鍵。能夠說,正確地管理 state 就是開發完美 React 應用的關鍵。
參考資料:
Thinking in React
Common React.js mistakes: Unneeded state
You Probably Don't Need Derived State