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

我一般会拆成 BaseCard ，ACard ，BCard 三个组件来写，包括 ts 也是，interface BaseCardProps ，然后被另外两个组件继承。我自认为写到还算优雅，组件分拆出来每个文件代码量一般控制在 100 行内，顶多 300 行出一点。
行数超 300 的话，后续有时间整理代码我一般会按不同功能细化继续拆分出组件。看到有人说 javaer 写点简单功能就先写十几个文件然后到处继承，每个类代码很少，难道我一直以来坚持的写法是错误的吗，all-in-one 全堆一起才是正确写法？

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

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

写 react 天天被 上面 diss ，哎

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

曾几何时 写代码前 我会考虑目录结构 代码分层 各种设计模式也算用的很溜 但现在回过头去看 又有什么实际的意义呢(仅自己的看法) 熵增是避免不了的
代码规范 可读性那已经是很久以前的事情了 现在我只想一把梭 看到结果

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

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

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

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

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

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

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

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

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

为啥

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

组合优于继承。

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

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

业务逻辑用 hook 复用

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

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

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

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

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

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

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

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

不超过三处地方复用, 我宁愿 ctrl+c ctrl+v.
设计赶不上需求变化.
特别是那种某个日期后页面展示发生变化, 但还得兼容旧的数据, 我直接 cv, 复用是不可能复用的.

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

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

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

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

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

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

Sonnet3.7 幼稚的碳基生物

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

真正的 react 难道不是}>这样吗，你这 extends 的不够 react

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

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

那还是套娃组合吧（叹气

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

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

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

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

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

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

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

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

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

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

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

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

组合优于继承

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

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

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

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