掘金 AMA：听《React 状态管理和同构实战》做者--LucasHC 说 React 和前端那些事

第十七期 AMA 掘金团队请来了《React 状态管理和同构实战》做者--LucasHC 作了为期三天的 Ask Me Anything (AMA) 活动（活动已结束）。第十九期 AMA 正在进行，欢迎去和 Android 技术专家--任玉刚聊聊你的技术疑问和见解，提问传送门

咱们在此精选了一些来自用户的提问及 LucasHC 的回答。

关于 LucasHC

《React 状态管理和同构实战》做者，知乎「前端开发」话题优秀回答者。曾职于百度知识搜索部，负责部门内技术更新迭代，工程项目落地实施；也曾服务于法国能源和苏伊士集团、硅谷 BePATIENT 集团。

社区小伙伴精选提问--技术直接相关

业内有哪些工具或 npm 库或开发模式是能够确切可以帮助解决痛点或者改善现状的呢？？ ─ @黄大发丶

Lucas 前辈你好，我是前端小白黄大发同窗。咱们组内面临着最古老的 react 管理平台重构任务，此次咱们想生成关于咱们管理平台的阅读文档(包括经常使用的 样式命名 工具方法 全局组件 复杂api交互流程 等)。

因此我想提出的问题是：面向 react 代码的可维护性和可持续发展(不要单个功能每一个团队成员都实现一遍)(新成员加入的时候知道有哪些功能能从如今代码中复用 也知道有哪些功能尚未他能够添加实现进去)，业内有哪些工具或 npm 库或开发模式是能够确切可以帮助解决痛点或者改善现状的呢？

谢谢前辈耐心阅读完问题。💛💛

感谢提问，第一个问题我认为提的很是好，很是有意义。

的确，面临项目负责度的提高，各类组件也“爆炸式”增加。如何让这些组件们方便易用，同时能快速上手，不成为负担，又避免重复造轮子现象，良好的组件管理在团队中很是重要。

关于「React 组件管理文档」我能够简单梳理一下，总的来讲，社区上在这方面的探索不少，相关方案也各有特点：

1）最知名的必定是：storybook，请参考 https://storybook.js.org/网页连接 他会生成一个静态页面，专门用来展现组件的实际效果以及用法。缺点：业务侵入性较强，且 story 编写成本较高。

2）接下来是我我的很喜欢的 react-docgen，比较极客风格，它可以分析并提取 React 组件信息，原理是使用了 recast 和 @babel/parser AST 分析，最终产出一个 json 文档。https://github.com/reactjs/react-docgen网页连接，缺点：它较为轻量，缺少有效的可视化能力。

3）那么在 react-docgen 之上，咱们能够考虑 React Styleguidist，这款 React 组件文档生成器，支持丰富 demo，我想可能会更符合您的需求。

4）一些小而美的解决方案，好比：react-doc，react-doc-generator，cherrypdoc，甚至 ant-design 的 Bi Sheng。

5）“本身动手，丰衣足食”，其实开发一个相似的工具并不会太复杂，也仍是比较有趣的。好比，redemo https://imweb.github.io/redemo/网页连接，我也本身实现了相似的平台。有过有时间和精力，有兴趣您能够根据本身的需求，实现一个彻底 match 本身团队的React 组件管理文档。

总结： 推荐程度按照次序排列，最终如何选用还须要您本身根据实际状况作判断。 不知道有没有回答您的问题，还有疑问能够追问。

Happy coding!

在你看来，什么场景适合react来进行开发呢？ ─ @rocky191

以前用的是vue，如今想学学react，感受有些地方比vue麻烦，数据的绑定修改，每次都得手动调用setstate，增长了必定的复杂性。在你看来，什么场景适合react来进行开发呢？

您好，感谢提问。

“每次都得手动调用 setstate”这种非双向绑定的操做，可能暂时让您感受不舒服。可是这也增长了开发者对于程序的把控性、可调式性，主动权在开发者手里。

setstate 正式 React： UI = f(data) 的核心关键，我相信目前您的困扰更可能是习惯的问题，在熟悉 React 以后，会感到他的清爽和便利。

另：setstate 只是处理组件内部本身的数据状态，在大型应用中，这种场景并不会很是很是多，更多的是基于 Redux 或者 Mobx 等对于数据状态的管理。开发者主要关心的是对于数据的设计和贯通，完成正确不可变形流转便可。

为何彷佛目前react选型公司更多些呢？ -@小小石马农

