第十七期 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 优化了这些点：
- 启动配置 Setup，简化 store 创建等
- 简化 reducers 编写 Simplified reducers
- 对于异步的处理，Async actions, Async/Await 取代 Thunks 方案
- 不需要在编写 action type
因此从开发效率上来说，我个人觉得使用 rematch 或者 dva 都比原生手写 Redux 来的实在。问题在于，使用这些上层封装之后，也会带来调试的“不便”，比如你不知道为什么 action 就被 dispatch 了，为什么异步就被“安排的明明白白”了。
如何做选择？当然是在了解 rematch 这些方案的基础上，知其然，知其所以然，那就放心使用这些吧，一定能发挥更大威力。我们团队也有自己的解决方案，使用起来清爽无比～
react服务端渲染前景怎么样？ ─ @yuyurenjie
react服务端渲染前景怎么样
当然是要看具体场景了。适合业务需求，何乐而不为？所以需要分开看吧。
产品对 SEO，首屏加载要求高，SSR 就又发挥的空间。前景肯定会有“一席之地”对，但是要看具体项目，大规模应用那倒也是不可能的吧
项目初期技术选型应该根据哪些因素来选择？ -@gshisan
项目初期技术选型应该根据哪些因素来选择（抛开团队因素）
您好，感谢提问。
- 学习成本和复杂度（如果团队大部分都 hold 不住，那肯定不行）
- 相关技术选型的生态以及成熟度（如果没人用，维护者不积极维护，不好）
- 关键环节的兜底能力（如果相关技术选型执行一半有问题，能不能有人出来解决）
- 备选方案能不能及时跟进
当然，最重要的是是否贴合业务。
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 下面交流技术哟，传送门。
542
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
