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

85 天前
 zhengfan2016

看 java 味有感

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

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

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

5097 次点击
所在节点    React
52 条回复
sakura1988
85 天前
先证明 A 和 B 的并集真的是公共的,再来复用。
很多时候只是目前看起来一样罢了,相似而不同、皮像肉不像。后续加一点变化,A 和 B 的并集就跟着变小,然后这个复用就作废,并且直接逆变换为屎山。最终结果就是两个完全无关的东西被缝合成一个弗兰肯斯坦。
superedlimited
85 天前
@angrylid @angrylid 真的,都看懵了都,谁家的 react 还有继承啊?文档写得清清楚楚 composition 代替 extends ,仿佛看到了新建项目都是 java17 的时代,还在抱着 java8 吭哧吭哧写着各种设计模式的 javaer (笑🤭
bojue
85 天前
@crysislinux #17 职责单一原则有时候更清晰一点,可复用组件只要不断迭代 case 迟早都是 s 山
zhibisora
85 天前
别拆了, 如果本来就是耦合 UI 或者单个页面的写一起算了, 单文件 600 行还是能读的, 逻辑可读性还能更高, 代码也能简化. 这几天天天看有人说用 claude 写 4000 行的单个文件:) 等以后 ai 能改准了, 没必要考虑拆分, 等要复用时再拆好了
twig
85 天前
我就爱这么写。将来 refactor 的时候,找到那一个地方,嗖一改,就得了。挺省事儿啊。
bruceczk
85 天前
你要是每次遇到重合都抽一个新的组件确实是有点烦人了,毕竟嵌套层数太多也影响效率的。
xzh654321
85 天前
组合优于继承
mxT52CRuqR6o5
84 天前
我个人的经验是:宁可复用不足,也不要过度抽象,复制粘贴也没啥
提前优化是万恶之源
mxT52CRuqR6o5
84 天前
设计师不参与的 UI 组件抽象其实没啥意义,因为没有沉淀成设计规范
keithwhisper
84 天前
首先是一点函数式的味道都没有...
然后这种是无效抽象, 只是现阶段代码相似罢了... 复用代码最好是从逻辑的角度去考虑, 而不是代码块是不是可以合并
ochatokori
84 天前
我写 vue 也差不多这样,像一个上传接口有多种上传样式,我会把上传部分写成 base ,每个样式都写成一个组件,上传逻辑继承这个 base
kongcc
83 天前
看是复制粘贴的成本是否大于拆分的成本。拆分完又不复用,不是自己找麻烦吗

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://yangjunhui.monster/t/1118463

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX