React v16.3.0: New lifecycles and context API

zombieda 發布于2019-08-22 15:52 / 824人閱讀

摘要：為管理提供了一個新的方案，它為字符串提供了方便，并且沒有任何缺點司徒正美注意除了新的外，回調將繼續得到支持。例如司徒正美通常會將傳遞給它們包裝的組件。

幾天前，我們寫了一篇關于即將到來的對我們的傳統生命周期方法的變更的文章，包括逐步遷移策略。在React 16.3.0中，我們添加了一些新的生命周期方法來幫助遷移。我們還引入了新的API，用于長時間請求的特性:一個官方的上下文API、一個ref轉發API和一個更語意化的ref API。

請繼續閱讀，了解更多關于這個版本的信息。

官方認證的 Context API

多年來，React為Context提供了一個實驗性的API。雖然它是一個強大的工具，但是由于API中固有的問題，它的使用是不受歡迎的，因此我們打算用一個更好的API來替代這實驗性的API。

React 16.3引入了一個新的Context API，它更高效，同時支持靜態類型檢查和深度更新。

注意
舊的ContextAPI 將繼續保留到React 16.x，所以您將有時間遷移。

下面是一個示例，說明如何使用新的上下文API注入“主題”:

## by 司徒正美
const ThemeContext = React.createContext("light");

class ThemeProvider extends React.Component {
  state = {theme: "light"};

  render() {
    return (
      
        {this.props.children}
      
    );
  }
}

