首頁 >web前端 >js教程 >對於react你知道多少?關於react的注意事項總結

對於react你知道多少?關於react的注意事項總結

寻∝梦
寻∝梦原創
2018-09-11 11:23:051481瀏覽

本篇文章主要的講述了關於react中的需要知道的事項的,如容器組件還有組件的屬性、setState 非同步性等內容,下面就讓我們一起來看這篇文章吧


容器性元件(container component)和展示性元件(presentational component)

使用React編寫元件時,我們需要有意識地將元件分割為容器性元件(container component)和展示性元件(presentational component),這有助於我們在編寫元件時,更明確這個元件應該負責哪些事情。

容器性元件,負責業務流程邏輯的處理,如發送網路請求,處理請求數據,將處理過的資料傳遞給子元件的Props使用。同時,容器性元件提供來源資料的方法,以Props方式傳遞給子元件,當子元件的狀態變更引起來源資料的變化時,子元件會透過呼叫容器性元件提供的方法來同步這些變化。

展示性元件,負責元件的外表,也就是元件如何渲染,具有強烈的內聚性。展示性元件不關心渲染時所使用的元件屬性(Props)是如何取得的,它只要知道有了這些Props後,元件應該如何渲染就足夠了。屬性如何獲取,是容器性元件負責的事情。當展示性元件狀態的變化需要同步到來源資料時,就需要呼叫容器性元件中的方法,這個方法一般也是透過Props傳遞給展示性元件。

例如,一個Todo項目,有一個Todo元件和一個TodoList元件,Todo元件是一個容器性元件,負責從伺服器端取得待辦事項列表,取得到待辦事項列表後傳遞給TodoList顯示。在TodoList中新建一項待辦事項後,需要透過TodoList 的 Props,呼叫Todo元件中儲存待辦事項的方法,將新建的待辦事項同步到伺服器端。

容器性元件和展示性元件可以相互嵌套,一個容器性元件可以包含多個展示性元件和其他的容器性元件;一個展示性群組將也可以包含容器性元件和其他的展示性組件。這樣的分工,可以使與元件渲染無直接關係的邏輯由容器性元件集中負責,展示性元件只專注於元件的渲染邏輯,從而使展示元件更容易被重複使用。對於非常簡單的頁面,一般只要一個容器性元件就足夠了;但對於負責頁面,則需要多個容器性元件,否則所有的業務邏輯都在一個容器性元件中處理的話,會導致這個元件非常複雜,同時這個元件所獲得的來源數據,可能需要經過很多層的元件Props的傳遞,才能到達最終使用的展示性元件。

Props、State和元件的普通屬性

Props、State的概念都很清晰,元件的普通屬性是指在元件中直接掛載到this下的屬性。其實,Props和State也是元件的兩個普通屬性,因為我們可以透過this.props 和 this.state 直接取得。那麼Props、State 和 元件的其他普通屬性,分別應該在什麼場景下使用呢?

Props和State都是用於元件渲染的,也就是說,一個元件最終長成什麼樣,取決於這個元件的Props和State。 Props和State的變化都會觸發元件的render方法。但這兩者也是有差別的。 Props是唯讀的數據,它是由父元件傳遞過來的;而State是元件內部自己維護的狀態,是可變的。 State可以根據Props的變化而變化。如果元件中還需要其他屬性,而這個屬性又與元件的渲染無關(也就是render方法中不會用到),那就可以把這個屬性直接掛在this下,而不是作為元件的一個狀態。

例如,元件中需要一個計時器,每隔幾秒鐘改變一下元件的狀態,就可以定義一個this.timer屬性,以備在componentWillUnmount時,清除計時器。 (想看更多就到PHP中文網React參考手冊欄位學習)

setState 非同步性

React官網提到,this.state和this.props的更新可能是異步的,React可能會出於效能考慮,將多個setState的調用,合併到一次State的更新中。所以,不要依賴this.props 和 this.state的值來計算下一個狀態。引用官網的一個程式碼範例:

// Wrong
this.setState({
  counter: this.state.counter + this.props.increment,
});

如果一定要這麼做,可以使用另一個以函數作為參數的setState方法,這個函數的第一個參數是前一個State,第二個參數是目前接收到的最新Props。如下圖所示:

// Correctthis.setState(function(prevState, props) {
  return {
    counter: prevState.counter + props.increment
  };
});

在调用setState之后,也不能立即使用this.state获取最新状态,因为这时的state很可能还没有被更新,要想保证获取到的state是最新的state,可以在componentDidUpdate中获取this.state。也可以使用带用回调函数参数版本的setStatesetState(stateChange, [callback]),回调函数中的this.state会保证是最新的state。

componentWillReceiveProps

当组件的属性可能发生变化时,这个方法会被调用。这里说可能,是因为父组件render方法每次被调用时,子组件的这个方法都会被调用(子组件第一次初始化时除外),但并不一定每次子组件的属性都会发生变化。如果组件的State需要根据Props的变化而变化,那么这个方法就是最适合这个这个逻辑的地方。例如当Props变化时,组件的State需要重置,就可以在这个方法中调用this.setState()来重置状态。需要注意,在这个方法中调用this.setState()并不会重新触发componentWillReceiveProps的调用,也不会导致render方法被触发两次。一般情况下,接收到新Props会触发一次render,调用this.setState也会触发一次render,但在componentWillReceiveProps中调用this.setState,React会把原本需要的两次render,合并成一次。

