摘要：譯的生命周期的使用場景原文鏈接作者翻譯上名這個圖片，就是組件的生命周期，從形成到銷毀的過程。這并不意味著沒有用。最常見的用例更新以響應(yīng)或更改。是否可以調(diào)用總結(jié)在理想的世界中，我們不會使用生命周期方法。

原文鏈接：React Lifecycle Methods- how and when to use them

作者：Scott DomesFollow Front-End/Mobile Developer @ MuseFind.
翻譯：johannlai

上名這個圖片，就是 React 組件的生命周期，從形成 (pre-mounting)到銷毀 (unmounting)的過程。

React 的優(yōu)雅之處就在于，它把復(fù)雜的 UI 分解成很小的部分。 我們不僅僅可以劃分我們的應(yīng)用，而且我們還可以定制我們每一個組件。

通過組件的生命周期方法，我們可以控制當(dāng)UI的每個微小部分渲染，更新，考慮重新渲染，然后完全消失時會發(fā)生什么事情。

讓我們開始吧！

您的組件將很快就會出現(xiàn)在屏幕上面。這個大塊的渲染功能與其所有精美的 JSX 一樣，即將被調(diào)用。那你想做什么？

答案是... 可能不是很多。 但是 componentWillMount 的確用處不會太大。

關(guān)于 componentWillMount 的事情是，沒有組件可以玩，所以你不能做任何涉及DOM的事情。（譯者：因為還沒渲染組件）

此外，自從您的組件的構(gòu)造函數(shù)（ constructor ）被調(diào)用以來，沒有任何變化，但是，無論如何，您應(yīng)該在其中設(shè)置組件的默認(rèn)配置。

  export default calss Sidebar extends Component {
    constructor(props) {
      super(props)
      this.state = {
        analyticsOpen: false,
        requirementsOpen: false,
        barndInfoOpen: false
      }
    }
  }

現(xiàn)在您的組件處于默認(rèn)位置，幾乎所有的東西都應(yīng)該由其余的組件代碼來處理，而不需要額外的生命周期方法。

例外是只能在運行時完成的任何設(shè)置，說白了也就是連接到外部 API 。舉個栗子，如果您的應(yīng)用程序使用Firebase，則需要在應(yīng)用程序首次掛載（mounting）時進行設(shè)置。

但關(guān)鍵是，這樣的配置應(yīng)該在應(yīng)用程序的最高級別組件（根組??件）。 這意味著99％的組件應(yīng)該不能使用 componentWillMount 。

您可能會看到使用componentWillMount的人啟動AJAX調(diào)用來加載組件的數(shù)據(jù)。 千萬不要這樣做，我們馬上就會聊到這個。

接下來，更有用的方法是：
最常見的用例： 您的根組件中的應(yīng)用程序配置。
可以調(diào)用setState：不要。改用默認(rèn)狀態(tài)（ default state ）。

現(xiàn)在我們在說話您的組件在那里，掛載了并準(zhǔn)備好使用了。怎么辦？

這里是您加載數(shù)據(jù)的位置。我會讓 Tyler McGinnis 解釋為什么：

You can’t guarantee the AJAX request won’t resolve before the component mounts. If it did, that would mean that you’d be trying to setState on an unmounted component, which not only won’t work, but React will yell at you for. Doing AJAX in componentDidMount will guarantee that there’s a component to update.
您不能保證在組件掛載之前，AJAX請求將 resolve 。如果這樣做，那意味著你會嘗試在一個未掛載的組件上設(shè)置StState，這不僅不會起作用，反而 React 會對你大喊大叫。在componentDidMount中執(zhí)行AJAX將保證有一個要更新的組件。

ComponentDidMount 也可以在做很多你在沒有組件的時候不能做的事情。 下面舉幾個栗子：

繪制您剛剛渲染的元素

從元素集合初始化 masonry 網(wǎng)格布局

增加事件監(jiān)聽器

基本上，你可以在這里做任何剛剛因為沒有 DOM 而不能做的設(shè)置，并且可以獲取你所需要的全部數(shù)據(jù)。

最常見的用例： 啟動AJAX調(diào)用，以加載組件的數(shù)據(jù)。
可以調(diào)用setState：是的。

我們的組成部分做得很好，突然之間，一大堆新的 props 到達了，使到組件處于混亂狀態(tài)。

很有可能一些由父組件的componentDidMount加載的數(shù)據(jù)終于到達，并被傳遞下來。

在我們的組件對新的 props 進行任何操作之前，將調(diào)用componentWillReceiveProps，并將下一props 作為參數(shù)。

現(xiàn)在，我們正在處于一個很有趣的地方，我們可以訪問下一個 props （通過nextProps）和我們當(dāng)前的 props （通過this.props）。

下面這些是我們在componentWillReceiveProps 中需要做的：

檢查哪些props 會改變（使用componentWillReceiveProps的大警告 - 有時它什么也沒有改變時被調(diào)用; React 只是想做一個檢查）

如果props 會以重要的方式改變props，就行事。

