React一线问题十问十答

原文网址：http://yanhaijing.com/web/2018/09/12/react-qa/

最近在开源中国搞了个问答活动，收到了不少网友关于React的提问，本文挑选出一些比较典型的问题总结一下，对问答感兴趣的同学可以移步这里

问答

问：React如何快速的入手，有什么学习方法推荐的吗？

答：快速上手的话，建议阅读一些入门教程，比如阮一峰老师的博客，接下来要实践一下，比如简单实现一个小程序，接下来就是在学习和实践中循环了

另外React的官网是非常不错的资料，主要作用可用来查阅资料，如果入门了以后，想要对React有深入的了解，可以关注下我的新书《React状态管理与同构实战》

问：问一下React和Vue的区别？React和Vue等框架未来的发展趋势？

从开发效率和学习成本来看，未来会不会出现比现有前端工程化更简洁的前端框架或开发模式呢？

答：关于React和Vue的区别网上有大把大把的资料，这里就不展开回答了，简单来说Vue是MVVM框架，React是一个View层的抽象解决方案

我认为未来React和Vue会长期并存，都会有很多的工作机会，其实在React和Vue之前，框架也是多个并存的情况，另外个人建议不要太局限于框架，在我看来一个功能用Vue和用React来实现，并没有太大的开发效率上的区别

从开发效率和学习成本来看，未来可能会出现更高效的情况，但从原理上来说，要颠覆现在框架的原理，可能需要很长时间的发展

框架都是用来解决具体问题的，未来不会再出现一个新的react了，颠覆react的一定不是react的效仿者，目前来看react能够坚持很久，但是react也有很多不适合的场景，比如动画就非常不友好，前端框架的发展方向应该是围绕解决问题，提升效率来的

问：现在框架很多，原始的js这些还没学完，React跟vue这些已经铺天盖地了，而且框架性的东西会要求大家按照他们的语法或者逻辑来做，对于新人重新开始可能没问题，对于老手来说切换的成本大，容易出错，是否有好的办法？

答：我对于框架的态度一直是工作中用到了才回去真正学习，否则不会去深入了解，所以面对繁多的新技术不要畏惧，要感到高兴，因为这才能证明前端在发展，另外如果原始js还没学完，怎么能自称为老手？

框架只是改变了UI的写法，组件的写法，其实涉及到逻辑部分，都还是原生的js，所以原生js和框架两个都要学好；现在前端工程师必须有很强的学习能力，不能面向技术编程，而是要面向解决问题编程，不管什么技术，只要能解决问题就是好的，否则一个技术展被淘汰了，还是要被迫的去学习

我现在觉得更大的学习压力是对于新手的，而不是老手的，老手其实只要学一个框架就好了，新手要学的东西远比老手多，所以现在前端的入门越来越难了

问：刚好最近也在学习React，也接触了Redux这个状态管理工具，对于React的设计思想稍微有了些自己的理解——精简而又复杂，复杂指的是很容易“过度设计”，显得整个项目有点臃肿庞大，对于这个问题，有没有什么组件设计建议呢？

答：React中一切都是基于组件，但是组件的粒度确认一个问题，到底是该每个按钮设计一个组件，无比细粒度呢？还是很大模块的组粒度呢？

我觉得对于不同场景，应该有不同的设计理念，对于组件库，那么应该设计的竟可能细粒度，这样才能方便组合；对于业务代码，则不应该设计得过细，会浪费精力，也不宜过大，过大了维护起来也是个问题，还是老规矩，每个组件不要超过300行挺好

问：怎么正确的理解React的生命周期呢?

答：每一个软件都会诞生和死亡的一天，React组件也有自己的生命周期，每一个React组件都会经历出生、存在和消亡的过程，在React的世界里，这三个生命周期被称为，挂载（Mounting）、更新（Updating）和卸载（Unmounting）

React为每个过程提供了一些回调函数，称作钩子函数，让我们可以自定义一些事情，如果想了解更多的内容，可以关注下我的新书《React状态管理与同构实战》

问：React在什么时候比较适合SSR呢？

答：React再有node中间层的时候比较适合做SSR，其实是否SSR应该是业务决定的，比如如果你需要做SEO那你就需要SSR，比如新闻网站，内容类网站；对于不需要SEO的系统，比如后端系统，webapp，都是不需要SSR的

想了解更多SSR的内容，可以关注我的新书

问：1、React在表单处理上有没有比较好的解决方案？目前在一些复杂的表单处理上，需要些大量的handleXXXChange方法，Vue中的v-model要简单许多。此外还有表单校验，包括antd在内的ui框架，在这方面的处理都显得相当复杂，不易维护。

2、在render中使用箭头函数和bind都是不推荐的，但是对于列表遍历中传递当前对象：

{items.map((item, index) => ( <li onClick={(e) => this.handleItemClick(e, item, index)}>{item.title}</li> )}

如果不使用箭头函数，有什么比较好的解决方案吗？

答：

可以写一个babel插件，给react扩展v-model的功能哈
表单校验，也可以封装一些高阶函数吧
在原生标签的函数中，使用bind或者剪头函数没什么问题哈，或者可以把值放到dom属性中，这样的性能还不如多一个函数快

问：react redux 怎么处理多线程文档,管理多个请求并发问题?

你怎么看待这种用worker的方式启动新线程的?

var worker = new Worker(js file path);

答：js中是没有多线程的，但是却可以做到请求并发，如果想要多个请求都返回时才处理，可以使用Promise.all

在有密集计算，又不希望卡顿主线程的情况下，原来只能用setTimeout分片，现在可以用worker了，这种方式非常棒，有实际的使用场景

问：做技术选型如何考量react在开发应用的优略？学习成本？也就是说react实际技术落地的技术点？

答：这其实就是技术选型的问题，我将回答react到底适合什么场景，技术栈是否应该统一

如果你的页面交互比较简单，其实使用react，并不能比使用jq提升多少效率，对于这种业务，用不用react是无所谓的；如果你的页面是面向c端的页面，并且需要做seo，那么就要掂量掂量了，因为你使用react的话就需要使用ssr了

对于一个团队来说技术栈肯定是统一更好的，但是还是要看业务是否统一，因为面向c端的和面向内部的系统不统一也可以；如果你的页面仅仅是内部系统，那么选择react+antdesign是非常好的选择；如果你的业务是面向c端的，然后页面又比较简单那么react就不是必须的了，也不是最好的选择；如果你的页面有面向c端的，也有面向内部的，我认为是可以保持两套技术栈的；两套技术栈就意味着浪费效率，基建可能要做两套，这也是一个问题

所以要综合考虑，结合业务场景，如果你个团队同时存在jq和react是可以接收的，但同时存在react和vue就是不能接受的了