這篇文章主要介紹“JavaScript通過緩存React事件來提高性能”，在日常操作中，相信很多人在JavaScript通過緩存React事件來提高性能問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”JavaScript通過緩存React事件來提高性能”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

在豐順等地區(qū)，都構建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供成都網(wǎng)站設計、網(wǎng)站制作 網(wǎng)站設計制作按需定制開發(fā),公司網(wǎng)站建設,企業(yè)網(wǎng)站建設,成都品牌網(wǎng)站建設,網(wǎng)絡營銷推廣,外貿網(wǎng)站制作,豐順網(wǎng)站建設費用合理。

JavaScript中一個不被重視的概念是對象和函數(shù)是如何引用的，并且直接影響 React性能。  如果創(chuàng)建兩個完全相同的函數(shù)，它們仍然不相等，試試下面的例子：

const functionOne = function() { alert('Hello world!'); };  const functionTwo = function() { alert('Hello world!'); };  functionOne === functionTwo; // false

但是，如果將變量指向一個已存在的函數(shù)，看看它們的差異：

const functionThree = function() { alert('Hello world!'); };  const functionFour = functionThree;  functionThree === functionFour; // true

對象的工作方式也是一樣的。

const object1 = {}; const object2 = {}; const object3 = object1; object1 === object2; // false object1 === object3; // true

如果人有其他語言的經驗，你可能熟悉指針。每次創(chuàng)建一個對象，計算機會為這個對象分配了一些內存。當聲明 object1 ={} 時，已經在用戶電腦中的  RAM(隨機存取存儲器) 中創(chuàng)建了一個專門用于object1 的字節(jié)塊?？梢詫?object1 想象成一個地址，其中包含其鍵-值對在 RAM 中的位置。

當聲明 object2 ={} 時，在用戶的電腦中的 RAM 中創(chuàng)建了一個專門用于 object2 的不同字節(jié)塊。object1 的地址與 object2  的地址是不一樣的。這就是為什么這兩個變量的等式檢查沒有通過的原因。它們的鍵值對可能完全相同，但是內存中的地址不同，這才是會被比較的地方。

當我賦值 object3 = object1 時，我將 object3 的值賦值為 object1  的地址，它不是一個新對象。它們在內存中的位置是相同的，可以這樣驗證:

const object1 = { x: true };  const object3 = object1;  object3.x = false;  object1.x; // false

在本例中，我在內存中創(chuàng)建了一個對象并取名為 object1。然后將 object3 指向 object1 這時它們的內存的地址中是相同的。

通過修改 object3，可以改變對應內存中的值，這也意味著所有指向該內存的變量都會被修改。obect1 的值也被改變了。

對于初級開發(fā)人員來說，這是一個非常常見的錯誤，可能需要一個更別深入的教程，但是本廣是關于React 性能的，只是本文是討論 React  性能的，甚至是對變量引用有較深資歷的開發(fā)者也可能需要學習。

這與 React 有什么關系? React 有一種節(jié)省處理時間以提高性能的智能方法：如果組件的 props 和 state 沒有改變，那么render  的輸出也一定沒有改變。 顯然，如果所有的都一樣，那就意味著沒有變化，如果沒有任何改變，render 必須返回相同的輸出，因此我們不必執(zhí)行它。 這就是 React  快速的原因，它只在需要時渲染。

React 采用和 JavaScript 一樣的方式，通過簡單的 == 操作符來判斷 props 和 state 是否有變化。  React不會深入比較對象以確定它們是否相等。淺比較用于比較對象的每個鍵值對，而不是比較內存地址。深比較更進一步，如果鍵-值對中的任何值也是對象，那么也對這些鍵-值對進行比較。React  都不是:它只是檢查引用是否相同。

如果要將組件的 prop 從 {x：1} 更改為另一個對象 {x：1}，則 React 將重新渲染，因為這兩個對象不會引用內存中的相同位置。  如果要將組件的 prop 從 object1(上面的例子)更改為 o bject3，則 React 不會重新呈現(xiàn)，因為這兩個對象具有相同的引用。

在 JavaScript 中，函數(shù)的處理方式是相同的。如果 React 接收到具有不同內存地址的相同函數(shù)，它將重新呈現(xiàn)。如果 React  接收到相同的函數(shù)引用，則不會。

不幸的是，這是我在代碼評審過程中遇到的常見場景:

class SomeComponent extends React.PureComponent {   get instructions () {     if (this.props.do) {       return 'click the button: '     }     return 'Do NOT click the button: '   }    render() {     return (       
         {this.instructions}          alert('!')} />       
     )   } }

這是一個非常簡單的組件。 有一個按鈕，當它被點擊時，就 alert。 instructions 用來表示是否點擊了按鈕，這是通過  SomeComponent 的 prop 的 do={true} 或 do={false} 來控制。

這里所發(fā)生的是，每當重新渲染 SomeComponent 組件(例如 do 從 true 切換到 false)時，按鈕也會重新渲染，盡管每次  onClick 方法都是相同的，但是每次渲染都會被重新創(chuàng)建。

