[React] react-interview-01

1.render 函數中 return 若是沒有使用()會有什麼問題？

咱們在使用 JSX 語法書寫 react 代碼時，babel 會將 JSX 語法編譯成 js，同時會在每行自動添加分號（；），若是 return 後換行了，那麼就會變成 return；

渲染沒有返回任何內容。這一般意味着缺乏 return 語句。或者，爲了避免渲染，返回 null。

爲了代碼可讀性咱們通常會在 return 後面添加括號這樣代碼能夠折行書寫，不然就在 return 後面緊跟着語句.

錯誤

const Nav = () => {
  return
    <nav className="c_navbar">
      { some jsx magic here }
    </nav>
}

2.componentWillUpdate 能夠直接修改 state 的值嗎？

react 組件在每次須要從新渲染時候都會調用 componentWillUpdate(),

例如，咱們調用 this.setState()時候

在這個函數中咱們之因此不調用 this.setState()是由於該方法會觸發另外一個 componentWillUpdate(),若是咱們 componentWillUpdate()中觸發狀態更改,咱們將以無限循環.

3.什麼渲染劫持？

首先，什麼是渲染劫持：渲染劫持的概念是控制組件從另外一個組件輸出的能力，固然這個概念通常和 react 中的高階組件（HOC）放在一塊兒解釋比較有明瞭。

高階組件能夠在 render 函數中作很是多的操做，從而控制原組件的渲染輸出，只要改變了原組件的渲染，咱們都將它稱之爲一種渲染劫持。

實際上，在高階組件中，組合渲染和條件渲染都是渲染劫持的一種，經過反向繼承，不只能夠實現以上兩點，還能夠加強由原組件 render 函數產生的 React 元素。

實際的操做中 經過 操做 state、props 均可以實現渲染劫持

4.React Intl

react-intl 實現 React 國際化多語言

5.說說 Context 有哪些屬性？

新版本的 context api 中 經常使用的只有 Provider 和 Consumer 兩個對象

6.怎麼使用 Context 開發組件？

import React, {Component} from 'react'

// 首先建立一個 context 對象這裏命名爲：ThemeContext
const ThemeContext = React.createContext('light')

// 建立一個祖先組件組件 內部使用Provier 這個對象建立一個組件 其中 value 屬性是真實傳遞的屬性
class App extends Component {
  render () {
    return (
      <ThemeContext.Provider value="dark">
        <Toolbar />
      </ThemeContext.Provider>
    )
  }
}

// 渲染 button 組件的外層包裹的屬性
function Toolbar () {
  return (
    <div>
      <ThemeButton />
    </div>
  )
}
// 在 Toolbar 中渲染的button 組件 返回一個 consumer （消費者）將組件組件的 value 值跨組件傳遞給 // ThemeButton 組件
function ThemeButton (props) {
  return (
    <ThemeContext.Consumer>
      { theme => <button {...props} theme={theme}>{theme}</button> }
    </ThemeContext.Consumer>
  )
}

7.爲何 React 並不推薦咱們優先考慮使用 Context？

• Context 目前還處於實驗階段，可能會在後面的發行版本中有很大的變化，事實上這種狀況已經發生了，因此爲了不給從此升級帶來大的影響和麻煩，不建議在 app 中使用 context。
• 儘管不建議在 app 中使用 context，可是獨有組件而言，因爲影響範圍小於 app，若是能夠作到高內聚，不破壞組件樹之間的依賴關係，能夠考慮使用 context
• 對於組件之間的數據通訊或者狀態管理，有效使用 props 或者 state 解決，而後再考慮使用第三方的成熟庫進行解決，以上的方法都不是最佳的方案的時候，在考慮 context。
• context 的更新須要經過 setState()觸發，可是這並非很可靠的，Context 支持跨組件的訪問，可是若是中間的子組件經過一些方法不影響更新，好比 shouldComponentUpdate() 返回 false 那麼不能保證 Context 的更新必定可使用 Context 的子組件，所以，Context 的可靠性須要關注。

8.React15 和 16 別支持 IE 幾以上？

React15 版本不直接支持 IE8 瀏覽器的，官方文檔中說 React16 中依賴於集合類型 Map 和 Set 所以再也不支持 IE 11 如下的瀏覽器，若是想要支持，須要使用全局的 polyfill

9.舉例說明 React 的插槽有哪些運用場景？

對於 portal 的一個典型用例是當父組件有 overflow: hidden 或 z-index 樣式，但你須要子組件可以在視覺上 「跳出(break out)」 其容器。例如，對話框、hovercards 以及提示框。因此通常 react 組件裏的模態框，就是這樣實現的

10.你有用過 React 的插槽(Portals)嗎？怎麼用？

• 首先簡單的介紹下 react 中的插槽（Portals），經過 ReactDOM.createPortal(child, container)建立，是 ReactDOM 提供的接口，能夠實現將子節點渲染到父組件 DOM 層次結構以外的 DOM 節點。
• 第一個參數（child）是任何可渲染的 React 子元素，例如一個元素，字符串或 片斷(fragment)。第二個參數（container）則是一個 DOM 元素。
• 對於 portal 的一個典型用例是當父組件有 overflow: hidden 或 z-index 樣式，但你須要子組件可以在視覺上 「跳出(break out)」 其容器。例如，對話框、hovercards 以及提示框。因此通常 react 組件裏的模態框，就是這樣實現的。

11.React 的嚴格模式有什麼用處？

react 的 strictMode 是一個突出顯示應用程序中潛在問題的工具，與 Fragment 同樣，strictMode 不會渲染任何的可見 UI，它爲其後代元素觸發額外的檢查和警告。

注意：嚴格模式僅在開發模式下運行，它們不會影響生產構建

能夠爲程序的任何部分使用嚴格模式

import React from 'react';

function ExampleApplication() {
  return (
    <div>
      <Header />
      <React.StrictMode>
        <div>
          <ComponentOne />
          <ComponentTwo />
        </div>
      </React.StrictMode>
      <Footer />
    </div>
  );
}

在上述的示例中，不會對 Header 和 Footer 組件運行嚴格模式檢查。可是，ComponentOne 和 ComponentTwo 以及它們的全部後代元素都將進行檢查。

StrictMode 目前有助於：

• 識別不安全的生命週期
• 關於使用過期字符串 ref API 的警告
• 關於使用廢棄的 findDOMNode 方法的警告
• 檢測意外的反作用
• 檢測過期的 context API

題目和答案來源於 [react 每日 3 問]](https://github.com/haizlin/fe-interview/blob/master/lib/React.md)