likes
comments
collection
share

构建 React 组件的关键概念 / 指南

作者站长头像
站长
· 阅读数 20

《构建 React 组件的关键概念 / 指南》中的一些概念不仅仅可以应用在 React 组件开发方面，本文更深层次的关注点是 “构建组件的关键概念 / 指南”，只不过本文集中围绕 React 展开。本着开放的态度阅读、琢磨《构建 React 组件的关键概念 / 指南》会更合理。

《构建 React 组件的关键概念》额外从《React 哲学》、《React Patterns》提取了些要点。

目录

  • 创建
    • 分析 UI 稿并设计 React 组件
    • 实现静态 React 组件
    • 添加交互
  • 整洁之道
  • 重构
  • 总结
  • 附录
  • 其它
    • 阅读、使用、贡献
    • 交个朋友

分析 UI 稿并设计组件

  • 图示 UI 稿中的组件层级。另外，后续存在调整的可能性，且可以帮助长时间未返工该组件的自己或其他工程师快速理解，所以保留这样的图示；
  • 拆分组件层次的过程中起码要遵循 “单一职责” 这个设计原则。反复温故 “S.O.L.I.D” 设计原则百利无一害；
  • 确定组件在交互、性能、适配等方面的特征，
    • 尺寸感知；
    • 布局感知（响应式）；
    • 网络感知；
    • 硬件感知；
    • 性能感知；
    • ……
  • 合理设定复用性，
    • 复用性格局，
      • 项目内复用；
      • 项目间复用；
    • 格局不同，组件在灵活性方面的设计不同。期望项目内复用性格局下实现的组件在项目间复用，运气好点工作量不大，反之就很苦恼了。打个比方，因为家用飞机缺失战斗机的功能，所以不顾家用飞机的定位设计，毅然拿来充当战斗机使用，一定是蹩脚的，而且与真正的战斗机差距很大，此时研制或换成一架真正的战斗机，会更合理些。根本不可能指望一架飞机同时拥有战斗机、轰炸机、私人飞机、空中巴士等所有的特点；
    • 项目内复用的组件类似于模具，造船、做衣服、吹瓶子的模具。模具成型后，修改的成本极大，几乎不可能跨品牌、跨主题使用。所以，越是仅专注于当前项目的组件越是要明白跨项目复用的局限性。其实从划分组件层级时，就要有具象、抽象组件两种概念，后者为了高度复用，甚至跨项目复用，前者为了直接使用的便利性，项目内复用便利性很强，但自定义能力方面偏弱；
    • 无论项目内抑或项目间复用的组件，对它们的管理也需要一定的规则辅助。像家具商城组织各种或同类型的家具一样，去组织软件组件才是正确的姿势，如果你还知晓很多第三方 UI 套件、组件，也可以用类似的概念管理，会很舒适。椅子，样式很多，不同材质的，不同用途的，不同适用人群的… 按钮、导航栏等也是；
    • 严格、精准定位复用格局。抽屉、抽屉垫，后者完全可以在生产抽屉时就定制好，拿来就用，说不定更节省空间，但那就没了更换、创作的乐趣以及来自可替换抽屉垫方案的利润等。但是更换的乐趣需要用户充分的审美、判断等能力，这又是大多数人缺失的，这会导致权衡的痛苦以及错误判断后的代价等；
    • 重用性越强的组件，属性支持的越多？因为更抽象，因为要支持更多的具象场景（使用场景）。即：一般情况下，属性数量或复杂度与复用程度成正比；
    • 组件层级、特征、复用性、设计原则、抽象、具象等，说了这么多，本质都是为了在相关维度上形成清晰的边界，边界的重要性相当于边境线；
    • 复用形式很多，并非只有 React 组件这一种形式。Hooks、工具函数、数据访问网关等等都是。于本文而言，这条这可能超出了主题，但是于复用而言，还是很合理的；
  • 有条件的话，用视频（动画、摄影等） / 音频 / 文字等方式随笔记录各种细节铺垫等，包括接下来的过程；

