组件库在开发前端时扮演着关键角色。我们决定着手构建组件库，在搜集前端的设计图时，遇到了业务线之间的不同，这给我们的工作带来了不小的挑战。尤其是营销活动中的视觉和交互需求，它们对组件库的通用性提出了更高的要求，这一点不容忽视。
设计稿分析及影响
在整理前端设计图的过程中，诸多不同之处显现出来。这些并非仅仅是外观上的差异。在营销领域的应用中，我们追求创新视觉和交互体验，因此组件库必须考虑如何满足这种灵活性。例如，某些营销活动可能需要独特的交互逻辑来吸引眼球。这表明，构建组件库不能一成不变，必须充分考虑实际业务的多样性。这对组件库的灵活性和扩展性提出了挑战，若设计不当，将导致组件库难以适应各种业务场景。
组件库的构建离不开UI规范的支撑。若缺乏统一的UI规范，组件库将变得混乱无序。为此，我们特地成立了一个由客户端和设计师组成的虚拟团队，致力于制定UI规范。这种跨岗位的合作模式打破了传统界限。团队的核心任务是统一跨平台的设计语言，从而有效解决业务线间存在的巨大差异问题，确保组件库在视觉和交互上实现和谐统一。
组件管理方式决策
在组件管理上，我们经过深思熟虑。若选择单一包的管理模式，会遇到不少难题。集团现有能力难以得到有效利用，组件在构建过程中会频繁被打包到页面的各个模块中。而采用多包管理模式，则能充分利用集团资源，并对组件的发布实施规范管理，但相应的成本也会有所增加。使用时，每个组件都需要安装新的包，这对业务开发人员来说，需要记住的信息量也相应增多。综合考虑我们项目多人员参与、长期维护以及组件分层的特点，我们决定采用基于管理工具lerna的多包管理模式。
对原子组件和通用业务组件的管理也需深思熟虑。原子组件采用单一包进行管理，当它们与通用业务组件处于同一级别时，会将通用业务组件以多个包的形式置于packages目录下进行管理。这一做法是基于综合考虑了各种因素，比如成本等方面的考量。
样式相关的探索
闲鱼前端项目的长期使用行内样式存在不少问题。这就像一堵墙，阻碍了我们对于CSS的运用，连keyframes动画都无法实现。经过一番调研，我们决定采用非行内技术的组件脚手架方案。
css模块的style.xxx方法能有效处理名称冲突，但调整起来不够便捷。于是我们另辟蹊径，提出了添加统一前缀的策略，还将pre属性作为组件的props向业务开发者开放，以便他们自行调整样式。
社区中还有babel-plugin-react-css-modules这样的插件被纳入考量。然而，实际操作中需要将其安装在dependence目录下，而我们只提供基础组件，不想增加过多依赖，因此最终决定放弃使用它。
我们随后将拆分的样式变量置于根元素中进行定义，并且将全局CSS的CDN链接添加到了组件脚手架里。虽然这样做会增加开发投入，但它让开发人员能够直接利用这些变量。我们后续还打算通过插件来降低这部分成本。
Storybook的价值
故事书拥有独特优势，独立于主应用程序运行，极大地方便了开发者。开发者无需关注应用程序特有的依赖和需求，即可进行UI组件的开发。故事书使得组件能够独立开发，并在隔离环境中进行交互展示。这就像为组件开发开辟了一片专属的“试验田”，有助于更高效地打造出高质量的组件。
root = true[*] # 匹配所有文件charset = utf-8 # 文件编码是utf-8indent_style = space # 空格缩进indent_size = 2 # 缩进空格为2end_of_line = lf # 使用Unix-style 换行符trim_trailing_whitespace = true # 除去换行行首的任意空白字符insert_final_newline = true # 每个文件以换行结束
组件库的实际效益
const { getESLintConfig } = require('@iceworks/spec');module.exports = getESLintConfig('rax-ts');
投入使用的组件效果显著。在各条业务线上，减少了重复的开发任务。使用这些组件，业务开发人员感到非常便捷，无需担忧UI的还原问题。同时，这些组件还能规范UI设计，提升前端开发的效率与秩序。这充分说明了组件库建设的重要性，它不仅涉及技术整合，还对业务整体发展起到促进作用。
"stylelint-config-recess-order": "^2.5.0","stylelint-order": "^5.0.0"
未来的发展展望
/*** ● feat: 新增功能* ● fix: 修复 bug* ● docs: 文档相关的改动* ● style: 对代码的格式化改动，代码逻辑并未产生任何变化(例如代码缩进，分号的移除和添加)* ● test: 新增或修改测试用例* ● refactor: 重构代码或其他优化举措* ● chore: 项目工程方面的改动，代码逻辑并未产生任何变化* ● revert: 恢复之前的提交** 提交格式：<type>(): 其中scope可忽略 ** 提交实例：git commit -am 'fix(location): 登录接口地址修改'**/
组件库已取得一定成果，但仍有机会提升。我们打算通过插件等方法降低样式变量的使用成本。同时，组件库在应对多样化业务场景，特别是营销活动场景时，还需更灵活、更完善。想知道，各位在项目里构建或使用组件库时，是否遇到过特别的问题？欢迎点赞并分享你们的经验。