下面是一個例子。假設(shè)我們在上面提到，我們有一個 元素。假設(shè)我們根據(jù)this.props.percent 繪制一個很好的圓形圖形。

ps` ，如果百分比發(fā)生變化，我們想重新繪制網(wǎng)格。以下是代碼：

  componentWillReceiveProps( nextProp ) {
    if(this.props.percent !== nextProps.percent) {
      this.setUpCirCle(nextProps.percent)
    }
  }

注意：在初始渲染時不調(diào)用 componentWillReceiveProps 。
我的意思是在技術(shù)上，組件正在接收props，但沒有任何舊的props要比較，所以...不算。

最常見的用例：根據(jù)特定的props，更改來觸發(fā)狀態(tài)（state）轉(zhuǎn)換。
是否可以調(diào)用setState: Yes

現(xiàn)在我們的組件越來越緊張了。

我們有新的props。典型的React教條說，當(dāng)一個組件接收到新的props或新的state時，它應(yīng)該更新。

但是我們的組件有點焦慮，首先要求許可。

這是我們所需要的 —— shouldComponentUpdate方法，以 nextProps 為第一個參數(shù)，nextState是第二個參數(shù)：

shouldComponentUpdate(nextProps, nextState) {
  return this.props.engagement !== nextProps,engagement
    || nextState.input !== this.state.input
}

shouldComponentUpdate應(yīng)該總是返回一個布爾值 —— 就像這個問題的答案
--> “我可以渲染嗎？”
--> 是的，小組件，你可以去渲染。

默認(rèn)情況下它總是返回true。

但是，如果您擔(dān)心浪費渲染
其實，shouldComponentUpdate是提高性能的好地方。

我以這種方式寫了一篇關(guān)于使用shouldComponentUpdate的文章 - 看看：

How to Benchmark React Components: The Quick and Dirty Guide

在這篇文章中，我們談?wù)撘粋€有很多fields的表格。問題是，當(dāng)表重新渲染時，每個字段也將重新渲染，速度很慢，效率很低。

ShouldComponentUpdate允許我們說：只有當(dāng)所關(guān)心的props的改變的時候才更新！

但請記住，如果您設(shè)置并忘記它可能會導(dǎo)致重大問題，因為您的React組件將無法正常更新。所以謹(jǐn)慎使用。

最常見的用例： 當(dāng)您的組件 re-render (重新渲染)時，完全控制。
是否可以調(diào)用setState: No

哇，什么過程現(xiàn)在我們承諾更新。"希望我在重新渲染之前先做任何事情?" 我們的組件問。不，我們說。停止打擾我們。在整個MuseFind代碼庫中，我們從不使用componentWillUpdate。在功能上，它基本上與componentWillReceiveProps相同，除非你不允許調(diào)用this.setState。

如果您正在使用shouldComponentUpdate 并且需要在props更改時執(zhí)行某些操作，那么componentWillUpdate就會很有意義。

最常見的用例： 在一個也有shouldComponentUpdate（但不能訪問以前的props）的組件上使用而不是componentWillReceiveProps。

是否可以調(diào)用setState: No

很棒！小組件！

在這里我們可以和componentDidMount做同樣的事情 ： 重新設(shè)置我們的 masonry 布局，重繪我們的canvas,等。

等等 - 我們沒有在componentWillReceiveProps中重畫我們的canvas嗎？

是的我們沒有做。原因是：在componentDidUpdate中，你不知道為什么它更新。

因此，如果我們的組件接收到的canvas數(shù)量超過了與我們的canvas相關(guān)的props，我們不希望每次更新時都會浪費時間重繪canvas上面。

這并不意味著componentDidUpdate沒有用。要回到我們的 masonry 布局示例，我們要在DOM自身更新后重新排列網(wǎng)格，所以我們使用componentDidUpdate來完成。

componentDidUpdate() {
  this.createGrid()
}

最常見的用例：更新DOM以響應(yīng)prop或state更改。
是否可以調(diào)用setState: Yes

幾乎結(jié)束了~

你的組件將會消失。也許永遠，這很傷心。

在它之前，它詢問你是否有任何最后的請求。

在這里，您可以取消任何傳出的網(wǎng)絡(luò)請求，或刪除與組件關(guān)聯(lián)的所有事件監(jiān)聽器。

基本上，清理任何只涉及到有關(guān)的組件的哦事情，
當(dāng)它走了，它應(yīng)該完全消失。

componentWillUnmount() {
  window.removeEventListen("resize", this,resizeListener)
}

最常見的用例：清理組件中殘留的殘留物。
是否可以調(diào)用setState: No

在理想的世界中，我們不會使用生命周期方法。我們所有的渲染問題都將通過state 和 prop進行控制。

但它事實上并不是一個理想的世界，有時您需要更準(zhǔn)確地控制組件更新的方式和時間。

謹(jǐn)慎使用這些方法，并小心使用。我希望這篇文章有助于闡明什么時候和如何使用生命周期方法。