shouldComponentUpdate

这个方法常作为优化React性能使用。当shouldComponentUpdate返回false时,组件本次的render方法不会被触发。可以通过在这个方法中比较前后两次state或者props,根据实际业务场景决定是否需要触发render方法。

React提供了一个React.PureComponent组件,这个组件重写了shouldComponentUpdate,会对前后两次的state和props进行浅比较,如何不一致,才会返回true,触发后续的render方法。这里的浅比较指,只会对state和props的第一级属性进行比较(使用!==),这满足一般的使用场景。如果你的组件继承了React.PureComponent,但在setState时,传入的state是直接修改的原有state对象,就会因为依然满足浅比较的条件,而不会重新触发render方法,导致最终DOM和state不一致。例如state={books: ['A','B']},在setState时,使用this.setState({name: this.state.books.push('C')})直接修改books对象,这样虽然books内容发生了修改,但因为对象引用并没有变化,所以依然满足浅比较条件,不会触发render方法。

一般情况下,让shouldComponentUpdate返回默认的true是不会有太大问题的。虽然这样可能导致一些不必要的render方法被调用,但render方法直接操作的是虚拟DOM,只要虚拟DOM没有发生变化,并不会导致实体DOM的修改。而JS慢是慢在实体DOM的修改上。只要你的render方法不是很复杂,多调用几次render方法并不会带来多大的性能开销。

render

父组件每次render方法被调用,或者组件自己每次调用setState方法,都会触发组件的render方法(前提是shouldComponentUpdate使用默认行为,总是返回true)。那么组件每次render,是不是都会导致实体DOM的重新创建呢?答案是,不是!

React之所以比直接操作DOM的JS库快,原因是React在实体DOM之上,抽象出一层虚拟DOM,render方法执行后,得到的是虚拟DOM,React 会把组将当前的虚拟DOM结构和前一次的虚拟DOM结构做比较,只有存在差异性,React才会把差异的内容同步到实体DOM上。如果两次render后的虚拟DOM结构保持一致,并不会触发实体DOM的修改。

React速度快的原因,还有一个是它出色的Diff算法。标准的比较两棵树的Diff算法的时间复杂是 O(n3) 。而React基于非常符合实际场景的两个假设,就将Diff算法的时间复杂度降到了接近O(n)。这两个假设是:

  1. 如果两个组件或元素类型不同,那么他们就是完全不同的树,不需要再比较他们的子节点。例如,59da28f5dfb08cc4320eedd48bbc94b6c87d292abd3767e5a975339e763d52ff将产生是两个完全的树状结构;e388a4556c0f65e1904146cc1a846beechildren94b3e26ee717c64999d7867364b1b4a3e388a4556c0f65e1904146cc1a846beechildren94b3e26ee717c64999d7867364b1b4a3也是两个完全不同的树。这种情况下,组件会被完全重建,旧的DOM节点被销毁,组件经历componentWillUnmount(),然后重新创建一棵新树, 组件经历 componentWillMount() 和  componentDidMount()

  2. 可以为组件或元素设置key属性,key用来标识这个组件或元素。key不需要全局唯一,只需要在兄弟组件或兄弟元素间保证唯一性就可以。key常用到集合(List)元素中。例如:

<ul><li key=&#39;a&#39;>Book A</li><li key=&#39;b&#39;>Book B</li></ul>

当在第一个位置插入一条记录Book C 时,

<ul><li key=&#39;c&#39;>Book C</li><li key=&#39;a&#39;>Book A</li><li key=&#39;b&#39;>Book B</li></ul>

由于有key的标识,React知道此时新增了一条记录,会创建一个新的25edfb22a4f469ecb59f1190150159c6元素,并把它插入到列表中的第一个位置。如果没有设置key,React并不知道是新增了一条记录,还是原来的两条记录完全替换成新的三条记录,或者其他更加复杂的修改场景。React需要自上而下的比较每一条记录,这样每次比较节点都不同,所以需要修改两次节点,然后再新增一个节点,效率明显要差很多。

这里同时揭露了另一个问题,不要使用元素在集合中的索引值作为key,因为一旦集合中元素顺序发生改变,就可能导致大量的key失效,进而引起大量的修改操作。

如何发送网络请求

当我们需要从服务器获取数据时,我们应该在组件的哪一个生命周期方法中发送网络请求呢?React官网上提到,可以在componentDidMount中发送网络请求,这也是一般情况下的最佳实践。有些人也会把发送网络请求放在componentWillMount中,并且认为这个方法先于componentDidMount调用,所以可以更快地获取数据。个人认为,这种使用方法一般也是没有问题的,但在一些场景下会出现问题,比如需要在服务器端渲染时,componentWillMount会被调用两次,一次是在Server端,一次是在Client端。可参考这篇文章。

本篇文章到这就结束了(想看更多就到PHP中文网React使用手册栏目中学习),有问题的可以在下方留言提问。

以上是對於react你知道多少?關於react的注意事項總結的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn