有关pro存在形式的问题

[xxholly32]

最近我在考虑如何基于element-plus 做二次开发，然后找到了这个宝藏库，里面有一些功能相对element-plus来说确实更加强大。

我在vue2时代也是通过您这样的方式去做一些解耦，但由于侵入性比较强以及当时element-ui对monorepo做的不是很好，所以我当时拿整个element-ui项目进行魔改，并也在内网开发了类似pro的项目。

但pro的封装虽然让用户能够更加便捷的开发，但还是会存在一些问题：

1. 开发更加无脑

pro的封装是将工作量分给了核心组件开发团队，而在业务放他们仅仅是无脑调用，但到了某一天，可能会出现为什么你功能没有的问题，你没有，那我做不了的情况。如果一旦有bug，他也不会去排查，而是将责任甩在开发这个pro组件库人的头上。

2. 心智负担

除了看element-plus的文档以外，还需要看您的文档，当然对于1~2个开发成员来说可能还行，但数量一旦大，就可能会出现文档在哪，或者找不到的情况。在开发中也会想 我用 el-select 还是 pro-select。当然心智负担不仅仅包括这些，npm的版本更新，changelog，常见问题，更新建议等其实都算。

我这边也做了一个pro，https://xxholly32.github.io/element-plus-pro/ ，将element-plus的官方文档和我定制的组件放在了一起

为了解决这类的问题，我的解决方案还是说，如果element-plus 真的做不了，那尽可能将一些简单的组件用代码片段的方式开放出来。可以看下这个issues：vuejs/repl#78 ，开发根据自己的需要引入到自己的components里面成为项目的一部分，而不是npm包的一部分。

我个人还是希望将开发的能力最大化，以及可以最大程度的扩展组件库（不是以npm包的形式），就像tailwindcss，当你在用它的时候，你就在学习它了。就算是npm的形式，那也是封装一些特定的库。我们公司对于时间控件的交互和element-plus 差了一些

以上是我个人对 pro 的一些看法

还有一些discussion element-plus 官方团队一直没有回复，我厚脸皮的放在这：

• [Enhancement] How can I set all the defaults at once element-plus/element-plus#11970
• 以及尽快发布一些 @element-plus/* 的库 Next Step of Element Plus element-plus/element-plus#8288 (comment)
• How can I get the Chinese document file element-plus/element-plus#11811

如果有需要我可以提供 contribute

[tolking]

如果是公司使用完全可以像腾讯、字节这种自己设计、开发组件库。选择基于 element-plus 开发就需要忍受其带来的缺点。

高度封装必定会一定程度地牺牲易用性，对于封装和维护也是挑战。个人觉得应该避免封装一些大型的组件，提供合适的插槽用于附加内容。对于提bug的看开就行

代码片段 谁来编写、维护？怎么更新代码？简单的代码直接问 ChatGPT 就行了，时代变了...

我觉得你需要的可能是 headless UI。曾经也有过相关计划，但这需要合理的从组件库中抽离单个逻辑的 composable 代码，这是一个漫长的过程。

任何开源项目都欢迎你的贡献。

element-plus 官方团队成员都是用爱发电，希望不要要求我们做任何事情。组件库、文档、周边生态代码都是开源，你可以自己去寻找答案。