高手问答第 210 期 —— 前端开源狂热专家带你深入 React 技术

局长 发布于 08/28 22:36
阅读 2K+
收藏 8

OSCHINA 本期高手问答(2018 年 8 月 29 日 — 9 月 4 日)我们请来了@颜海镜 为大家解答关于 React 方面的问题。

颜海镜,知名技术博主,开源达人,常以歪脖无脸男形象作为头像,经过多年沉淀,专注 Web 前端开发,先后任职于金山、百度、美团点评,负责前端开发工作。著有《React状态管理与同构实战》一书。

React 绝不仅仅是一个灵活、高效的视图层开发库。截至本书写作之时,v16.4.1 版本共有 20 个分支,其代码仓库中有近1万次 commits,94 次发布的背后是 1193 名贡献者的付出,还有 102694 个 stars 和 18568 个forks,这些数字构建起了一个庞大的技术社区,其背后蕴含了海量的优秀设计思想。

React 自开源以来,便以革命性的设计理念迅速颠覆了前端开发的传统意义,其倡导的组件化、状态管理、虚拟 DOM 等思想极大提高了前端开发效率。为了更加高效地维护 React 应用的数据状态,以 Redux 为代表的数据管理模式横空出世。

本期问答内容:

  1. 新人学习 React 觉得上手难怎么办,有没有什么好办法?
  2. React 和其他框架对比有什么特点?
  3. 在状态管理方面,Redux 和 Mobx、Context 对比有什么特点?
  4. React 作为服务端渲染工具,有大规模的产品线实践吗?有没有哪些安全隐患?
  5. React 存在哪些性能问题?是不是在开发应用时总会有性能隐患和瓶颈?
  6. React 组件的设计思路及复用技巧是永远被推荐的吗?该如何避免“过度设计”?

或者其它 React 相关的问题,也欢迎大家积极提问!

为了鼓励踊跃提问,@博文视点 会在问答结束后从提问者中抽取 5 名幸运会员赠予《React状态管理与同构实战》一书。

购买链接:京东

OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。

下面欢迎大家就 React 问题向@颜海镜 提问,请直接回帖提问。

加载中
0
博文视点
博文视点

高手问答第 210 期 —— 前端开源狂热专家带你深入 React 技术

@fattypanda  @NotFound403  @varHarrie  @Andrew1985  @vr和ar加油努力

恭喜以上五位网友或获得《React状态管理与同构实战》图书一本 

请私信 @博文视点   告知快递信息(格式:姓名+电话+地址)! 

1
fattypanda
fattypanda

@颜海镜 react 的状态管理有没有除 redux、Mobx 和context 以外的工具。

1、redux 只能有一个实例、或者说多个实例嵌套容易被别有实例捕获 dispatch 。

2、mobx 虽然没有强制要求一个实例,但是官方毕竟推荐项目中不要使用多个(也许是只之前我的用法问题)。

3、context 虽然可以解决以上问题,但我遇到组件中可跨子组件通信难点时,react的版本为16.2.0,那个时候context 还是官方不推荐的方法。

另外,关于全局状态管理

1、dva 对于我来说,有点太过于复杂,它融合了 redux redux-saga ,所以具备它们的特性,但是这个两东西都是一个复杂度高的东西(并非说有多难,虽然也挺难的,但是文档上80%的东西都是不常用,但需要用的时候找起来又很麻烦)。

2、bbx 很简单,作者和dva的作者也同一个小组,但是目前感觉它的关注度不够,自己玩还行,不敢直接上项目。

除了以上的这些状态管理,有没有什么简单,又能满足大部分需求的工具,最好带可扩展的特性。

颜海镜
颜海镜
另外我的书中也介绍了很多状态管理的内容,可以了解下
颜海镜
颜海镜
业务简单是不需要状态管理工具的,业务复杂才需要使用类似redux的状态工具,个人感觉mobx比redux适合简单一些的场景,还可以看看rematch
1
阳光暖暖-笑容浅浅

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

颜海镜
颜海镜
React中一切都是基于组件,但是组件的粒度确认一个问题,到底是该每个按钮设计一个组件,无比细粒度呢?还是很大模块的组粒度呢? 我觉得对于不同场景,应该有不同的设计理念,对于组件库,那么应该设计的竟可能细粒度,这样才能方便组合; 对于业务代码,则不应该设计得过细,会浪费精力,也不宜过大,过大了维护起来也是个问题,还是老规矩,每个组件不要超过300行挺好
1
NotFound403
NotFound403

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