请问在为项目选择前端技术方案的时候，什么状况下适合用react，有哪些考虑因素？react相对来讲比vue开发成本更高，可是为何彷佛目前react选型公司更多些呢？

您好，感谢提问。

我认为，即使“react 相对来讲比 vue 开发成本更高”，那么高出的成本也是有限的。且高出来的这些成本会在：维护成本、复用设计、减小潜在 bugs、生态丰富程度等环节中得到收益。

请问什么场景使用mobx，什么场景使用redux？ -@lunarsprite

请问什么场景使用mobx，什么场景使用redux？还有您对Umi和Dva如何看待？谢谢。

您好，感谢提问。

mobx 和 redux 解决问题相似，都是针对 React 应用当中的数据状态管理的解决方案。可是它们实现以及使用理念有较大差别，对于技术选型，仍是看团队风格和喜爱吧。这二者都比较成熟可靠，我的认为 mobx 更灵活，甚至更偏向面向对象和 Vue 风格，也许在代码量上相对 Redux 有所优点。可是 Redux 这种纯函数的…

咱们怎么在redux，rematch或者dva这些库之间作选择？ -@王宇靖

在作状态管理时，用redux会形成代码增加速度很快，咱们怎么在redux，rematch或者dva这些库之间作选择？

您好，感谢提问。

Redux 确实有一些遭人诟病的一些“问题”（能够参考我在知乎的回答：https://www.zhihu.com/question/263928256/answer/274963347网页连接）

所以就像你所，不少面向简化 Redux 封装的解决方案不少。 好比 Rematch，好比 DVA。就像我所说，这些解决方案无外乎针对 Redux 优化了这些点：

1. 启动配置 Setup，简化 store 建立等
2. 简化 reducers 编写 Simplified reducers
3. 对于异步的处理，Async actions, Async/Await 取代 Thunks 方案
4. 不须要在编写 action type

所以从开发效率上来讲，我我的以为使用 rematch 或者 dva 都比原生手写 Redux 来的实在。问题在于，使用这些上层封装以后，也会带来调试的“不便”，好比你不知道为何 action 就被 dispatch 了，为何异步就被“安排的明明白白”了。

如何作选择？固然是在了解 rematch 这些方案的基础上，知其然，知其因此然，那就放心使用这些吧，必定能发挥更大威力。咱们团队也有本身的解决方案，使用起来清爽无比～

react服务端渲染前景怎么样？ ─ @yuyurenjie

react服务端渲染前景怎么样

固然是要看具体场景了。适合业务需求，何乐而不为？因此须要分开看吧。

产品对 SEO，首屏加载要求高，SSR 就又发挥的空间。前景确定会有“一席之地”对，可是要看具体项目，大规模应用那倒也是不可能的吧

项目初期技术选型应该根据哪些因素来选择？ -@gshisan

项目初期技术选型应该根据哪些因素来选择（抛开团队因素）

您好，感谢提问。

1. 学习成本和复杂度（若是团队大部分都 hold 不住，那确定不行）
2. 相关技术选型的生态以及成熟度（若是没人用，维护者不积极维护，很差）
3. 关键环节的兜底能力（若是相关技术选型执行一半有问题，能不能有人出来解决）
4. 备选方案能不能及时跟进

固然，最重要的是是否贴合业务。

React 升级经验或者建议? -@清秋

在作的一个 16 年开始的存量项目须要进行 React 升级，发现牵一发而动全身，React 从 v15 升级到 v16，发现使用的一些第三方库是依赖 React 15 版本的，如 antd，也要随之升级，还有很是大量的存量代码须要随之调整。想问LucasHC 有没有相似的升级经验或者建议，能够少走一些弯路，感谢。

您好，感谢提问。

升级的话，本身业务还好说，掌控权都在本身手上。可能就是工做量稍微大一点，所以须要记得及时更新，而不是多个大版本以后才去行动，这样带来的成本极大。

确实如你所说，第三方库这方面那就很尴尬了，除非本身 fork (不是特别现实)或者提 PR，通常这些库都 PR welcome 的吧。这也就涉及到对库的选择问题了。。。

从mvc到flux到redux再到不少其余的方案，状态管理演化的过程有什么规律？将来它的趋势是什么？ -@依然君

大神您好，我对于前端状态管理很感兴趣。我想问，从mvc到flux到redux再到不少其余的方案，状态管理演化的过程有什么规律？将来它的趋势是什么？

