從我畢業到現在也差不多快一年半了，想要找個地方沉澱下自己，同時也希望大佬們，指出我錯誤的思考。 我直接把我自己寫的 ppt 的東西複製過來了
特點
1.宣告式設計 −採用宣告正規化，可以輕鬆描述應用。
2.高效 −通過對DOM的模擬，最大限度地減少與DOM的互動。
3.靈活 −可以與已知的庫或框架很好地配合。
4.元件 − 通過 React 構建元件，使得程式碼更加容易得到複用，能夠很好的應用在大專案的開發中。
5.單向響應的資料流 − React 實現了單向響應的資料流，副作用少，易於追蹤問題和維護
複製程式碼定義元件的多種方式
createClass
// es5 環境下
var Contacts = React.createClass({
render() {
return (
<div>1</div>
)
}
})
複製程式碼React.Component
// es6 方式需要編譯
class Contacts extends React.Component {
constructor(props) {
super(props);
}
render () {
return <div>1</div>
}
}
複製程式碼無狀態函式式元件
// 適合純渲染元件
const Contacts = (props) => <div>1</div>
複製程式碼生命週期
貼張官方圖
各階段函式說明
Mounting(掛載)
- getDefaultProps：獲取預設 props
- getInitialState | | constructor: 都是定義預設的 state，只不過是兩種定義元件的方式
componentWillMount: 即將廢棄,在render之前呼叫，所以就算在這個方法中呼叫setState也不會觸發重新渲染（re-render）- render: 最核心的方法: 返回需要渲染的東西
- componentDidMount：
- 此時已獲取到真實 dom， jquery 。
- 不過一般都用做 資料請求，此時 setState 可以重新觸發渲染
- 如果一個元件有兄弟元件、父子元件那麼執行該方法的順序：排在面的子元件， 所有子元件執行完再父親元件，都是因為遞迴渲染的特性
Updating(更新) 將會在 props或 state 更新後呼叫
componentWillReceiveProps: 即將廢棄， 由 getDerivedStateFromProps 替代,更新 state 的值、比較 nextProps和 this.props 避免重複渲染- shouldComponentUpdate: 判斷元件是否應該重新渲染，預設為 true，主要用於效能優化
- componentWillUpdate: state 或者 props 更新後 re-render 之前呼叫。不可以在此 setSate ， 會溢位棧造成瀏覽器卡死 render()
- componentDidUpdate：可以操作dom 發起 網路請求
解除安裝階段
componentWillUnmount: 當我們的元件被解除安裝或者銷燬了就會呼叫，我們可以在這個函式裡去清除一些定時器，取消網路請求, 在 spa 中比較常見
元件通訊
父子： 通過 props
子父： 回撥函式，通過更新 父親的 state 來更新
子子： 1. emit 的方式 釋出訂閱 2. 通過父親元件來中轉
跨層級元件：context context是一個全域性變數,像是一個大容器,在任何地方都可以訪問到。
但是 當中間某個元件 shouldComponentUpdate 設定為 false 的時候就 gg 了。
原因是 shouldComponentUpdate 會切斷子樹的 rerender，當 state 或 props
沒有發生變化時，可能意外中斷上層 context 傳播。也就是當 shouldComponentUpdate
返回 false 時，context 的變化是無法被底層所感知的。
三方狀態庫： redux、rematch (二次封裝redux)、mobx、smobx，
這些東西藉助一句話，"如果你不知道是否需要 Redux，那就是不需要它。"
複製程式碼redux ?
三大原則
- 單一資料來源
- State 只讀的 （此處可能會有歧義）
- 用純函式執行修改
結合 react 使用， 一張我畫的簡圖代表個人理解
核心概念
路由
更多
- 高階元件
- graphql
- react native
- 函數語言程式設計
結語
2019 年基本計劃是 寫一個不錯的個人專案， 同時有機會去了解下底層實現，也去學習 vue 對比下。 欺騙一下自己： 新的一年，新的自己