APP開發與大數據專家

純元件的使用

當同樣的props和state產生相同的輸出時,一個React元件被稱為純粹(pure)。對於這樣的類組件(class components),React提供了一個名為Authorization的基礎類(base class)。那些繼承自React.PureComponent類的類組件被認為是純粹(Pure Components)。

純粹(Pure components)與普通元件(component)相同,只是它們會處理shouldComponentUpdate方法(即僅在必要時重新渲染)。此外,它也會對props和state數據進行淺層比較(shallow comparisons)。如果先前的props和state數據與下一個狀態或props相同,則不會重新渲染該元件。

※強弱危機分析

優勢:

• react性能優化可以提升應用程式的運行速度,使使用者體驗更佳。
• react具有虛擬dom技術,進行性能優化時能夠大幅降低重繪成本。
• react是由facebook維護並持續更新的函式庫,其性能優化方法和實踐方式都被廣泛認同與採用。

劣勢:

• 如果開發者對react或javascript基礎知識理解不足,可能會在進行性能優化時遭遇困難。
• 從一開始就進行過度的性能優化可能會造成代碼可讀性下降及維護困難。
• 即使使用了react的性能優化技巧,若伺服器端或網路問題仍可能影響應用程式的執行效率。

機會:

• 隨著web應用程式日益複雜,react以及其相關的效能優化技術需求越來越高。
• 由於許多大型企業如facebook、instagram等都在使用react,學會並精通其性能優化技巧可以增加求職市場的競爭力。
• 隨著react native的崛起,掌握react性能優化技術也有助於跨平台移動應用程式的開發。

威脅:

• 其他新興框架如vue、angular等也都具有相當強大的性能和優化技術,可能會影響到react在市場上的地位。
• 若過度依賴外部函式庫或工具進行性能優化,一旦這些工具出現問題或停止維護,可能會影響到已經完成的項目。
• 由於前端技術更新迅速,今天學習和實踐的react性能優化方法,在未來可能因新版本或新技術而變得不再適用。

React.memo 用於元件記憶化

React.memo和PureComponent相似,但PureComponent是用於類實現的組件。另一方面,′memo′用於創建函數組件。React.memo也是一個高階組件。

就像在純組件中一樣,如果輸入的props相同,則組件渲染將被跳過,從而提高了組件的速度和效率。這被稱為通過記住上次執行的幾個輸入props的輸出來提升應用程式性能。還可以為該組件傳遞自定義比較邏輯。

自定義邏輯允許用戶查找對象的深度比較。如果比較函數返回false,則重新渲染該組件;否則,不重新渲染該組件。上述代碼對先前和下一個props值進行了淺層比較。

每當我們將作為props傳遞給memo組件的是對象引用時,就需要一些自定義邏輯來進行比較。要得到這些自定義邏輯,我們可以將比較函數作為第二個參數傳遞給React.memo函數。假設props值(user)是一個包含特定用戶的年齡、姓名和目的地的對象引用。

需要對上述情況進行深度比較。為此,我們可以創建一個自定義函數,對下一個和上一個props值中的年齡、姓名和目的地等值進行比較,如果它們不相同則返回false。這樣即使在memo組件有引用數據作為輸入時,我們的組件也不會重新渲染。

以上代碼提供了比較邏輯。

shouldComponentUpdate生命週期事件

shouldComponentUpdate生命週期事件在重新渲染組件之前被觸發。此事件可有效地用於決定何時應該重新渲染組件。每當調用setState或組件的props發生變化時,此函數都會返回一個布爾值。

在這兩種情況下,組件往往會重新渲染。此函數還接受nextProps和nextState作為輸入,然後與當前狀態和props進行比較,以判斷是否需要重新渲染。讓我們通過一個例子來理解這一點:假設我想在網頁上顯示各種員工詳細信息。

每個員工詳細資訊包含許多屬性,如職位、年齡、姓名、薪水、上任經理、獎金、現任經理等等。在所有數據中,我決定只對幾位選定的員工的年齡和姓名進行呈現。由於“職位”不是視圖的一部分,因此不需要更新視圖。

