推一波自己的 React 组件库

[xiejay97]

感觉写的挺好的，就是缺 API 文档和测试，希望有人一起共建。

https://github.com/laser-ui/laser-ui

https://laser-ui.github.io/

[ltaoo1o]

能完整实现一套组件库很厉害了，有什么比较亮眼的功能点吗

[xiejay97]

@ltaoo1o 样式，其实用组件库最麻烦的就是样式问题，我设计了一套 JS 样式封装，可以整个替换或者针对元素单独节点设置，包括修改或者覆盖 class 和 style ，其它不能说亮眼，只能说都有：
动态主题，使用 css 变量。
ARIA 支持。
国际化支持。
SSR 支持。
移动设备支持。

因为完全没什么第三方依赖，体积打包特别小 100KB

[SayHelloHi]

学习了 感谢分享～

[xiejay97]

实在写文档有心无力

[ltaoo1o]

@xiejay97 #2 我用组件库也是经常会遇到要覆盖样式，但是非常困难的问题。可以在某个页面强调一下这个功能点，给一个具体的业务场景，肯定能吸引到有需求的人来用。

[putyy]

瞟了一眼 不错 先赞！

[passion336699]

https://github.com/laser-ui/laser-ui/blob/main/libs/components/src/tabs/Tabs.tsx

OP 可以介绍下 refreshTabs 确保选项卡正确处理溢出，并且将因溢出而不可见的选项卡放到下拉列表的思路吗？

最近有需求要实现一个，取取经

[xiejay97]

@passion336699 考虑简单场景，一堆选项卡（ tab ）放在可滚动容器（ container ）中，首先检查 container 的 scrollWidth 和 clientWidth 判断是否选项卡有溢出滚动，如果有，方案 1：遍历 tab ，通过`getBoundingClientRect`获取 left ，对比 left 是否超过 container 的 left ；方案 2：遍历 tab ，通过累加 offsetWidth ，对比宽度是否超过 container 的 clientWidth

[xiejay97]

@xiejay97 方案 2 不好，因为 css 导致的位置变化是很难计算的（如 margin 、transform ）

[blur1119]

最近正好想做组件库相关的事情。还有组件功能可以编写的吗，想参与进来

[xiejay97]

@blur1119 有的，我 Dropdown 那块就一直想加虚拟滚动支持，懒没写，而且有其它原子类组件，合适的话也可以开发，留 issue 我拉你

[eluotao]

已 Start,就佩服你们这种写 ui 的

[shunia]

文档的话，可以多写点注释，先自动生成一波，有问题再慢慢调整。

一般我看到这种 readme 就归结为低质量自 high 产物直接略过了，高质量的 readme 真的是必不可少的，既然代码都开源了，别省这个功夫。

[xiejay97]

@shunia 我就是因为想完善文档才发贴不是，所以个人开发者想做这类项目真的挺无奈的，因为很难有社区陪你一起成长，有多少喜欢并且能够折腾技术的人，生活很难的啦。不过我很庆幸这些东西全在公司落地项目，我个人也保持着一个技术人的热爱。

[dufu1991]

@shunia https://github.com/any-tdf/stdf 这个的 README 能不能过关，提提意见。

[guhuisec]

不错

[SHF]

不错，支持 react 19 吗？

[xiejay97]

@SHF 支持而且超前，可以看看这个迁移计划 https://github.com/laser-ui/laser-ui/issues/1

[seeu2ex]

加一个，有开发计划吗

[xiejay97]

@seeu2ex 没有啊，我自己业务上是已经没有需求了，有什么想法可以留 issue ，欢迎共建

[GeekGao]

OP 卖课更能发挥出价值。让更多人学会这套技能。
单纯的组件库太多了，维护周期很难持续。

[xiejay97]

@GeekGao 现在这个市场，卖课的要有良心应该劝人不要学前端了，除非学历和简历够硬

[shunia]

@dufu1991 #15 额，我确实有点看法，不过你这个从 readme 到文档工具都是标准模板水准的，顶多就是挑刺了。

1. 测试页面的链接，也就是 demo ，放在更明确显眼的位置，而且不要扫码。直接网页打开我完全可以控制台工具看 responsive 模式，你让我扫码我是不可能扫的，尤其是老外，他们注重隐私，扫码是一个心理风险很高的操作。
2. 我不太理解为什么移动优先，就需要色彩对比度/色度这么高吗？我个人感觉看着好累啊。目前主流平台，没有任何一个用这么重色度色彩盘的吧？
3. 我刚看首页第一眼寻思啥玩意我在 svelte 里用 tailwind css 还用你写个库？后来在网站里点到了组件列表才意识到不对劲。所以你的首页应该是三个按钮：组件库放在第一个，DEMO 放在第二个，开始使用放在第三个。
4. 基于第三条，首页的简介方块里应该着重调整成描述这是一个优秀的组件库。最好能有一个使用组件库的简要代码以及渲染出来的组件的样式，放在这几个简介之前。好像很多组件库都有这种首页形式，直观的很。简单来说 landing 页很值得优化。

[Morning009]

感觉不错，学习了。已 star⭐

[forty]

赞！希望 OP 持续完善。

点了几个我关注的控件，感觉细节上还差比较多啊。
比如：
缺少校验功能，输入内容不符合要求时，标红并在下方文字提示或悬浮提示；缺少自动补全；缺少密码强度显示等这些常用功能。
select 选择框多选时，框中并未即时展示已经勾选的项，而要等关闭下拉之后才会显示，不知算不算 bug 。
时间输入框无法响应键盘操作，日期不支持选月选年模式，不支持拖拽范围等等。

