背景
icon
的管理是设计稿转代码过程中,重要但容易被忽视的环节。
所以在实际的业务代码中 icon
问题的解决方案往往也是八仙过海,能用就行。比如导出为 png
, svg
格式的文件,在项目中作为静态资源直接引用,或者上传到 CDN 作为外链引用。显然这些方案多少都存在着一些小问题:
在用户体验上,包括在高分辨率屏幕上显示模糊、增加额外的
http
请求、异步加载造成页面抖动等;在开发体验上,包括无法通过
CSS
控制样式以便和文本保持一致、难以复用和更新等。
为了解决上述问题,规范一点的做法是把设计稿 icon
转换成 iconfont
字符集,在项目中导入字体文件使用。对于初创团队而言,淘宝免费的 `iconfont`[1] 网站无疑是快速的解决方案:上传 icon
——生成项目——一键下载,非常方便。然而有几个问题阻碍了它成为企业级的解决方案:
一个是项目间无关联,相同
icon
无法复用和统一更新;一个是无法强绑定企业账户,在团队协作和人员更迭交接时不可控;
最后一个是
icon
的版权问题,所有人都可以免费使用所有人上传到平台的icon
,这可能不是公司所希望的。
所以上述的解决方式在项目初期可能确实可以快速解决问题,但随着业务复杂度的指数级别增长,开发周期的拉长,以及项目维护人员的更迭, 这都可能成为后期无法维护的技术债,降低开发效率,影响用户体验。在转转的技术体系中,iconfont
平台作为物料中心建设的组成部分,是不可或缺的一环。
预期目标
icon
作为设计规范和物料资源,也有着团队协作和版本更迭的强需求,正如成熟的研发团队往往会部署自己私有的 GitLab
服务管理代码资源一样,搭建自有的 iconfont
平台也应该在合适的时候被提上日程,以解决上述痛点。
我们希望 iconfont
平台可以实现:
明确角色的职责:UI 贡献
icon
;FE 使用icon
权限管理体系
可持续的迭代、同步、和维护