做开源组件这件事，让我改掉了很多自我感动式开发
有一段时间我特别容易陷入一种状态：自己觉得这个设计挺巧、这个实现挺优雅、这个抽象挺漂亮，于是很容易被“我写得不错”这件事打动。
后来做开源组件做多了，我慢慢发现，很多这种自我感动并没有太大意义。
因为开源不会因为你觉得自己写得好，就自动变成一个好用的东西。真正决定它价值的，还是别人接进去顺不顺、踩坑多不多、边界稳不稳、文档清不清楚。
“我觉得合理”和“别人用得顺”不是一回事
以前自己写组件，很多默认前提都在自己脑子里。
我知道这个参数该怎么传，我知道这个组件主要给什么场景用，我知道哪些边界先不处理也没关系。所以很多设计在我自己眼里是合理的。
但一旦放到开源里，这些默认条件就全都消失了。
别人只会按他自己的理解来接，你写得不够直观，他就会困惑；默认行为不够稳，他就会踩坑；文档说得不够清楚，他就会觉得这个组件“不太敢用”。
这时候你会很快明白，组件设计最重要的，不是你自己觉得顺，而是使用者第一次接触时能不能顺。
我开始更在意默认值、命名和兜底
这些东西听起来都不大，但恰恰最容易暴露一个组件是否成熟。
默认值是不是符合直觉，命名是不是能让人一眼看懂，出错时有没有兜底策略，扩展场景下会不会把 API 撑得很奇怪，这些问题以前我没那么敏感，后来却越来越在意。
因为开源组件和业务代码不一样。
业务代码很多时候只要团队内部约定清楚就够了，但开源组件面对的是不确定的人和不确定的场景。你不能指望每个人都读源码，更不能指望每个人都愿意猜你的设计意图。
所以真正成熟的组件，往往不是“写得最花”的那个，而是“别人最不容易误用”的那个。
我也慢慢接受，不是每个点都要炫技
有些实现确实可以写得很巧，但如果这个巧是以增加理解成本为代价，那就未必值得。
尤其是在组件库这种偏公共基础设施的地方，很多时候稳定、直观、方便维护，比单纯追求技巧感更重要。
我以前也会因为实现上的“漂亮”而兴奋，现在反而更容易问自己几个问题：
- 这个设计别人接手会不会难受
- 这个 API 三个月后我自己还想不想维护
- 这个能力真的是用户需要的，还是我自己想加
- 如果文档不解释，这个行为别人能不能猜到
问得多了，很多自我感动式的设计自然就会收回去。
开源最好的地方，是它会逼你诚实
你在业务里可以靠熟悉场景掩盖很多问题，但在开源里不太行。
组件好不好用，issue 会告诉你；命名直不直观，使用者会告诉你；边界稳不稳，线上场景会告诉你；文档写没写到点上，别人上手时的反馈也会告诉你。
这种过程其实挺磨人的，但也很有价值。
因为它会逼着你从“我想怎么写”，慢慢转向“别人需要我怎么写”。这对一个前端来说，我觉得是很重要的一步。
至少对我而言，做开源组件最大的收获之一，就是把我从很多“自我感觉良好”的写法里拉了出来，让我更愿意站在使用者的视角去做东西。
这比单纯多写几个组件，值钱得多。