摘要：你可以使用這個技術在構建時間生成。谷歌實際上是在年開始抓取素材的，這個算法現在已經可以完美地工作了。閉包在無處不不在，并且你可能一直使用到它，即使你還沒有注意到。但是你在方法中使用閉包時，它確實是不好的。

原文：5 common practices that you can stop doing in React

從下面這點來說，很難說React是這個星球上最受歡迎的庫之一。很多人對React感興趣，新的開發者之所以傾向于使用這個框架的原因是因為它的UI優先方法。雖然這些年React和它的整個生態已經比較成熟，但是在某些情況下你仍然會這樣問自己：“正確的做法到底是什么？”

這是一個好問題--并不總是有一個通用的“正確”的做事方式。事實上，正如你所知，最佳實踐并不總是那么的適用。長遠來看，其中的某些寫法可能會影響性能，可讀性，并導致效率低下。

在本文中，我將描述在React開發中5種被普遍接受的寫法，但是實際上你是可以避免這樣做的。當然，我將解釋為什么我認為這些做法是可以避免的，并且我會建議你用其他的寫法來完成相同的事情。

從一開始就優化React

React的開發人員在如何使React更快投入了大量的精力，每次迭代新的優化方法又會被添加進去。在我看來，你不應該花費時間優化這些東西，除非你發現了真正的性能影響。

為什么？

React相比其它的前端平臺更容易擴展，因為你不必重寫某個模塊來加快應用的速度。導致性能問題的罪魁禍首通常是React使用更新虛擬DOM的reconciliation過程。

讓我們看一下React是如何處理下面的事情的。在每個render()中，React生成了一個由UI元素組成的樹——子節點是實際的DOM元素。當state或者props更新的時候，React需要使用最小的改變次數來生成一個新的樹，并保持可預測性。

想象一下，你看到的樹是這個樣子的：

想象一下，你的應用接收到新的數據，下列的節點需要被更新：

React通常會重新渲染整個子樹，而不是像這樣僅僅渲染相關節點：

當頂層組件的state發生改變的時候，它的子元素都會重新渲染。這是默認的行為，在小型應用中不需要擔心。隨著應用的逐漸擴展，您應該考慮使用Chrome Profiling工具來測量實際性能。這個工具將為你提供在不必要的渲染上所浪費時間的精確數據。如果這些數據很重要，你可以通過向你的組件中添加shouldComponentUpdate鉤子來優化你的渲染時間。

這個鉤子在重新渲染開始之前將被觸發，默認返回true:

shouldComponentUpdate(nextProps, nextState) {
  return true;
}

當返回true時，React的diff算法接管并重新渲染整個子樹。你能避免這樣的情況發生，通過在shouldComponentUpdate中添加比較邏輯，并且僅當相關的props發生改變的時候更新邏輯。

shouldComponentUpdate(nextProps, nextState) {
    if (this.props.color !== nextProps.color) {
      return true;
    }
    if (this.state.count !== nextState.count) {
      return true;
    }
    return false;
  }

除了color/count，其它任何props/state改變，這個組件都不會更新。

除此之外，還有一些開發人員通常忽略的non-React優化技巧，但它們會影響應用程序的性能。

我將在下面列舉一些可以避免的習慣和解決方案：

未優化的圖片--如果你的應用中有很多動態圖片，你需要在處理圖片時考慮你的選項。較大的圖片可能會給用戶一種應用很慢的印象。在將圖片推入服務器之前壓縮圖片，或者使用動態圖片處理解決方案來替代。我個人喜歡Cloudinary來優化react圖片因為它有它自己的react庫，但是你也可以使用Amazon S3或者Firebase。

未壓縮的構建文件--Gzipping構建文件(bundle.js)可以有效的減少文件大小。你需要修改webserver的配置文件。Webpack有一個gzip壓縮插件，叫做compression-webpack-plugin。你可以使用這個技術在構建時間生成bundle.js.gz。

服務端渲染的SEO

雖然單頁面應用非常棒，但是他們仍然存在兩個問題。

當應用首次加載的時候，瀏覽器中沒有JavaScript緩存。如果應用很大，首次加載應用的時間將會很慢。

由于應用程序是在客戶端進行渲染，搜索引擎使用的web爬蟲程序將無法索引JavaScript生成的內容。搜索引擎將看到你的應用是空白的，然后排名很差。

這就是服務端渲染技術派上用處的地方。在SSR中，JavaScript內容最初是由服務器渲染的。在首次渲染后，客戶端的腳本接管，并像一個正常的SPA應用運行。由于你需要使用Node/Express服務，因此在以傳統SSR進行構建時復雜度和花費更高。

如果你是為了搜索引擎優化、谷歌索引和沒有任何問題地抓取JavaScript內容，那么有一個好消息。谷歌實際上是在2016年開始抓取JavaScript素材的，這個算法現在已經可以完美地工作了。

以下是2015年10月Webmaster博客的節選。

今天，只要你不阻止Googlebot抓取你的JavaScript或CSS文件，我們就能像現代瀏覽器一樣渲染和理解你的網頁。為了反映這一改進，我們最近更新了我們的技術站長指南，建議不要禁止Googlebot抓取你網站的CSS或JS文件。

如果你使用服務器端渲染，是因為你擔心你的谷歌頁面排名，那么你不需要使用SSR。它曾經是過去的事，但現在不是了。

然而，如果你正在改善首次渲染速度，那么你應該嘗試使用像Next.js這樣的庫來實現更加簡單的SSR。Next將節省你在設置Node/Express 服務所花費的時間。

Inline styles和CSS imports

在使用React做開發時，我曾親自嘗試過多種不同的樣式理念，為了能找到一種新的引入樣式到React組件的方式。在React組件中使用已經存在多年的傳統的CSS-in-CSS 方法。你的樣式表全部樣放在一個樣式表目錄，然后你可以將所需要的CSS導入到你的組件中。

然而，當你使用這些組件的時候，樣式表不再清晰明了。React鼓勵你以組件化的方式來思考你的應用，然而樣式表則強迫你以文檔的角度來思考。

目前有多種方法將CSS和JS代碼合并到一個文件中。內聯樣式可能是其中最流行的。

const divStyle = {
  margin: "40px",
  border: "5px solid pink"
};
const pStyle = {
  fontSize: "15px",
  textAlign: "center"
};

const TextBox = () => (
  

    
Yeah!
  
);

export default TextBox;

你不需要再導入CSS，但是這會犧牲可讀性和可維護性。除了這樣做，內聯樣式不支持媒體查詢，偽元素以及樣式回退。當然，有一些技巧可以讓你解決上述問題，但是使用起來卻并不方便。

這就是CSS-in-JSS派上用處的地方，內聯樣式并不完全是CSS-in-JSS。下面的代碼演示了使用styled-components的概念。

import styled from "styled-components";

const Text = styled.div`
  color: white,
  background: black
`
This is CSS-in-JS

在瀏覽器中看上去是這樣的：

This is CSS-in-JS

新的