Closed wisetc closed 6 years ago
我接触saltui是在钉钉的开发文档,官方推荐开发者使用他们的saltui,当我来到saltui的文档网站,看到那么多的组件可以直接拿来用,心里满心是欢喜,这个好,那个赞,没有想到的是后来的使用中,还是遇到了一些问题。
遇到的第一个问题是,没有顶部的带自动关闭效果的提示组件,我采用轻提示Toast代替,会发现其有字数限制,6个字不能完整显示错误提示。
又遇到了第二个问题,引用saltui的某个组件后,原有自定义的REM系统竟然被saltui覆写了,导致了原来的页面样式错乱。关于这个问题,我是找到了解决方案,并且反馈给官方的git仓库,官方则建议我不要用自定义的REM系统,否则使用某些组件可能样式会有问题。
又遇到了第三个问题,Slot组件在选项滑动的时候,会报错,passive的事件不能preventDefault,不知道是怎么解决。
又遇到了第四个问题,我利用PhotoField组件上传图片至阿里OSS,我发现该组件不支持自定义的上传方法,于是我费了老大劲利用相关库在前端构造了formdata使用PhotoField组件,就因为OSS上传成功返回的数据为空,组件就报错而不能正常显示上传成功的状态。见PhotoField组件不支持自定义的上传方法。
然后用了下表单大类中的field相关组件,发现样式的调整不太容易操作,感觉是因为粒度太大了,自定义的配置项不满足灵活的使用组件的需求。
从我的使用体验上来看,总体感觉saltui还在完善中,没有饿了么开源组件库element-ui这么满足实际要求,我正在考虑要不要转到react-weui。当初之所以用saltui一是因为跟钉钉合作,这次的开发项目钉钉微应用理应满足;二是有阿里钉钉的大厂背景,相信阿里的团队和技术;三是因为saltui组件真的很丰富,大概可以满足极多场景的需求;四是因为其迷人的外表。现在实际使用看来,稳定性确是一个很重要的因素,是不是真的满足使用需求还需要结合实际的UI场景和数据类型。
踩坑还在继续,现在说saltui不行还为时尚早。
这些并不完全满足要求的开源组件也告诉我一个事,那就是不能过于依赖第三方的组件,还是要慢慢积累出一套适合自己业务的组件。
我接触saltui是在钉钉的开发文档,官方推荐开发者使用他们的saltui,当我来到saltui的文档网站,看到那么多的组件可以直接拿来用,心里满心是欢喜,这个好,那个赞,没有想到的是后来的使用中,还是遇到了一些问题。
遇到的第一个问题是,没有顶部的带自动关闭效果的提示组件,我采用轻提示Toast代替,会发现其有字数限制,6个字不能完整显示错误提示。
又遇到了第二个问题,引用saltui的某个组件后,原有自定义的REM系统竟然被saltui覆写了,导致了原来的页面样式错乱。关于这个问题,我是找到了解决方案,并且反馈给官方的git仓库,官方则建议我不要用自定义的REM系统,否则使用某些组件可能样式会有问题。
又遇到了第三个问题,Slot组件在选项滑动的时候,会报错,passive的事件不能preventDefault,不知道是怎么解决。
又遇到了第四个问题,我利用PhotoField组件上传图片至阿里OSS,我发现该组件不支持自定义的上传方法,于是我费了老大劲利用相关库在前端构造了formdata使用PhotoField组件,就因为OSS上传成功返回的数据为空,组件就报错而不能正常显示上传成功的状态。见PhotoField组件不支持自定义的上传方法。
然后用了下表单大类中的field相关组件,发现样式的调整不太容易操作,感觉是因为粒度太大了,自定义的配置项不满足灵活的使用组件的需求。
从我的使用体验上来看,总体感觉saltui还在完善中,没有饿了么开源组件库element-ui这么满足实际要求,我正在考虑要不要转到react-weui。当初之所以用saltui一是因为跟钉钉合作,这次的开发项目钉钉微应用理应满足;二是有阿里钉钉的大厂背景,相信阿里的团队和技术;三是因为saltui组件真的很丰富,大概可以满足极多场景的需求;四是因为其迷人的外表。现在实际使用看来,稳定性确是一个很重要的因素,是不是真的满足使用需求还需要结合实际的UI场景和数据类型。
踩坑还在继续,现在说saltui不行还为时尚早。
这些并不完全满足要求的开源组件也告诉我一个事,那就是不能过于依赖第三方的组件,还是要慢慢积累出一套适合自己业务的组件。