React 中無用但可以裝逼的知識

最近看了Dan Abramov的一些博客，學到了一些React的一些有趣的知識。決定結合自己的理解總結下。這些內容可能對你實際開發並沒有什麼幫助，不過這可以讓你瞭解到更多React底層實現的內容以及為什麼要怎樣實現。可以讓你跟別人有更多的談資，當然，也可以在某些場合裝一下逼。那麼接下來直接進入正文。

React如何區分類組件和函數組件

我們可以考慮從幾種方式：

統一使用new方法來生成實例

問題：

• 對於函數組件而言，這樣會讓它們生成一個多餘的this作為對象實例。

• 對於箭頭函數而言，會報錯。因為箭頭函數並沒有this,它的this是取自於定義這個箭頭函數所在環境的this

  const fun = () => console.log(2);
  new fun(); // Uncaught TypeError: fun is not a constructor

• 使用new會妨礙函數組件返回原始類型(string、number等)。

  我們都知道，使用new操作符後，只有當函數返回非null 和非undefined的對象的時候，返回值才會生效。否則new操作符的返回值都會是對象。關於new操作符詳細的內容可以點擊這裡

  function Greeting() {
    return 'Hello';
  }
  
  // 並不會返回字元串
  new Gretting(); // Gretting {}

綜上所述，這個方法不可行。

通過instanceof來判斷

不知道你有沒有察覺，我們寫React的類組件的時候，我們都需要通過extends React.Component的方式來寫。那麼，我們是否可以通過以下方式來判斷呢？

class A extends React.Component {
}

A.prototype instanceOf React.Component; // true

通過這種方式，我們確實可以區分類組件和函數組件，可是也存在一些問題：

• 箭頭函數沒有prototyoe

  這個問題其實好解決，如下

  function getType(Component) {
    if (Component.prototyoe && Component.prototype instance React.Component) {
      return 'class';
    }
  
    return 'function';
  }

• 對於一些項目(雖然很少)可能存在著多個React副本，並且我們目前要檢查的組件它繼承的React.Component是來自於另一個React副本的，這就會出現問題。這個問題的話就沒辦法解決了。因此這種方式也存在問題。

通過為React.Component增加一個特別的標記

寫過React的類組件的人都知道，我們每一個類組件都是要繼承於React.Component的。因此，如果我們在React.Component增加一個標記isReactComponent，這樣通過繼承的方式，我們就可以根據這個標記來判斷是不是類組件了。

// React 內部
class Component {}
Component.prototype.isReactComponent = {};

// 檢查
class Greeting extends Component {};
console.log(Greeting.prototype.isReactComponent);

事實上，React目前就是通過這種方式來進行檢查的。如果你沒有extends React.Component，React不會在原型上找到isReactComponent，因此不會把組件當做類組件來處理。

React Elements為什麼要有一個$typeof屬性

假如我們的jsx長這個樣子：

<Button type="primary">點擊</Button>

實際上，在經過babel後，它會變成下麵這段代碼：

React.createElement(
  /* type */ 'Button',
  /* props */ { type: 'primary' },
  /* children */ '點擊'
)

之後，這個函數執行結果會返回一個對象，這個對象我們稱為React Element。它是一個用來描述我們將要渲染的頁面結構的一個不可變對象。想瞭解更多與React Component,Elements和Inastances的可以點擊這裡。

// React Element
{
  type: 'Button',
  props: {
    type: 'primary',
    children: '點擊',
  },
  key: null,
  ref: null,
  $$typeof: Symbol.for('react.element'), // 為什麼有這個東西
}

對於React開發者來說，上面這些屬性大部分都是比較常見的。可是為什麼混進了一個奇怪的$$typeof？？它是幹嘛的呢？它的值為什麼是一個Symbol呢？

這個屬性的引入，其實要從一個安全漏洞說起。

假如我們要顯示一個變數，如果你使用純js來寫的話，可能是這樣：

const messageEl = document.getElementById('message');
messageEl.innerHTML = `<div>${message}</div>`;

這一段代碼，對於熟悉或者瞭解過XSS攻擊的人來說，一看就知道會有問題，存在著XSS攻擊。如果message是用戶可以控制的變數(比如說是用戶輸入的評論)的話，那麼用戶就可以進行攻擊了。比如用戶可以構造下麵的代碼來進行攻擊:

message = '<img onerror="alert(2)" src="" />';

如果我們明確知道，我們只想單純的渲染文本，不想把它當成html來渲染的話，那麼我們可以通過textContent來避免這個問題。

