一直想寫這方面的一些總結，對於React Web組件的渲染優化，很早就已經有一個明確的設計思路了。不過就個人而言，我還是喜歡等待實施的結果，想法和數據都得到了印證之後，再拿出來分享。
大概是去年年底，我就給團隊裏面的React程序員提出了一個任務，就是分析和解析國外的一些較爲成功的React大數據的Table組件。嗯，想必小夥子抱着想當然的心態，並沒有按照我的要求去做，他最後回覆我，爲什麼需要在一個頁面同時加載上萬條的數據？認爲此需求本身就立不住腳。當時我也覺得是，一下子加載那麼多數據，別說組件渲染，光服務器通信就夠吃力了。傳統思路一頁一頁加載不是挺香的嘛！
之後一路無話，直到若干個月前，封裝了一個React Table組件，最初並沒想着兼容大數據，只是想把導出Excel，各種過濾導出到Excel的工作徹底的推到前端去解決。然後就發現，哦喲，現在前端生成幾千條數據的Excel居然那麼爽快了（不是Excel的XML，是Excel的bin），確實可以用此解決定製Excel輸出的問題，但Table組件必須能承載更多的數據。
當然，實際上那時候已經升級到了React 16.1了，渲染的性能已經比15版本時要更優秀了，加載個幾千條數據，隨便排個序，篩選幾個字段值，毫無壓力。不過我還是抱着一顆追求和探索的心，開始了對這個Table組件的再次優化之路。
針對渲染速度優化，是一個分層遞進的問題。
第一，雖然有上萬條數據，但是每一次一屏內要實際渲染的數據，只有x條（具體看用戶選擇一頁多少行了）。這裏其實還可以再細化，就是一屏內多少列，但目前沒有實施到這個細節（就16版本，其實不需要了）。
第二，儘量避免在table cell再次渲染一個React組件，取而代替的，可以選擇直接插入html代碼，往往這裏只是要插入一些簡單的樣式而已。
第三，對於特定的值過濾，不必要過濾全數據，而可以選擇在渲染前過濾。全數據1萬條，每條都過濾一下，和當前只渲染x條，過濾當前渲染的x條，顯然後者更實在。
第四，不必將全數據都放在React的State中，只需要把當前要渲染的x條放入State即可。
第五，大數據的操作（過濾，排序），不要輕易觸發Table的State的改變，而在內存中進行，數據處理完畢（包括分頁過濾）後，再通知Table更新State（最最關鍵）。這就要求，涉及對應大數據操作的組件，必須自身持有State，而不要隨便的去觸發Table組件（或Table所在容器組件）State變化（兩者的依存關係要搞清楚）。
嗯，所以這個Table組件，迎來了第二個版本，這是幾個月前的結果。
上上週，突然出現一個需求，需要基於現有的某些基礎記錄，進行數據推算。因爲一些緣故，無法將這些推算結果寫入數據庫，只能前端持有（每次都動態推算）。基於10000+條左右的基礎數據，會產生10幾萬次的循環（分拆和匹配），然後界面同時呈現（持有）幾萬條推算結果。一波操作下來，發現Table組件居然如絲般順滑，毫無卡頓。
事實上，React Web最大的優勢就在於，不必要呈現的DOM節點和數據，在React是完全不會渲染的，也不會形成在DOM節點上，而不是簡單的將其display none。所以，很多循環和運算，可以推到渲染前和渲染時再去執行，控制的粒度，可以精細到用戶與界面發生交互時才進行進一步的計算，自然將大大的提升組件的性能，用戶不易感知其中變化，而組件可承載的數據量卻是過去的幾何倍增長。
然後再導出這樣的數據到Excel（不是Excel的XML，是Excel的bin，不知爲何總有人抱着老黃曆），10MB的數據，也不過一瞬間。
嗯，可以的，前端真香。
----------------------------------------------------
哦，對了，補充的說一句，大量用Vue的小朋友們，要注意了，你們開發的組件存在大量的卡頓。沒錯，說的就是你，開源中國，還有bilibili，開多幾個Tab就卡，你們不是在開發Web，是在開發科阿卡，趕緊學學知乎吧！