一直想写这方面的一些总结，对于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，是在开发科阿卡，赶紧学学知乎吧！