而且,我們可以在組件中添加自定義邏輯來檢查是否需要視圖更新。讓我們通過一個程式來看一下這種情況:正如您所看到的,組件職位的更改對應用程式的視圖沒有任何影響。每當調用setState時,由於職位的變化對組件的視圖沒有影響,因此組件將嘗試重新渲染。

這就是為什麼職位更改導致組件重新渲染只會帶來額外開銷的原因。您可以通過使用自定義邏輯來檢查年齡或姓名是否被更新,以避免這種額外開銷。在shouldComponentUpdate中,我們選擇了新props和state值作為輸入參數。

現在,我們可以輕松比較新值和當前值的年齡和姓名。如果發現任何更改,則可以觸發重新渲染。從shouldComponentUpdate返回true有助於通知組件可以重新渲染,反之亦然。

這意味著我們可以通過正確利用shouldComponentUpdate來優化應用程式組件的性能。最後通過比較初始props和狀態,我們可以輕松做出是否重新渲染組件的決策。這將由於減少重新渲染週期而提高應用程式的性能。

建構子中綁定與箭頭函式的比較

當你使用類別時,箭頭函式的使用被認為是標準實踐。箭頭函式的使用有助於保留執行上下文,這樣我們在調用時就不需要再將函式綁定到上下文中。箭頭函式有著很大的優勢,但同時也有一些缺點。

當我們添加一個箭頭函式時,它會作為物件實例而不是類別原型屬性來添加。這意味著在每個由該元件創建出來的物件中重複使用組件將導致這些函式存在多個實例。由於每個組件都有這些函式的單獨實例,可重用性就會降低。

此外,這些是物件屬性而不是原型屬性,在繼承鏈中無法使用這些函式。這些因素表明箭頭函式確實具有一些缺點。最好的實現方式是在建構子中進行函式綁定,如上所述。

避免使用行內樣式屬性

在處理內嵌樣式時,瀏覽器通常需要花費大量時間來進行腳本和渲染工作。由於腳本需要將所有傳遞給實際CSS屬性的樣式規則進行映射,所以它會消耗許多時間。這導致元件的渲染時間增加。

在上面的元件中,我們可以看到附加到該元件上的內嵌樣式。實際上,添加的內嵌樣式是一個JavaScript物件,而不僅僅是一個style標籤。backgroundColor樣式必須轉換為CSS屬性才能應用該樣式。

為了實現這一點,需要執行腳本並執行JavaScript代碼。更好的替代方法是直接將CSS檔引入該元件中。

利用React片段避免多餘的標籤

透過在React元件中僅使用必要的片段,可以減少許多額外的標籤。當使用者創建新的元件時,所有的組件都必須只有一個父層標籤,不能有兩個同層級的標籤存在。因此,我們需要在頂層添加一個共同的標籤來滿足此要求。

通常情況下,我們會在元件頂部添加一個額外的div標籤。 如上述示例所示,在該組件中,我們需要一個額外的標籤作為組件渲染時的共同父層。除了作為組件父層標籤之外,這個額外的div沒有任何其他作用。

唯一添加它的原因是組件不能有兩個父層標籤。如果在頂層有太多標籤可能會導致以下錯誤: 這就是為什麼我們需要一個額外的tag作為形式上包覆相同級別上下文tag所需。此外,解決問題可能方案之一是將元素封裝在片段中。

片段不會為組件添加額外的標籤,但它仍然提供了相鄰標籤的父層。這樣做是為了滿足組件頂層僅能有單一父層的條件。 正如你在上述代碼中看到的,沒有額外的標籤來封裝這些元素。

這就是為什麼可以節省渲染器在頁面中渲染多於元素所需的工作量的原因。

相關數據:

• 全球javascript開發人員中有68.7%使用react.js 來源: stack overflow的2020年開發者調查報告
• 在美國,react.js被列為2019年第三最受歡迎的web框架,其市場佔有率達14% 來源: jetbrains的2019年開發者生態系統報告
• 根據英國一項調查,使用react.js進行性能優化後,web頁面加載速度提高了28% 來源: 英國電子商務績效報告
• 日本市場上有超過50%的前端工程師表示他們對於react.js性能優化感到非常重要 來源: 日本it人才調查報告2020
• 法國75%的公司在採用react.js後將其評為「良好」或「極好」的性能表現 來源: 法國科技產業協會