摘要：為了使用它們，您可以向組件添加一個屬性，該屬性的值是一個回調函數，它將接收底層的元素或組件的已掛接實例，作為其第一個參數。通常最好使用另一個生命周期方法，而不是依賴這個回調函數，但是很高興知道它存在。

（在 React 里面，你可以知道也可以不知道的事, 但是你會發現他們確實很有用）

根據記錄，問這些問題可能不是深入了解他們在使用 React 方面的經驗的最佳方式。
之所以標題是《 React 常見的面試題》，其實只是想起一個比《在 React 里面，你可以知道也可以不知道的事, 但是你會發現他們確實很有用》要簡單明了的標題而已。

原文鏈接：React Interview Questions

作者： Tyler.Google Developer Expert and a partner at React Training where we teach React online

翻譯：Johann Lai

當調用 setState 時，React會做的第一件事情是將傳遞給 setState 的對象合并到組件的當前狀態。這將啟動一個稱為和解（reconciliation）的過程。和解（reconciliation）的最終目標是以最有效的方式，根據這個新的狀態來更新UI。 為此，React將構建一個新的 React 元素樹（您可以將其視為 UI 的對象表示）。
一旦有了這個樹，為了弄清 UI 如何響應新的狀態而改變，React 會將這個新樹與上一個元素樹相比較（diff）。

通過這樣做， React 將會知道發生的確切變化，并且通過了解發生什么變化，只需在絕對必要的情況下進行更新即可最小化 UI 的占用空間。

簡單地說，一個 React element 描述了你想在屏幕上看到什么。換個說法就是，一個 React element 是一些 UI 的對象表示。

一個 React Component 是一個函數或一個類，它可以接受輸入并返回一個 React element t（通常是通過 JSX ，它被轉化成一個 createElement 調用）。

有關更多信息，請查看 React Elements vs React Components

如果您的組件具有狀態( state )或生命周期方法，請使用 Class 組件。否則，使用功能組件

refs 就像是一個逃生艙口，允許您直接訪問DOM元素或組件實例。為了使用它們，您可以向組件添加一個 ref 屬性，該屬性的值是一個回調函數，它將接收底層的 DOM 元素或組件的已掛接實例，作為其第一個參數。

class UnControlledForm extends Component {
  handleSubmit = () => {
    console.log("Input Value: ", this.input.value)
  }
  render () {
    return (
      

         this.input = input} />
        Submit
      
    )
  }
}

以上注意到我們的輸入字段有一個 ref 屬性，其值是一個函數。該函數接收我們然后放在實例上的實際的 DOM 元素，以便在 handleSubmit 函數內部訪問它。經常誤解的是，您需要使用類組件才能使用ref ，但 ref 也可以通過利用 JavaScript 中的閉包與 功能組件( functional components )一起使用。

function CustomForm ({handleSubmit}) {
  let inputElement
  return (
    
 handleSubmit(inputElement.value)}>
       inputElement = input} />
      Submit
    
  )
}

keys 是什么幫助 React 跟蹤哪些項目已更改、添加或從列表中刪除。

  return (
    

      {this.state.todoItems.map(({task, uid}) => {
        return 
{task}
      })}
    
  )
}

每個keys 在兄弟元素之間是獨一無二的。我們已經談過幾次關于和解（reconciliation）的過程，而且這個和解過程（reconciliation）中的一部分正在執行一個新的元素樹與最前一個的差異。keys 使處理列表時更加高效，因為 React 可以使用子元素上的 keys 快速知道元素是新的還是在比較樹時才被移動。

而且 keys 不僅使這個過程更有效率，而且沒有keys，React 不知道哪個本地狀態對應于移動中的哪個項目。所以當你 map 的時候，不要忽略了 keys 。

  {(user) => user === null
    ? 
    : }

import React, { Component, PropTypes } from "react"
import fetchUser from "twitter"
// fetchUser接收用戶名返回 promise
// 當得到 用戶的數據的時候 ，返回resolve 狀態

class Twitter extends Component {
  // 在這里寫下你的代碼
}

如果你不熟悉渲染回調模式（render callback pattern），這將看起來有點奇怪。在這種模式中，一個組件接收一個函數作為它的 child。注意上面包含在 標簽內的內容。Twitter 組件的 child 是一個函數，而不是你曾經習以為常的一個組件。 這意味著在實現 Twitter 組件時，我們需要將 props.children 作為一個函數來處理。

以下是我的答案。

    import React, { Component, PropTypes } from "react"
    import fetchUser from "twitter"
    
    class Twitter extends Component {
      state = {
        user: null,
      }
      static propTypes = {
        username: PropTypes.string.isRequired,
      }
      componentDidMount () {
        fetchUser(this.props.username)
          .then((user) => this.setState({user}))
      }
      render () {
        return this.props.children(this.state.user)
      }
    }

值得注意的是，正如我上面提到的，我通過調用它并傳遞給 user 來把 props.children 處理為為一個函數。

這種模式的好處是我們已經將我們的父組件與我們的子組件分離了。父組件管理狀態，父組件的消費者可以決定以何種方式將從父級接收的參數應用于他們的 UI。

為了演示這一點，我們假設在另一個文件中，我們要渲染一個 Profile 而不是一個 Badge,，因為我們使用渲染回調模式，所以我們可以輕松地交換 UI ，而不用改變我們對父（Twitter）組件的實現。

  {(user) => user === null
    ? 
    : }

