反思，我写的前端的 react 味是不是太重了

[zhengfan2016]

看 java 味有感

假如前端有如下页面组件 a 和 b ，a 和 b 中有一部分并集的功能，比如 card 的边框，标题什么的

我一般会拆成 BaseCard ，ACard ，BCard 三个组件来写，包括 ts 也是，interface BaseCardProps ，然后被另外两个组件继承。我自认为写到还算优雅，组件分拆出来每个文件代码量一般控制在 100 行内，顶多 300 行出一点。

行数超 300 的话，后续有时间整理代码我一般会按不同功能细化继续拆分出组件。看到有人说 javaer 写点简单功能就先写十几个文件然后到处继承，每个类代码很少，难道我一直以来坚持的写法是错误的吗，all-in-one 全堆一起才是正确写法？

[hwdq0012]

好代码是重构的，一般按经验设计就好，不用过度设计，按需要重构即可， 主干设计抓好，git flow 抓好，可快速重构，先做一个垃圾出来， 况且 mvvm 能垃圾到哪去（ react 是 mvvm 还是 mvc 忘记了

[crysislinux]

我倾向于共享逻辑而不是继承组件。

[Uncertainty]

写 react 天天被 上面 diss ，哎

[herm2s]

以偏概全是最不可取的，你说的那种十几个文件到处继承的写法，只有时间太多的人才会那么干，都是干开发的心里清楚，自己写那点垃圾代码还没点数吗

[kxg3030]

曾几何时 写代码前 我会考虑目录结构 代码分层 各种设计模式也算用的很溜 但现在回过头去看 又有什么实际的意义呢(仅自己的看法) 熵增是避免不了的

代码规范 可读性那已经是很久以前的事情了 现在我只想一把梭 看到结果

[zhengfan2016]

@crysislinux 纯逻辑共享一般用 hook ，这个主要是样式和 dom 结构上的共享

[serco]

为啥你会觉得除了十几个文件继承，就只剩下全堆在一起的写法了。

继承现在不都丢得差不多了吗，都是 mixin composition

[zhengfan2016]

@hwdq0012 react 和 vue 是 mvvm ，好像只有 thinkphp 等那些传统后端渲染才是 mvc

[InkStone]

如果没有哪个地方需要以 BaseCard 作为通用去访问这两个组件，那不建议以 is-a 的语义做抽象。如果有的话，也优先使用 interface （我不熟悉 ts 的 interface 语义，不知道是不是跟 Java 一样），interface 用不了再考虑继承。

[wangtian2020]

我不拆，你越是想把耦合的东西拆开就越发现自己在浪费时间。页面逻辑本来就是耦合的，代码为什么要解耦，根本解不出来，左手倒右手的解耦没意义。

[shintendo]

感觉就是过度设计强迫症，跟 react 关系不大

[ipwx]

成熟的组件库，card 一般也没 N 个。

如果你需要 N 个 card ，不如想想你是否有这么多种风格非常不一样的 card 。能不能用参数解决

[zy0829]

@Uncertainty 为啥

[bler]

我的建议是有个大致的模块继承关系就行，别在基类放太多东西，就算 A,B card 有重复的定义也行，避免到时候又出现一个 C Card 但是不需要 base card 中的某一个属性。我之前写代码就是这样，写的太细了，考虑的太多了，尤其是项目从 0 开始的时候，有一个大致的继承关系就行，别考虑太细，扩充容易，但是拆分功能难，人无法考虑东西特别完整，留着扩充的接口，写重复代码无所谓，以完成任务为主，后续项目功能完善了，再考虑提取公共部分的内容

[136475688]

组合优于继承。

[RRRSSS]

关键是拆完之后，如果之后想要添加个 props ，还要全盘考虑兼容已经用了这个组件的页面。

我的意思是，如果是业务页面，怎么简单怎么来吧。

业务逻辑用 hook 复用

样式组件基本现在都有组件库吧，再封装一些针对业务的组件(Title 、Card 什么的)

[crysislinux]

@zhengfan2016 共享组件结构我倾向于拆开搞几个组件来组合，共性不是很大我倾向于各搞各的。

[ltaoo1o]

@ipwx 多年经验，拆成 N 个是最优解。加参数解决，随着参数的增加，到后面一定会出现避免影响其他组件，复制一份或重写一个。

[wu67]

个人经验, 相似界面的业务组件, 不写成一个. 相似的数据逻辑, 写成函数.
接手过最离谱的一次💩山, 一个弹窗表单组件 7 个页面用到, 改一个地方, 查 7 个页面有没有改错...

[paopjian]

基础组件可以拆细点, 但是定了型最好就别改了
我是宁愿复制一份给新需求, 也不敢去再改已上线的功能, 越想着适用各种场景, 未来要细调的地方越多. 麻烦的一点就是如果要统一加什么功能还得一个个去改.

[zhengfan2016]

@ipwx 一般单纯能用 className 解决的，肯定不会分拆组件的。就算 tailwindcss 超长，也有 cva 这些好用的 tailwindcss 复用工具，像我需要分拆的都是属于两个组件 dom 层级不相同的组件。

