uView对比1.X

2024-01-03 06:08:17

uView2.0与uView1.x之间,是有非常大差异的,1.x不能升级到2.x版本。
造成这个问题的根本原因是,2.x是一个重构版本,对1.x进行了整个架构的改造升级,摒弃了1.x中一些不合理的理念和做法,同时引入很多优秀的新特性,让2.0更加 健壮和稳定。
下面列出一些1.x2.x的差异,让您能更好的对2.x有整体的认识,了解该使用哪个版本,以及是否值得升级到2.0版本。

#1. 对nvue的支持

众所周知,1.x是不支持nvue的,所以2.x立项的首要目标就是对nvue的兼容,目前uView2.0也全面实现了兼容nvue
我们也知道,nvue的背后其实是weex,在渲染上有出色的效果,但是其也有很多无法填平的兼容问题,导致某些情况下费尽心思依然无法实现理想的效果。

#2. form表单校验的加强

1.x中,prop参数不支持a.b.c的写法,2.x实现了支持,同时对form组件引入了validateField、resetFields、clearValidate等方法,从各个方面对表单功能 进行了加强,让您在移动端依然能对表单校验游刃有余。

#3. 优化popup弹窗组件

2.x中,我们对弹窗进行了优化,有如下:

  • 修复了1.x中快速切换可能会卡死;
  • 移除了内置的scroll-view组件,让popup内的内容可以超出边界;
  • 优化弹窗的响应速度
  • 处理了由于uni-app的问题,导致微信小程序内,弹窗内无法准确获取元素尺寸而导致某些内嵌组件失效的问题;
  • 提供一个bgColor参数,设置为transparent可以方便去掉背景色,实现个性化的中部弹窗;
#4. 提供通用性的customStyle参数

我们为每个组件都提供了一个customStyle,一般作用于组件内部的根节点,可以方便设置一些基础样式,它同时能接受对象或者字符串的样式形式,如下:

// 对象形式
<u-badge :customStyle="{backgroundColor: 'red'}"></u-badge>

// 字符串形式
<u-badge customStyle="background-color: red;"></u-badge>

copy

#5. 优化在微信小程序上的差异

微信小程序中,默认情况下,自定义组件本身的那个节点是一个“普通”的节点,使用时可以在这个节点上设置class style 、动画、 flex布局等,但是在复杂的 布局下,这可能会导致我们无法控制组件的整体布局,所以在2.x中,我们统一将所有组件设置为“虚拟的”,让其能更好的按我们的预期进行工作。

// #ifdef MP-WEIXIN
// 将自定义节点设置成虚拟的,更加接近Vue组件的表现,能更好的使用flex属性
options: {
	virtualHost: true
}
// #endif

copy

#6. 加强calendar日历组件

2.x中,我们加入了多个控制参数,让您能够对日历进行各个方面进行细致的操作,如通过formatter参数,可以自定义日历提示语,角标等;允许控制日期最大和最小范围; 可以通过滚动的形式,同时展示多个月份;总之,相比1.x,我们从每个方面进行了细致的考虑,并提供了对应的处理方法。

#7. picker组件的调整

1.x中,我们提供了pickerselect组件,这些组件存在一些不足与混乱,同时可能无法配置出我们想要的场景,在2.x中,我们对此进行了梳理,拆分为典型的picker组件, 用于普通的非时间类型选择,同时提供datetime-picker组件,用于专门的时间选择,并针对时间的格式化,最小和最大时间等方面,提供了多样化的控制参数。

#8. 加强numberBox组件

1.x上,由于历史原因,此组件存在更新值时可能会有异常的问题。在2.x中,我们对此组件进行了重构和加强,加入异步控制,以及样式完全自定义的特性,让它能适用于 任何您需要它的场景。

#9. 优化upload组件

1.x中,我们将上传的核心功能集成在组件内,导致在某些特殊返回状态,以及有前端直传oss时,可能会操作不方便的问题。
所以,在2.x中,我们重构了此组件,此后,组件内部只提供图片(新增了视频和文件类型)的选择与展示,将上传的步骤交由外部用户自定义的逻辑进行操作,实现更好的解耦。

#10. 优化radio和checkbox组件

1.x中,我们没法控制这两个组件的排列形式,所以在2.x中,我们提供了一个placement参数,可以对调图片与文本的位置,用于在特殊场景的布局,同时我们在组件内部进行了 特殊处理,让他们能更好的配合form组件进行表单校验。

#11. switch组件细节优化

1.x中,该组件能够满足正常使用,在2.x中,我们对它进行优化,比如加入更好的loading效果、切换动画、以及提供space参数让您配置出另一种风格的样式。

#12. 优化countDown倒计时组件

2.x中,我们对此组件进行如下优化:

  • 加入毫秒级的功能
  • 提供完全自定义的样式配置,让它能适用于任何场景。
#13. 优化swipeAction滑动单元格组件