每次渲染時，都會在內存中創(chuàng)建一個新函數(shù)(因為它是在 render 函數(shù)中創(chuàng)建的)，并將對內存中新地址的新引用傳遞給，雖然輸入完全沒有變化，該 Button 組件還是會重新渲染。

修復

如果函數(shù)不依賴于的組件(沒有 this 上下文)，則可以在組件外部定義它。  組件的所有實例都將使用相同的函數(shù)引用，因為該函數(shù)在所有情況下都是相同的。

const createAlertBox = () => alert('!');  class SomeComponent extends React.PureComponent {    get instructions() {     if (this.props.do) {       return 'Click the button: ';     }     return 'Do NOT click the button: ';   }    render() {     return (       
         {this.instructions}                
     );   } }

和前面的例子相反，createAlertBox 在每次渲染中仍然有著有相同的引用，因此按鈕就不會重新渲染了。

雖然 Button 是一個小型，快速渲染的組件，但你可能會在大型，復雜，渲染速度慢的組件上看到這些內聯(lián)定義，它可能會讓你的 React  應用程序陷入囧境，所以***不要在 render 方法中定義這些函數(shù)。

如果函數(shù)確實依賴于組件，以至于無法在組件外部定義它，你可以將組件的方法作為事件處理傳遞過去:

class SomeComponent extends React.PureComponent {    createAlertBox = () => {     alert(this.props.message);   };    get instructions() {     if (this.props.do) {       return 'Click the button: ';     }     return 'Do NOT click the button: ';   }    render() {     return (       
         {this.instructions}                
     );   } }

在這種情況下，SomeComponent 的每個實例都有一個不同的警告框。 Button 的click事件偵聽器需要獨立于 SomeComponent。  通過傳遞 createAlertBox 方法，它就和 SomeComponent 重新渲染無關了，甚至和 message  這個屬性是否修改也沒有關系。createAlertBox 內存中的地址不會改變，這意味著 Button  不需要重新渲染，節(jié)省了處理時間并提高了應用程序的渲染速度

但如果函數(shù)是動態(tài)的呢?

修復(高級)

這里有個非常常見的使用情況，在簡單的組件里面，有很多獨立的動態(tài)事件監(jiān)聽器，例如在遍歷數(shù)組的時候：

class SomeComponent extends React.PureComponent {   render() {     return (       
         {this.props.list.map(listItem =>                         alert(listItem.text)} />                    )}       
     );   } }

在本例中，有一個可變數(shù)量的按鈕，生成一個可變數(shù)量的事件監(jiān)聽器，每個監(jiān)聽器都有一個獨特的函數(shù)，在創(chuàng)建 SomeComponent  時不可能知道它是什么。怎樣才能解決這個難題呢?

輸入記憶，或者簡單地稱為緩存。 對于每個唯一值，創(chuàng)建并緩存一個函數(shù); 對于將來對該唯一值的所有引用，返回先前緩存的函數(shù)。

這就是我將如何實現(xiàn)上面的示例。

class SomeComponent extends React.PureComponent {   // SomeComponent的每個實例都有一個單擊處理程序緩存，這些處理程序是惟一的。    clickHandlers = {};    // 在給定唯一標識符的情況下生成或返回單擊處理程序。   getClickHandler(key) {     // 如果不存在此唯一標識符的單擊處理程序，則創(chuàng)建     if (!Object.prototype.hasOwnProperty.call(this.clickHandlers, key)) {       this.clickHandlers[key] = () => alert(key);     }     return this.clickHandlers[key];   }   render() {     return (       
         {this.props.list.map(listItem =>                                            )}       
     );   } }

數(shù)組中的每一項都通過 getClickHandler  方法傳遞。所述方法將在***次使用值調用它時創(chuàng)建該值的唯一函數(shù)，然后返回該函數(shù)。以后對該方法的所有調用都不會創(chuàng)建一個新函數(shù);相反，它將返回對先前在內存中創(chuàng)建的函數(shù)的引用。

因此，重新渲染 SomeComponent 不會導致按鈕重新渲染。類似地，相似的，在 list 里面添加項也會為按鈕動態(tài)地創(chuàng)建事件監(jiān)聽器。

當多個處理程序由多個變量確定時，可能需要使用自己的聰明才智為每個處理程序生成唯一標識符，但是在遍歷里面，沒有比每個 JSX 對象生成的 key  更簡單得了。

這里使用 index 作為唯一標識會有個警告：如果列表更改順序或刪除項目，可能會得到錯誤的結果。

當數(shù)組從 ['soda'，'pizza'] 更改為 ['pizza'] 并且已經緩存了事件監(jiān)聽器為 listeners[0] = () =>  alert('soda') ，您會發(fā)現(xiàn) 用戶點擊提醒蘇打水的披薩的now-index-0按鈕。 但點擊 index 為 0 的按鈕 pizza  的時候，它將會彈出 soda。這也是 React 建議不要使用數(shù)組的索引作為 key 的原因。

到此，關于“JavaScript通過緩存React事件來提高性能”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
分享名稱：JavaScript通過緩存React事件來提高性能
文章URL：http://weahome.cn/article/joocds.html