实现静态 React 组件

  • 编写静态版本时，不需要考虑太多交互细节；
  • 完全不应该使用 state 构建静态 React 组件，state 代表了随着时间会产生变化的数据，应当仅在实现交互时使用；
  • 组件比较简单时，可以自上而下这么个层次顺序构建，但并不推荐；
  • 较为大型的组件，以 CDD 模式自下而上地构建，这是最佳实践，强烈推荐；
  • 通过 props 传入所需的数据、表达式等。此时是相对于选型数据结构这件事而言蛮不错的时机，但后续存在调整的可能性；
  • 除数据、表达式等之外，将任何可变动的部分，如：UI、算法等，从组件内部剥离出来，通过 props 传入。是否这么做取决于组件复用性的设定，若是项目间复用，最好是这么做，反之，并不需要追求尽可能全面地将可变部分从外部通过 props 传入；
  • 形不变的其它样式变化，如：改改颜色等。所在层级不变的元素变化，如：该层级的整个 UI 需要替换，或者说原本这个位置放的是 A，现在换成另外一个组件 B。无论是哪种复用格局下，它们都可以作为可变动部分经过 props 传入；
  • 从实现静态 React 组件这个过程开始，就要仔细分析以什么模式的组件呈现最合适，并不断在后续合理调整，

添加交互

  • 需要充足的时间考虑大量细节，用异步或串行时间线（见附录）等合适的办法可视出来；
  • 此时并不需要编写太多代码；
  • 遵循 “DRY - Don’t repeat yourself” 设计原则；
  • 找出且只保留组件所需的最小集合 state ，其他数据均由它们计算产生，
    • 该数据是否是由父组件通过 props 传递而来的？如果是，那它应该不是 state；
    • 该数据是否随时间的推移而保持不变？如果是，那它应该也不是 state；
    • 能否根据其他 state 或 props 计算出该数据的值？如果是，那它也不是 state；
  • 看清楚组件是如何被更新的，以及是在哪里被更新的，确定 state 放置的层级位置，
    • 找到根据这个 state 进行渲染的所有组件；
    • 找到他们的共同所有者组件（在组件层级上高于所有需要该 state 的组件）；
    • 该共同所有者组件或者比它层级更高的组件应该拥有该 state；
    • 如果你找不到一个合适的位置来存放该 state，就可以直接创建一个新的组件来存放该 state，并将这一新组件置于高于共同所有者组件层级的位置；
  • 传递改变 state 的函数给元素的事件；
  • 传递改变父级 “state” 或全局 “store” 的函数（变量提升）给元素的事件。分析清楚所需的事件函数提供方，完全外部提供或内外都提供则通过 props 传入外部的，若外部传入的事件基于内部计算结果，则以回调参数的方式传递给外部函数，应该优先考虑外部提供的方式。打个比方，人与飞机的关系是，人驾驶飞机，飞机提供了被驾驶的完整功能。子组件控制父组件、状态提升等可以参考这种场景，并且合理体现这种关系，父组件应尽可能多地提供控制器给子组件。人充当了飞机的控制、方向枢纽，人的控制体验马虎不得，此处人便是子组件，对父组件的控制体验非常重要；
  • 严格反复确认涉及到的组件层级、组件模式、数据结构、算法等是否合理，及时调整；

整洁之道

  • 组件的每一个部分都应该竭尽可能可拆卸重用，否则必然存在不灵活、浪费、低质量等情况，应该竭尽全力接近这个目标，以保证组件足够纯净、灵活；
  • 比起写，代码更多地是给人看的，开发体验格外重要，做不到可持续开发，必然浪费大量人力、财力等；
  • 构建更大的组件库时，代码模块化和清晰度是很重要的；
  • 随着代码重用程度的加深，代码行数也会显著地减少；
  • 单个文件最少化代码量；
  • 经常温故《代码整洁之道》并实践，向知行合一靠拢，不亦乐乎；

重构