2.x中,我们针对不同的平台,采用不同的方案去实现此组件的效果,在nvue上,我们采用了BindingX方案,在APP和微信小程序,H5上,我们采用了wxs的方案, 这些优化 ,能让我们滑动单元格时,有丝滑和细腻的效果。

#14. 组件内部获取尺寸时机的优化

1.x中,普遍的做法是在组件初始化完成后获取内部元素的尺寸,这导致在内容变化而导致尺寸变化后,可能导致不准确,或者需要通过调用组件的方法重新进行初始化。
而在2.x中,我们对此进行了反思,采用的方法为每次需要进行操作的时候,重新获取元素的尺寸,典型的为collapse折叠面板组件,在每次打开的时候,组件都会重新 计算该展示的高度。

#15. 父子嵌套组件调用的优化

在uView中,有很多组件都采用父子嵌套的做法,比如radio组件,就由u-radio-groupu-radio组件,1.x中对类似的组件采用了统一的处理方法,该方法存在一定的缺陷, 导致反复操作一些子组件时,重复加入一些实例到管理状态中,从而导致卡顿或者混乱。在2.x中,我们对类似的问题进行了优化,保证了状态的正确性,以及在组件被卸载的时候,进行移除。

#16. 骨架屏组件重构

1.x中,我们需要给骨架屏组件提供类名,以及初始的模拟数据,让组件内部进行尺寸获取以及在对应的位置绘制占位图,在便捷性的同时,舍弃了可控性。
所以,在2.x中,我们采用了另一种实现方式,让用户可以通过参数的形式,配置出想要的占位图信息,可以获得更强的自定义性。

#17. 加强http请求

1.x中,我们提供了基本可用的http支持,它也存在一些缺陷,比如不支持upload、download,其他各项配置不够细化等。
2.x中,我们引入更专业的luch-request插件,它能全面的支持一个企业应用在各种复杂场景下的请求配置需求,我们对此插件进行了进一步的封装,并提供了详细实践用例, 您可以在Http请求?(opens new window)章节中查阅更多关于它的用法。

#18. 提供全局性的组件默认参数配置

我们知道,每个组件都有很多的props参数,在调用组件的时候,通过修改对应的参数,可以覆盖组件的默认值。但是在对于某个常用的组件来说,如果组件的某个参数 默认值不符合自己的需求,就需要在每次调用的时候,都去覆盖它。
2.x中,我们对此提供了一个解决方案,假设u-textcolor#333333,而您应用的默认色值为#555555,就需要每次使用u-text组件时,都去修改它,如下:

<!-- 列表页 -->
<u-text color="#555555" text="列表内容"></u-text>

<!-- 详情页 -->
<u-text color="#555555" text="详情内容"></u-text>

copy

2.x中,我们可以通过uni.$u.props.组件名.参数名的形去对组件的某个默认参数进行全局覆盖,比如我们我要修改u-text组件color参数:

// 建议在main.js中(初始化uView之后)引入外部配置文件中进行统一处理
uni.$u.props.text.color = '#555555'

copy

在进行如上设置后,整个应用中,任意调用u-text的地方,color参数的默认值都成为了#555555

#19. 优化demo演示效果,以及移除了模板和js的模块

为了让组件库更加专注和简洁,我们在演示demo中,移除了1.x中关于模板js的模块,同时优化了组件的演示效果,不再使用1.x切换按钮的形式去动态切换效果, 而是提供更直观的形式对组件的重要效果进行罗列演示。
同时,在官网中,我们也移除了模板模块。

#20. 加强tag组件

2.x中,我们对tag组件进行了加强,相较1.x,它具有如下优势:

  • 可以配置关闭功能
  • 可以配置图标
  • 可以适用于进行多选和单选的场景
#21. 加强swiper轮播图组件

2.x中,我们对swiper组件进行了加强,让它可以配置出更加灵活的指示器样式,同时加入加载中的状态,以及可以嵌入视频播放的特性。

#22. 优化sticky吸顶组件

1.x中,我们采用的是监听元素状态的形式,通过js方案进行吸顶,但是随着时代的进步以及设备的升级,大部分设备以及某些平台已经实现了对css sticky支持, 所以在2.x中,我们采用了两种方案,在各个平台,比如nvue, App, Ios,Android,微信小程序,H5等,通过各种手段,去判断当前平台或者设备是否支持css sticky, 如果支持则优先使用css方案以获得更细腻的效果。如果不支持css方案,则自动降级为js方案。

#23. 优化tabs组件

1.x,可能会存在动态增减菜单下,底部滑块位置可能会错乱的问题,得益于2.x的整体架构调整,我们在每次移动滑块时,都会重新获取菜单的尺寸,再进行移动,保证了滑块 能准确移动到如期的位置。同时,我们对此组件还进行其他细节优化,比如可以禁用某个菜单,显示角标,可以配合u-sticky进行吸顶等。

文章来源:https://blog.csdn.net/m0_72196169/article/details/135339246
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。