class ThemedButton extends React.Component {
  render() {
    return (
      
        {theme =>

createRef API

以前，React提供了兩種管理refs的方法:字符串ref API和回調ref API。盡管字符串ref API比較方便，但是它有幾個缺點，所以我們的官方推薦是使用回調ref。

React 16.3為管理refs提供了一個新的方案，它為字符串ref提供了方便，并且沒有任何缺點:

## by 司徒正美

class MyComponent extends React.Component {
  constructor(props) {
    super(props);

    this.inputRef = React.createRef();
  }

  render() {
    return ;
  }

  componentDidMount() {
    this.inputRef.current.focus();
  }
}

注意

除了新的createRef API外，回調refs將繼續得到支持。

您不需要在組件中替換回調refs。它們稍微靈活一些，因此它們將繼續作為一個高級特性。

forwardRef API

高階組件(或HOCs)是在組件之間重用代碼的常用方法?；谏厦娴闹黝}上下文示例，我們可能會創建一個臨時對象，將當前的“主題”作為一個屬性注入:

## by 司徒正美

function withTheme(Component) {
  return function ThemedComponent(props) {
    return (
      
        {theme => }
      
    );
  };
}

我們可以使用上述特殊的方式將組件連接到主題上下文，而不必直接使用主題上下文。例如:

## by 司徒正美

class FancyButton extends React.Component {
  buttonRef = React.createRef();

  focus() {
    this.buttonRef.current.focus();
  }

  render() {
    const {label, theme, ...rest} = this.props;
    return (
      
    );
  }
}

const FancyThemedButton = withTheme(FancyButton);

// We can render FancyThemedButton as if it were a FancyButton
// It will automatically receive the current "theme",
// And the HOC will pass through our other props.
;

HOCs通常會將props傳遞給它們包裝的組件。不幸的是，refs沒有沖透進去。這意味著如果我們使用FancyThemedButton，我們就不能將ref添加到FancyButton中，因此我們無法調用focus()。

新的代理API通過提供一種方法來攔截一個ref，并將其轉發為一個普通的props，從而解決了這個問題:

## by 司徒正美

function withTheme(Component) {
  // Note the second param "ref" provided by React.forwardRef.
  // We can attach this to Component directly.
  function ThemedComponent(props, ref) {
    return (
      
        {theme => (
          
        )}
      
    );
  }

  // These next lines are not necessary,
  // But they do give the component a better display name in DevTools,
  // e.g. "ForwardRef(withTheme(MyComponent))"
  const name = Component.displayName || Component.name;
  ThemedComponent.displayName = `withTheme(${name})`;

  // Tell React to pass the "ref" to ThemedComponent.
  return React.forwardRef(ThemedComponent);
}

const fancyButtonRef = React.createRef();

// fancyButtonRef will now point to FancyButton
;

組件生命周期鉤子的變化

React的類組件API已經存在多年，幾乎沒有變化。但是，當我們為更高級的特性(例如錯誤邊界和即將到來的異步渲染模式)添加支持時，我們以它本來沒有打算的方式來擴展這個模型。

例如，在當前的API中，用一些非尋常的手段來阻止初始渲染是很容易的。在某種程度上，這是因為有太多的鉤子來完成這項既定的任務，而且還不清楚哪一個是最好的。我們已經注意到錯誤處理的中斷行為通常不會被考慮，并且可能導致內存泄漏(這也會影響即將到來的異步渲染模式)。當前的類組件API也使其他的工作變得復雜，比如我們的代碼優化器（Prepack）的工作。

componentWillMount, componentWillReceiveProps, componentWillUpdate這些鉤子很容易引發問題，并且也嚴重擾亂React的生命周期。基于這些原因，我們將廢棄這些方法，以支持更好的替代方案。

我們認識到這一變化將影響許多現有的組件。因此，遷移路徑將盡可能平緩，并提供遷移方案。(在Facebook，我們擁有5萬多個React組件。我們也依賴于一個漸進的發布周期!

注意

棄用警告將在React16以后的版本中啟用，一直保留到17發布時。

即使在React17中，仍然可以使用它們，但是它們將添加“UNSAFE_”前綴，以表明它們可能導致問題。我們還準備了一個自動化的腳本，以便現有代碼中重命名它們。

除了廢棄不安全的生命周期鉤子外，我們還增加了一些新的生命周期鉤子:

getDerivedStateFromProps 用來componentWillReceiveProps。

getSnapshotBeforeUpdate，用在更新前從DOM中安全地讀取屬性。

StrictMode 組件

是一種專門用于暴露潛在問題的工具。與一樣，將不會渲染到視圖中。它能為其子組件激活額外的檢查和警告。

注意

檢查只在開發模式下運行;它們不會影響生產構建。

雖然嚴格的模式不可能捕獲所有的問題(例如某些類型的竄改)，但它可以幫助很多人。如果您在嚴格的模式下看到警告，這些事情很可能會導致異步渲染的錯誤。

在16.3版本中，StrictMode幫助:

識別具有不安全生命周期鉤子的組件。

關于遺留字符串ref API用法的警告。

檢測意想不到的副作用

云服務器 GPU云服務器 lifecycles Lifecycle contexts Context

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/93820.html

React組件生命周期

摘要：組件生命周期此文章適合之前的版本，，添加了一些新的生命周期函數，同時準備廢棄一些會造成困擾的生命周期函數。每個生命周期階段調用的鉤子函數會略有不同。 React組件生命周期此文章適合 React@17 之前的版本，React@16.3.0，添加了一些新的生命周期函數，同時準備廢棄一些會造成困擾的生命周期函數。所有如果在React@17 發布之前，這篇文章還是適用的。新的生命周期請看官...

mgckid 2019-08-20 10:42 評論0 收藏0
React組件設計模式-Provider-Consumer

摘要：和是成對出現的，每一個都會對應一個。而每一對都是由創建出來的。是一個普通的組件，當然，是需要位于組件的上層。又聲明了這個范圍的數據結構。解決嵌套問題的方式也更優雅。即使這一對的于另一對的的數據結構和值的類型相同，這個也讓能訪問那個的上下文。我們都知道，基于props做組件的跨層級數據傳遞是非常困難并且麻煩的，中間層組件要為了傳遞數據添加一些無用的props。而React自身早已提供了...

CKJOKER 2019-08-23 18:00 評論0 收藏0
ReactV16.3，即將更改的生命周期

摘要：我們目前的計劃是為不安全生命周期引入別名，和。從現在開始，只有新的生命周期名稱將起作用。從版本開始，更新以響應更改的推薦方法是使用新的靜態生命周期。注釋：本文是根據React的官方博客翻譯而成（文章地址：https://reactjs.org/blog/2018...）。主要講述了React之后的更新方向，以及對之前生命周期所出現的問題的總結，之后的React將逐步棄用一些生命周期和...

wendux 2019-08-22 16:28 評論0 收藏0
React中的“蟲洞”——Context

摘要：理論上，通過一層層傳遞下去當然是沒問題的。不過這也太麻煩啦，要是能在最外層和最里層之間開一個穿越空間的蟲洞就好了。使用看起來很高大上的使用起來卻異常簡單。就像中的全局變量，只有真正全局的東西才適合放在中。當我們寫React時，我們總是通過改變State和傳遞Prop對view進行控制，有時，也會遇到一點小麻煩。背景但是隨著我們的應用變的越來越復雜，組件嵌套也變的越來越深，有時甚至...

muddyway 2019-08-19 17:54 評論0 收藏0
Glide的源碼分析(一) Activity的生命周期與圖片加載的關系

摘要：從這段代碼入手分析分析從這段代碼可以看出無論傳入的是還是或者干脆傳入或都會調用這個方法而這個方法生成兩個對象對象，并把它加到上對象這兩個對象擁有共同的對象對象，當系統調用的生命周期，的生命周期隨之被調用來處理列表，將的生命周期與的生命周期聯從這段代碼入手分析Glide Glide.with(context) .load(url) .placehol...

Kosmos 2019-08-16 10:55 評論0 收藏0