[NerbraskaGuy]

组件癖吧，之前遇到的一个老项目，里面公用组件就快百来个，有的点进去看还就十几行代码，要说删掉吧，组件之间互相嵌套还贼复杂。

[kneo]

好像还是 java 味儿，没看出 react 味儿。

[jqtmviyu]

不超过三处地方复用, 我宁愿 ctrl+c ctrl+v.

设计赶不上需求变化.

特别是那种某个日期后页面展示发生变化, 但还得兼容旧的数据, 我直接 cv, 复用是不可能复用的.

[chenliangngng]

永远不要主动写继承，除非你接手的是写前端的 javaer[doge]

[SayHelloHi]

复制 + 粘贴 上线能跑就行 😁

[DICK23]

react 的代码风格就不适合继承写法

[jiuhuicinv]

能出活就行了，怎么实现的不重要

[jamesjammy061]

我一般是写一起，大了再拆出来。或者预期一开始就能预料到是分开写的，我也会先写一起，写的一定程度再拆

[wakarimasen]

我难道穿越了？
React 前几年的复用方式是 Mixins 和 HOC ，近些年是 Hooks ，到底哪个世界线的 React 依赖继承来复用。

[ty29022]

Sonnet3.7 幼稚的碳基生物

[linkopeneyes]

拆成互不关联的功能还行，我觉得最完美的是底层单一功能或者只有样式的 Headless 组件，中间一层基于 Headless 组合的功能组件，最后写一个大而且全的脏业务组件

[otakustay]

真正的 react 难道不是<BaseCard customize={<ACard />}>这样吗，你这 extends 的不够 react

[ragnaroks]

过度设计，如果时间充裕倒也不是坏事，但是往往最缺少的就是时间

[leokun]

我是把不一样的地方用 children 或者 props 传进去，应该是最直接的方法，而且也没那么烂

[ipwx]

@ltaoo1o 那还是套娃组合吧（叹气

[qingyingwan]

看起来感觉是工作经验比较少的前端。我当年 react 一两年经验的时候也经常纠结这种代码细节。现在做后端了，也遇到过这种纠结细节的，各种规则一大堆，代码 pr 要一周。结果核心的服务性能，延迟，稳定性，可观察性，架构设计都是依托。

[tonytonychopper]

我一般会写一个 Card ，视情况在 Card 提供 props 做差异化

[gouflv]

前端组件早就不是 oop 的思维了

[twofox]

我实在是太想吐槽公司的项目了。我说不上它到底是 vue 味还是 react 味，但可以肯定一股子屎味

前端用 vben admin 2.x 当脚手架

一个 vue 项目，学 react 封装了一大堆 hook 。配合 vue 稀烂的 ts 支持，用的实在是太难受了

[sakura1988]

先证明 A 和 B 的并集真的是公共的，再来复用。
很多时候只是目前看起来一样罢了，相似而不同、皮像肉不像。后续加一点变化，A 和 B 的并集就跟着变小，然后这个复用就作废，并且直接逆变换为屎山。最终结果就是两个完全无关的东西被缝合成一个弗兰肯斯坦。

[superedlimited]

@angrylid @angrylid 真的，都看懵了都，谁家的 react 还有继承啊？文档写得清清楚楚 composition 代替 extends ，仿佛看到了新建项目都是 java17 的时代，还在抱着 java8 吭哧吭哧写着各种设计模式的 javaer （笑🤭

[bojue]

@crysislinux #17 职责单一原则有时候更清晰一点，可复用组件只要不断迭代 case 迟早都是 s 山

[zhibisora]

别拆了, 如果本来就是耦合 UI 或者单个页面的写一起算了, 单文件 600 行还是能读的, 逻辑可读性还能更高, 代码也能简化. 这几天天天看有人说用 claude 写 4000 行的单个文件:) 等以后 ai 能改准了, 没必要考虑拆分, 等要复用时再拆好了

[twig]

我就爱这么写。将来 refactor 的时候，找到那一个地方，嗖一改，就得了。挺省事儿啊。

[bruceczk]

你要是每次遇到重合都抽一个新的组件确实是有点烦人了，毕竟嵌套层数太多也影响效率的。

[xzh654321]

组合优于继承

[mxT52CRuqR6o5]

我个人的经验是：宁可复用不足，也不要过度抽象，复制粘贴也没啥
提前优化是万恶之源

[mxT52CRuqR6o5]

设计师不参与的 UI 组件抽象其实没啥意义，因为没有沉淀成设计规范

[keithwhisper]

首先是一点函数式的味道都没有...
然后这种是无效抽象, 只是现阶段代码相似罢了... 复用代码最好是从逻辑的角度去考虑, 而不是代码块是不是可以合并

[ochatokori]

我写 vue 也差不多这样，像一个上传接口有多种上传样式，我会把上传部分写成 base ，每个样式都写成一个组件，上传逻辑继承这个 base

[Liamccc]

看是复制粘贴的成本是否大于拆分的成本。拆分完又不复用，不是自己找麻烦吗