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不行还为时尚早。
这些并不完全满足要求的开源组件也告诉我一个事，那就是不能过于依赖第三方的组件，还是要慢慢积累出一套适合自己业务的组件。