您好，感谢提问。

状态管理演化的规律永远都是向便捷性和维护性这两个终极目标发展。具体设计实践又会受到依托的“宿主” React，我看了看 Redux 每一个版本的迭代，其实很是有意思，感兴趣能够看一下。

将来趋势，应该仍是 Redux 为主的函数式和 Mobx 为主的偏向面向对象的响应式分立吧，只不过 React 最近几个大版本的变动，会让这些状态管理方案收到必定冲击。

非技术相关--闲聊篇

为啥程序员摆拍都这么骚😆 -@云梦

为啥程序员摆拍都这么骚😆

感谢提问。。。

这个嘛，由于“我不高不帅，没老婆没孩子，可是，我！骚！啊！” 😘

如何看待前端新人从事打杂工做以及频繁跳槽的现象？ -@jsChan

对于初入这个行业的年轻人来讲，你是如何看待前端新人从事打杂工做以及频繁跳槽的现象，你本身在刚入行的时候具体是参与什么工做，工做内容是什么？

您好，感谢提问。

这些问题颇有意义，我依次回答：

1）做为新人的话，若是从事打杂业务，咱们也能够从中吸收成长的营养。这些工做很是适合打牢基础，为之后进阶提供扎实的基础保障。同时也能够思考：这些打杂的活动是否是可以用技术的手段化繁为简？好比常常要作的繁琐 H5，运营页面等，是否能够提取出共性，将这些“打杂”变小，变无。

2）频繁跳槽的话确定不是一个好的现象。这个须要跳槽者本身看清楚各个阶段究竟须要的是什么。

3）以我我的经历，cover 一下上边两个话题。我刚参加工做，也作“打杂”需求，可是经过这些需求快速查漏补缺，完善基础。同时思考如何可以将这些繁琐事情抽象，减小后续开发成本。跳槽的话，我在路径是：应届毕业后大公司工做 3 年，完成职业素养的养成和开发规范化塑形，同时开拓视野，以后在独角兽公司工做 1 年左右，尝试各类挑战，将本身积累的技能加以应用。

怎么写好复杂业务代码？-@尹光耀

hi，在工做当中，业务是很重要的一部分，有时候甚至高于技术，对于刚毕业一年多的人来讲，怎么写好复杂业务代码？还有就是技术该如何推进业务发展呢？

感受我问得太笼统了。在交互特别多的场景下，因为一开始没有想到那么多状况，致使最后修修补补，原来的代码就不忍直视了。即便我对service、controller和format作了分层，但controller仍是会很大，最后老是可读性特别差。本身平时会研究react、redux、mobx之类的源码，可是这些在项目中仍是用不到，顶多写写博客告诉他们怎么用。研究这些深刻的东西，怎么才能和业务结合到一块儿呢？

您好，感谢提问。

这个问题我我的认为提的很是好。针对：

1）如何写好复杂业务代码：这个不是一簇而成的，确定是须要经验积累，跌跌撞撞才能有所心得。你如今也能发现本身的一些问题，好比以为本身对于复杂需求，代码写的“可读性差、初期设计不完善”，这正是在进步的体现。我认为写出组织良好且设计相对完美的代码，没有捷径，你如今已经在正确的路上进步了。同时建议多看看大型项目源码，对症下药。好比针对这个问题，看 React 之类的源码也许不如看一个应用层级更高，或者知名实战项目的源码更适合。

2）您说的“本身平时会研究 react、redux、mobx 之类的源码，可是这些在项目中仍是用不到”，我是彻底深有体会。由于我接触这类技术栈时，公司也彻底用不到。这时候个人作法是，先深刻理论，在知识层面彻底掌握这些内容（这个靠技术兴趣和自驱力了），而后有合适的机会要勇于创造挑战，好比在团队推广并应用落地。我当时正好碰上了一个很适合 React 开发的项目（即时通讯平台），并说服团队采用 react、redux 技术，平时在这方面的积累获得了真实应用。

3）在此以前，怎么才能和业务结合到一块儿呢？个人作法是思考业务中适合使用 React 实现的 feature，私底下作了一个 React 版本的实现。这会为后续 React 推广打下基础，至少你本身得先能 hold 住各类业务需求吧。

---

本期 AMA LucasHC 也回答了不少其余的技术、非技术问题，欢迎去他的 AMA 下面交流技术哟，传送门。

往期 AMA

• 2018 年掘金 AMA 年度总结：16 位技术大牛他们的技术事