const messageEl = document.getElementById('message');
messageEl.textContent = `<div>${message}</div>`;

而對於React而言的話，想要實現相同的效果，只需要:

<div>{message}</div>

即使message裡面含有img、script類似的標簽，它們最終也不會以實際上的標簽顯示。React會對渲染的內容進行轉譯，比如說上面的攻擊代碼會被轉譯為:

message = '<img onerror="alert(2)" src=""/>';
// 轉譯為
message = '&lt;img onerror="alert(2)" src=""/&gt;'

因此，這樣就可以避免大部分場景下的XSS攻擊了。

當然，React也提供了另一種方式來將用戶輸入的內容當成html來渲染:

<div dangerouslySetInnerHTML={{ __html: message }}></div>

前面說了這麼多，那麼跟$$typeof又有什麼關係呢？別急，重點來了。

對於下麵這種寫法，我們一般都知道，message可以傳基本類型、自定義組件和jsx片段。

<div>{message}</div>

可是，其實我們還可以直接傳React Element。比如，我們可以直接這樣寫

class App extends React.Component {
  render() {
    const message = {
      type: "div",
      props: {
        dangerouslySetInnerHTML: {
          __html: `<h1>Arbitrary HTML</h1>
            <img onerror="alert(2)" src="" />
            <a href='http://danlec.com'>link</a>`
        }
      },
      key: null,
      ref: null,
      $$typeof: Symbol.for("react.element")
    };
    return <>{message}</>;
  }
}

這樣在運行的時候，就會彈出一個alert框了。查看demo。那麼，這樣會有什麼風險呢？

考慮一個場景，比如一個博客網站的評論信息message是由用戶提供的，並且支持傳入JSON。那麼如果用戶直接將上文的message發送給後臺保存。之後，通過下麵這種方式展示的話，用戶就可以進行XSS攻擊了。

<div>{message}</div>

假設如果沒有$$typeof屬性的話，這種攻擊確實可行。因為其他的屬性都是可序列化的。

const message = {
  type: "div",
  props: {
    dangerouslySetInnerHTML: {
      __html: `<h1>Arbitrary HTML</h1>
<img onerror="alert(2)" src="" />
<a href='http://danlec.com'>link</a>`
    }
  },
  key: null,
  ref: null,
};

JSON.stringify(message);

事實上，React 0.13當時就存在著這個漏洞。之後，React 0.14就修複了這個問題，修複方式就是通過引入$$typeof屬性，並且用Symbol來作為它的值。

// 引入 $$typeof
const message = {
  type: "div",
  props: {
    dangerouslySetInnerHTML: {
      __html: `<h1>Arbitrary HTML</h1>
<img onerror="alert(2)" src="" />
<a href='http://danlec.com'>link</a>`
    }
  },
  key: null,
  ref: null,
  $$typeof: Symbol.for("react.element")
};

JSON.stringify(message); // Symbol無法被序列化

這是一個有效的方法，因為JSON是不支持Symbol類型的。所以，即使用戶提交瞭如上的message信息，到最後服務端也不會保存$$typeof屬性。而在渲染的時候，React 會檢測是否有$$typeof屬性。如果沒有這個屬性，則拒絕處理該元素。

那麼如果瀏覽器不支持Symbol怎麼辦？

是的，那這種保護方案就沒用了。React 依然會加上$$typeof欄位，並且將其值設置為0xeac7。(為什麼是這個數字呢，因為這個數字看起來有點像React)。

想查看具體的攻擊流程，可以查看這篇博客。

總結

• React會給React.Component.prototype增加一個isReactElement標誌。這樣，React就可以在渲染的時候判斷當前渲染的組件是類組件還是函數組件。
• React Element是一個用於描述要渲染的頁面結構的一個不可變對象。React函數組件和類組件執行到最後，其實都是生成一個React Elements樹。之後再由實際的渲染層(react-dom、react-native)根據這個React Elements樹渲染為實際的頁面。
• <div>{message}</div>這種方式不僅可以傳原型類型、jsx和組件，還可以直接傳React Element對象。
• $$typeof的出現就是為了防止服務端允許儲存JSON而引起的XSS攻擊。可是對於不支持Symbol的瀏覽器，這個問題依然存在。

本文地址在->本人博客地址, 歡迎給個 start 或 follow。

參考資料

Why Do React Elements Have a $$typeof Property?

How Does React Tell a Class from a Function?

XSS via a spoofed React element