React 的很大一部分是這樣的想法，即組件負責控制和管理自己的狀態。

當我們將 native HTML 表單元素（ input, select, textarea 等）投入到組合中時會發生什么？我們是否應該使用 React 作為“單一的真理來源”，就像我們習慣使用React一樣？ 或者我們是否允許表單數據存在 DOM 中，就像我們習慣使用HTML表單元素一樣？ 這兩個問題是受控（controlled） VS 不受控制（uncontrolled）組件的核心。

受控組件是React控制的組件，也是表單數據的唯一真理來源。

如下所示，username 不存在于 DOM 中，而是以我們的組件狀態存在。每當我們想要更新 username 時，我們就像以前一樣調用setState。

class ControlledForm extends Component {
  state = {
    username: ""
  }
  updateUsername = (e) => {
    this.setState({
      username: e.target.value,
    })
  }
  handleSubmit = () => {}
  render () {
    return (
      

        
        Submit
      
    )
  }
}

不受控制( uncontrolled component )的組件是您的表單數據由 DOM 處理，而不是您的 React 組件。

我們使用 refs 來完成這個。

class UnControlledForm extends Component {
  handleSubmit = () => {
    console.log("Input Value: ", this.input.value)
  }
  render () {
    return (
      

         this.input = input} />
        Submit
      
    )
  }
}

雖然不受控制的組件通常更容易實現，因為您只需使用引用從DOM獲取值，但是通常建議您通過不受控制的組件來支持受控組件。

主要原因是受控組件支持即時字段驗證，允許您有條件地禁用/啟用按鈕，強制輸入格式，并且更多的是 『the React way』。

AJAX 請求應該在 componentDidMount 生命周期事件中。 有幾個原因:

Fiber，是下一次實施React的和解算法，將有能力根據需要啟動和停止渲染，以獲得性能優勢。其中一個取舍之一是 componentWillMount，而在其他的生命周期事件中出發 AJAX 請求，將是具有 “非確定性的”。 這意味著 React 可以在需要時感覺到不同的時間開始調用 componentWillMount。這顯然是AJAX請求的不好的方式。

-您不能保證在組件掛載之前，AJAX請求將無法 resolve。如果這樣做，那意味著你會嘗試在一個未掛載的組件上設置 StState，這不僅不會起作用，反而會對你大喊大叫。 在 componentDidMount 中執行 AJAX 將保證至少有一個要更新的組件。

上面我們討論了 reconciliation ，什么是 React 在 setState 被調用時所做的。在生命周期方法 shouldComponentUpdate 中，允許我們選擇退出某些組件（和他們的子組件）的 reconciliation 過程。

我們為什么要這樣做？

如上所述，“和解（ reconciliation ）的最終目標是以最有效的方式，根據新的狀態更新用戶界面”。如果我們知道我們的用戶界面（UI）的某一部分不會改變，那么沒有理由讓 React 很麻煩地試圖去弄清楚它是否應該渲染。通過從 shouldComponentUpdate 返回 false，React 將假定當前組件及其所有子組件將保持與當前組件相同。

通常，您將使用Webpack的 DefinePlugin 方法將 NODE_ENV 設置為 production。這將剝離像 propType 驗證和額外的警告。除此之外，還有一個好主意，可以減少你的代碼，因為React使用 Uglify 的 dead-code 來消除開發代碼和注釋，這將大大減少你的包的大小。

因為不能保證props.children將是一個數組。

以此代碼為例，

  
Welcome.

在父組件內部，如果我們嘗試使用 props.children.map 映射孩子，則會拋出錯誤，因為 props.children 是一個對象，而不是一個數組。

如果有多個子元素，React 只會使props.children成為一個數組。就像下面這樣：

  
Welcome.
  
props.children will now be an array

這就是為什么你喜歡 React.Children.map，因為它的實現考慮到 props.children 可能是一個數組或一個對象。

為了解決跨瀏覽器兼容性問題，您的 React 中的事件處理程序將傳遞SyntheticEvent 的實例，它是 React 的瀏覽器本機事件的跨瀏覽器包裝器。

這些 SyntheticEvent 與您習慣的原生事件具有相同的接口，除了它們在所有瀏覽器中都兼容。有趣的是，React 實際上并沒有將事件附加到子節點本身。React 將使用單個事件監聽器監聽頂層的所有事件。這對于性能是有好處的，這也意味著在更新DOM時，React 不需要擔心跟蹤事件監聽器。

createElement 是 JSX 被轉載到的，是 React 用來創建 React Elements 的內容(一些 UI 的對象表示)cloneElement用于克隆元素并傳遞新的 props。他們釘住了這兩個?的命名。

一個回調函數，當setState結束并re-rendered該組件時將被調用。一些沒有說出來的東西是 setState 是異步的，這就是為什么它需要一個第二個回調函數。通常最好使用另一個生命周期方法，而不是依賴這個回調函數，但是很高興知道它存在。

this.setState(
  { username: "tylermcginnis33" },
  () => console.log("setState has finished and the component has re-rendered.")
)

this.setState((prevState, props) => {
  return {
    streak: prevState.streak + props.count
  }
})

沒毛病。但是這種寫法很少被使用，并不是眾所周知的，就是你也可以傳遞一個函數給setState，它接收到先前的狀態和道具并返回一個新的狀態，正如我們在上面所做的那樣。它不僅沒有什么問題，而且如果您根據以前的狀態（state）設置狀態，推薦使用這種寫法。