颜海镜
颜海镜
所以要综合考虑,结合业务场景,如果你个团队同时存在jq和react是可以接收的,但同时存在react和vue就是不能接受的了
颜海镜
颜海镜
对于一个团队来说技术栈肯定是统一更好的,但是还是要看业务是否统一,因为面向c端的和面向内部的系统不统一也可以; 如果你的页面仅仅是内部系统,那么选择react+antdesign是非常好的选择; 如果你的业务是面向c端的,然后页面又比较简单那么react就不是必须的了,也不是最好的选择; 如果你的页面有面向c端的,也有面向内部的,我认为是可以保持两套技术栈的; 两套技术栈就意味着浪费效率
颜海镜
颜海镜
这其实就是技术选型的问题,我将回答react到底适合什么场景,技术栈是否应该统一 如果你的页面交互比较简单,其实使用react,并不能比使用jq提升多少效率,对于这种业务,用不用react是无所谓的; 如果你的页面是面向c端的页面,并且需要做seo,那么就要掂量掂量了,因为你使用react的话就需要使用ssr了
0
八一菜刀
八一菜刀

@颜海镜 React如何快速的入手,有什么学习方法推荐的吗、

颜海镜
颜海镜
快速上手的话,建议阅读一些入门教程,比如阮一峰老师的博客,接下来要实践一下,简单实现一个小程序实践下,接下来就是在学习和实践中循环了 另外React的官网是非常不错的资料,主要作用可用来查阅资料,如果入门了以后,相对React有深入的了解,可以关注下我的新书《React状态管理与同构实战》,京东:https://item.jd.com/12403508.html
0
有人
有人

@颜海镜 怎么正确的理解React的生命周期呢?

颜海镜
颜海镜
每一个软件都会诞生和死亡的一天,React组件也有自己的生命周期,每一个React组件都会经历出生、存在和消亡的过程,在React的世界里,这三个生命周期被称为,挂载(Mounting)、更新(Updating)和卸载(Unmounting) React为每个过程提供了一些回调函数,称作钩子函数,让我们可以自定义一些事情,如果想了解更多的内容,可以关注下我的新书《React状态管理与同构实战》
0
Li_Peng
Li_Peng

@颜海镜 您好,想问一下您对React和Vue等框架未来的发展怎么看,从开发效率和学习成本来看,未来会不会出现比现有前端工程化更简洁的前端框架或开发模式呢?

颜海镜
颜海镜
从开发效率和学习成本来看,未来可能会出现更高效的情况,但从原理上来说,要颠覆现在框架的原理,可能需要很长时间的发展 PS:如果对框架的历史感兴趣,可以关注下《React状态管理与同构实战》,京东:https://item.jd.com/12403508.html
颜海镜
颜海镜
我认为未来React和Vue会长期并存,都会有很多的工作机会,其实在React和Vue之前,框架也是多个并存的情况,另外个人建议不要太局限于框架,在我看来一个功能用Vue和用React来实现,并没有太大的开发效率上的区别
0
Andrew1985
Andrew1985

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

颜海镜
颜海镜
我现在觉得更大的学习压力是对于新手的,而不是老手的,老手其实只要学一个框架就好了,新手要学的东西远比老手多,所以现在前端的上手越来越难了 PS:如果对React感兴趣,欢迎关注我的新书《React状态管理与同构实战》
颜海镜
颜海镜
框架只是改变了UI的写法,组件的写法,其实涉及到逻辑部分,都还是原生的js,所以原生js和框架两个都要学好; 现在前端工程师必须有很强的学习能力,不能面向技术编程,而是要面向解决问题编程,不管什么技术,只要能解决问题就是好的,否则一个技术展被淘汰了,还是要被迫的去学习
颜海镜
颜海镜
我对于框架的态度一直是工作中用到了才回去真正学习,否则不会去深入了解,所以面对繁多的新技术不要畏惧,要感到高兴,因为这才能证明前端在发展,另外如果原始js还没学完,怎么能自称为老手?
0
赤脚小子
赤脚小子

@颜海镜 您好,REACT和VUE的对比也是老生常谈的问题了,二者的竞争已经延伸到了小程序领域,目前在微信小程序开发领域都有了扩展的框架,美团对VUE改造的mpVue和京东对REACT的taro,

您觉得在小程序领域,REACT的优势有哪些?目前我也在做技术选型,比较纠结于taro的学习曲线

颜海镜
颜海镜
十分抱歉,我对小程序不是特别熟悉,我个人感觉写小程序,最好的实现方式肯定是用小程序原生的接口,因为任何其他编译的方式都只能是阉割版,但受限于开发效率和人力成本,诞生了类似mpVue这类项目,我觉得两者可能没有太大差别,但觉我了解taro可以跨越的端更多 技术选型上还是基于团队的情况吧,如果团队更熟悉vue就选mpVue,如果团队更熟悉react,就选taro
0
tikong
tikong

@颜海镜 一个页面多个组件,每个组件里面有相应业务的网络数据请求,初次进入页面,所有组件都能渲染请求数据。

请问从其他页面再次进入这个多组件页面的时候,怎么实现多个组件的这个页面,像初次进入一样渲染请求数据?

谢谢

颜海镜
颜海镜
因为你没有描述业务场景,大概分为两类: 1. 页面数据是定时刷新的 2. 希望页面获取焦点时刷新数据 对于1不需要做额外的处理了,你可以适用 requestAnimationFrame 对于2需要监听页面获取焦点的事件,在这个事件中,重新拉取数据
返回顶部
顶部