[xiejay97]

@forty 感谢意见，校验由 form 组件提供的。自动补全之前有，后来去除了，可以通过 select 组件实现。日期选月选年这个考虑过，实现简单，但是最终还是建议用选择类（如 select 组件）的组件。时间输入框无法响应键盘操作和日期不支持拖拽范围这个没太理解。其它基本上还是关于组件设计。其实作为这个组件库，设计遵循实现尽可能少的功能&强大的可扩展性，显示设计主要希望无障碍和反馈优先。比如密码强度显示，用户可以简单封装的情况下应不应该由组件库实现。

[forty]

@xiejay97 也就是说，单独用 input 就没有校验功能，只能套 form 组件去实现校验？
密码强度显示，不具备通用性，其它控件不会用到这个特性，所以是应该集成进来的，就像那个“显示密码”的小眼睛一样。
时间输入框，你不是 3 个数字下拉框吗，键盘无法使焦点跳入下拉框。
日期不支持拖拽范围，比如要选 12 月 15 号到 12 月 25 号的范围，鼠标在 15 这里按下，移动到 25 那里释放，从而选中这段范围。
日期选月选年，这个挺有用的，不是 select 组件能替代的。你现在这个，比如当前 12 月，要去到 6 月，就得在“上月”那里连续点 6 次，年也类似，比如现在 2024 ，要去到 1980 年，你得点到手都酸了。选月选年，就像 windows 右下角那个类似，很多日期组件都实现了的。

[xiejay97]

@forty 这个焦点管理是遵循 https://www.w3.org/WAI/ARIA/apg/patterns/，组件遵循 ARIA 的我也标记了。
目前时间输入框还没有这个设计可参考，遵循 No ARIA is better than Bad ARIA 的原则，这块没有加焦点管理，如果有符合人直觉和良好的 aria 设计加上是完全没问题的。
日期拖拽不就是组件打开范围选择吗。
选年月这个我觉得真的好用嘛，需求可以设计看看怎么加，但是我觉得就目前 windows 这种选择方式绝对不会是我想要的。额外提一下，你举例的场景是可以直接输入日期的。
密码强度这个完全可以加，不加用户去实现也完全可以，这就是很好的机会，我很希望有人能参与进来。

[xiejay97]

@xiejay97 https://www.w3.org/WAI/ARIA/apg/patterns/

[forty]

时间输入框不能键盘的问题，就算没有标准，有也比没有好，否则逻辑不自洽，有些下拉框能够键盘操作有些又不能，就容易造成用户困惑。

日期虽然能手工输入，但毕竟点击更方便不是更好吗？
windows 这种选择方式是主流，带年月点选的 ui 框架基本都大差不差这个样子，点月份切换到月份直选，点年份切换到年份直选，远比狂点“《”和“》”易用。
比如： https://ant.design/components/date-picker

[xiejay97]

@forty https://ant.design/components/date-picker 和 Windows 交互逻辑一样的，就当前时间我想改个 2000 年你可以自己用用，这个功能可以做（以及加 issue 了），但是他们目前的这种交互我不觉得值得参考。补充一下：月份和年目前我的组件是支持长按按钮的。时间输入框键盘我也很乐意去做，都是要设计先。

[forty]

@xiejay97 赞👍
你这个已经做的很好了，只是日期选择组件需要的细节确实是比较多。
比如说选生日，可能得选到 40 年之前甚至更久远，长按也要按好一会，而且数字滚动几十下是停不准的，得停下来之后再微调。其次，长按是需要教学的，其它类似按钮没有一致的长按行为的话，用户很难想到这个地方有长按交互。
如果是移动设备交互，往往可能还会支持左右横扫来切换，如果当前是"选日”，滑一下就切换到上个月下个月，如果当前是选月，滑一下就切换到上年下年，如果是选年，滑一下会切换上个 20 年下个 20 年之类。
对中国用户来说，有时候附带阴历日期也是个需求。

[forty]

还有一个细节，比如你的日期控件里面现在是“2024-12-31”，此时我手动键盘输入“2024-1-3”，焦点离开时，符合正常预期的结果应该是修正为“2024-01-03” ，但实际却是组件可能认为非法而重置为旧值“2024-12-31”了。另外，键盘聚焦到日期输入框时，貌似也无法调出日期选择控件，只有点击才会出来。

[xiejay97]

@forty 这个 2024-1-3 是可以优化输入，现在是强制校验格式匹配 format ，应该可以根据 format 泛匹配。这个键盘日期和时间是一样的，目前都没做，需要设计

[pannanxu]

支持一下，不过现在的组件库好像除了 antd pro component ，其他的 Form 组件都是需要写很多重复的东西。虽然可以自己封装但是还是比较麻烦。

比如

```js

<Form>
<FormGroupContext value={form}>
<Form.Item formControls={{ username: 'Please input your username!' }} label="Username">
{({ username }) => <Input formControl={username} style={{ width: '100%' }} placeholder="Username" />}
</Form.Item>
<Form.Item formControls={{ password: 'Please input your password!' }} label="Password">
{({ password }) => <Input formControl={password} style={{ width: '100%' }} type="password" placeholder="Password" />}
</Form.Item>
<Form.Item>
<Button type="submit" disabled={!form.valid}>
Submit
</Button>
</Form.Item>
</FormGroupContext>
</Form>
```

可以简化成这样

```js
<Form ref={form}>
<TextInput name='username' label='Username' required rule={[]} />
</Form>

```

[xiejay97]

@pannanxu 组件库是尽可能的弹性，面向多种场景，业务组件可以面向特定场景抽象高级组件