代码实现方式的纠结 / forwardRef 类型定义的问题

2022-05-09 · 周一郁闷多云

工作日常依然是继续重构 SA 项目,这里面的坑真的多。今天又给栽在了“编码实现方式”上。任何编程语言都是灵活的,最终效果哪怕是同一种,背后的实现都可以是百花齐放的。

相较于老版本的“穿插式”方案(弹窗哪一层组件调用就放哪里)这次重构我把组件关系给“扁平化”(无论调用位置在哪里,弹窗都放在父组件里面)了。这种方法显而易见,结构清晰,可读性蛮好的,缺点就是父组件承载的“压力”会比较多,因为它们的状态均由父组件进行管理,代码会略多一些。

我也就这件事情和公司的 @LW 同事聊了聊,他就很随性,说我怎么顺手就怎么写就行。我感觉我一个人都能想出很多写法,甚至今天的我再去看去年的我写的代码也是坨屎...

感觉这种问题真的是没有绝对的对和错,我手里这种问题太多了,全是纠结,天天背着这种包袱,感觉怎么写都是垃圾

也不知道这样的问题,要怎么逐渐去改善了,希望各位能给予我一些更好的建议吧...

晚上打完原神到了十点,之后继续维护项目。回到了「保罗 API Next」项目下,尝试把「奇趣播放器」移植到 React 环境下,期间通过公主连结 OP《Lost Princess》这首歌,发现播放器的歌词解析算法有些许不妥,稍作了些许改进并提交到了 GitHub

播放器组件使用了 forwardRef 转发给父组件,实现了父组件操作子组件的功能。在给组件参数设置 TS 类型的过程中,发现一个小问题,就是 FC 组件如果 props 只有 ref,你的 TS 定义也不能给 props 的类型设置为 undefined,否则会出现 ref 参数校验失败(不能将类型“RefObject<>”分配给类型“never”)的情况,需要注意下。

// Correct
export interface KPlayerProps {}

function KPlayer(props: KPlayerProps, ref: Ref<KPlayerRef>) {}

// Error
function KPlayer(props: undefined, ref: Ref<KPlayerRef>) {}
Lost Princess

Lost Princess

M・A・O
Paul

Paul

特立独行的一只前端菜狗。这篇日记编写大概耗时了 0 分钟,内容均为个人原创,并采用 CC BY-NC-SA 4.0 授权协议,转载请注明来源,谢谢!如本站内容对你有所帮助的话,不妨 捐助支持 一下?

近期评论

鲍小螺: 前辈多多指教!ahu: 后生可畏寻梦xunm: 真不错,板子很好看。timochan: 太惨了( ,更新暴毙,如果恢复没成功,数据也 dump 不出来鲍小螺: 在这部分对话中,广树和保罗继续讨论生活的不同方面。保罗提到了技术更新和国内的优秀 IT 技术。广树解释了在国内积累的经验如何在日本产生穿越的感觉,并表达了对于日本生活节奏的喜爱。他还提到了医疗水平的差异和对于生活方式的感受。保罗表示,通过动漫和现实的对比,艺术来源于现实,日本生活的确有着独特之处。他们讨论了国内的生活节奏和就医等方面的压力,以及个人选择的自由。最后,他们也谈到了不结婚不买房的选择和对于房价的困扰。鲍小螺: 该对话进一步讨论了房地产和税收的问题。保罗提到了国内的房地产税和增值税以及日本的固定资产税。广树解释了日本房地产税的收取方式,以及房产税对于国内房产的影响。他认为,与国内相比,日本的房子质量和服务更好。保罗提出疑问,为什么自己拥有的地也要交税。广树解释了类似增值税的原理,并指出在日本拥有房产是稳定安全的。最后,保罗表示从广树的角度来看,情况确实是如此。鲍小螺: 这篇文章的聊天记录也尝试过用 GPT 总结,结果并不是太好,不知道是不是 Prompt 的问题,实际出来的内容过于简练了,于是又耗费了半小时写完,呼~
奇趣音乐盒技术源于 Kico Player
Emmm,这里是歌词君