隔段时间，最好那会儿你已经淡忘了开展上述过程时在脑子里清晰记忆的各种细节，在这种状态下重新阅读每一行代码，

  • 哪里写的连自己一下子都看不懂了，花点时间搞明白，立马优化一下代码，该补充图示等文档都补上，该语义化的逻辑语义化，表意不清晰的声明都重新命名到自己能懂为止；
  • 琢磨琢磨不使用现有方案的话还可以使用啥方案实现，逮着一个更好的新办法，立马优化一下；
  • 用这份检查清单反复仔细检查下自己的组件，哪个地方没遵守，立马优化一下。
  • 根据书写规范、语言最佳实践等检查每一行、每一段代码；
  • 经常温故《重构》并实践，向知行合一靠拢，不亦乐乎；

就这么持续几个来回，完全不为过。

总结

在正常运行的前提下，践行整洁之道；为了高效运行、合理运行，践行重构之道。只有这样，代码才能经受时间的考验。

附录

用异步、串行时间线等合适的办法，将交互过程可视化出来，也称之为 “用户流程”。具体做法参见下图。

构建 React 组件的关键概念 / 指南

仔细阅读 《分析关键渲染路径性能》 这篇文章，便可知晓这张图的构思。提示：图中从左往右是串行，从上往下是并行。

另外推荐阅读一下《前端日常开发 0 BUG 自测清单》，头第二件事便是：清晰的用户流程。

阅读、使用、贡献

对于初阶 React 工程师，可以先将《构建 React 组件的关键概念 / 指南》作为一个实践指南、检查清单来使用，比完全从黑摸索要安全很多，模仿是最好的开始。巴菲特建议投资初学者最好的投资学习方法就是模仿大师，他在《投资最重要的事》里说：“我一直认为，对于刚开始起步的投资人来说，应该寻找已经被证明长期成功有效的投资方法，然后依葫芦画瓢照着做就行了。令人吃惊的是，这样做的人实在太少了。”再者说，一首好诗、一篇好文章、一手好字，都势必得经历先背诵、阅读、临摹、分析等过程，模仿到熟练，最后才能信手拈来地创作，熟能生巧。

对于高阶 React 工程师，咱们可以一起反复阅读、完善《构建 React 组件的关键概念 / 指南》，以检查、重构自己关于构建一个 React 组件的思维体系。

🚏《构建 React 组件的关键概念 / 指南》格外注重思考框架方面的实用性，也就是说，但凡编写一个 React 组件，可以根据它一步一步辅助自己思考，确保稳妥地开发，🚦。

“从 0 到 1” 编写一个组件的过程，是对本文最好的验证方式。我自己就是这么做的，一旦发现问题，就加以反思、总结，并及时更新到本文中。

交个朋友

我的工作内容涉及的比较多，比如：产品设计；交互设计；命令行客户端开发；Node 模块开发；架构设计、调整；领导团队，协调事务等。研究过的东西，即使当时形成了不错的方案，或者产生了一系列新的认知，过段时间后难免忘记很多细节，这是常态，也很无奈。类似于跑步，跑个几天，体能上来了，不跑了，隔上几周再跑，体能下降，又得重新跑个几天恢复到当初的体能。所以形成这样包含经验、步骤、提示的指南，帮助自己在一段时间后重新开展 React 组件开发工作时，快速恢复当初熟练的状态。

额外的灵感便是前面所说，将这一切分享给其他 React 工程师，并与有意向的朋友一起完善《构建 React 组件的关键概念 / 指南》。

非常希望和大家一起切实探讨咱们遇到的问题，一起持续更新《构建 React 组件的关键概念 / 指南》，一起结对学习、交流、进步，甚至结对阅读 React 的每一行代码。

🗣看完文章有任何疑问，🧐，或者，想和我结对编程的朋友，🤼‍♀️，随时找我！！！我的微信：iyoooooooo。😁🍭

转载自:https://juejin.cn/post/7167260479088230408
评论
请登录