React之路

今天把第一个用在生产环境的React项目提交了，总算是在前端之路上迈出了另一步。

当初选择这个技术栈的时候还是很忐忑的。一方面是传闻中陡峭的学习曲线，另一方面也是框架大战乱花迷人眼。不过这个小项目的完总算是让我松了口气，总算是证明了可行性。

回顾这几个月的学习历程，不得不承认人最大的敌人的是自己。如果当初我选择了那个熟悉的开发环境，就绝对不会在几个月后有如此的进步。主动放弃舒适区是种煎熬，好几次我都在想: 如果用xxx的话很快就可以解决啊。好在忍住了回头的冲动，硬着头皮踩完坑，也理了解了许多之前从未思考过的问题。

React本身并不难，只要理解了props和state的区别就可以上手了。但React只解决了view的问题，要构建完整的项目还需要搭配其他组件，而React的生态环境才是真正复杂之处。SPA必须上router，于是得学react router，如果要配合redux还得考虑react redux router。state的管理是上flux还是redux呢？或者新鲜出炉的mobx也不错？考虑国际化，又得从许多i18n库中选一个。项目的工程化又是个难题，构建的webpack是标配了，还得熟悉各种插件。然后是测试，karma、jsdom、mocha、chi、jest、tape、enzyme……看到这里许多人都已经懵逼了，更别提去一一熟悉这些组件了。

我的学习方法是抓住本质：React is React，任何围绕React构造的组件必然符合props和state的概念。熟悉了React，其他的组件自然也不会难理解，用到时再去看docs就可以了。在选择组件的时候必须问两个问题：这个组件解决了什么问题？我现在有这个问题吗？回答不出来就不要因为cool而添加组件，必须牢记：多增加一个组件，就给项目多增加了一分复杂性，也就减少了一分项目的稳定性。

至于JFX和v-dom，我认为如果不是做理论研究的话，可以先将他们当作既成事实先用起来。当React相关代码写多了，这两个看似怪异的东西的作用自然了然于胸。现在我再回过头去看，v-dom其实就是一个表示dom结构的JS object，而JFX则是创建这个object的简化语法。

React不再依赖event listener来同步dom更新，而是当state改变的时候就重新渲染整个dom。这简化了state的同步，但重新渲染dom却是十分影响性能的。比如有一个包含一百个子项的列表，当其中的一个改变时就得重新渲染这一百个子项，这样的性能必然是无法接受的。于是v-dom的作用就体现出来了：React的render函数改变的只是v-dom的结构，再用v-dom和dom的状态做比较，找出真正需要渲染的dom部分。于是一个既简化了状态同步，又相对高效的方式就这样产生了。另外，由于增加了v-dom这个抽象层，React不再完全依附于Web。v-dom可以和各种原生平台进行映射，我们就有了目前大热的React native跨平台解决方案。

这就是为什么React不再使用常见的template，而是由render函数返回一个v-dom，最后由framework来做算法比较最后更新dom或是其他native组件。一篇比较React和Angular的文章一针见血的指出了他们的本质区别：Angular使用JS来强化HTML，而React本身就是JS。

一个优秀的framework不仅要有优秀的特性，更应该引导开发者写出优秀的代码。这一点上，强调FP和组件分离的React无疑是成功的。组件化的概念从Web component标准就引入了，而首先将这个概念大规模用于生产环境就是React。我个人认为React在这一点上的意义远胜过v-dom或JFX。而FP的好处我就不再复述了，从React这两年的发展可以看出社区明显的FP倾向，这或许会对JS标准的发展产生一定的影响。

我从来就不是一个框架原教旨主义者，我相信很快就会有更优秀的框架取代React，Web必将踏过React的尸体继续前进。学习一个框架不仅是产出项目，更是开阔思维和成长技能。每一个优秀的框架都有可取之处，选择任何一个公认优秀的东西都不会错。

关键不是选择，而是专注。