uView2.0与uView1.x之间,是有非常大差异的,1.x
不能升级到2.x
版本。
造成这个问题的根本原因是,2.x
是一个重构版本,对1.x
进行了整个架构的改造升级,摒弃了1.x
中一些不合理的理念和做法,同时引入很多优秀的新特性,让2.0
更加 健壮和稳定。
下面列出一些1.x
与2.x
的差异,让您能更好的对2.x
有整体的认识,了解该使用哪个版本,以及是否值得升级到2.0
版本。
众所周知,1.x
是不支持nvue
的,所以2.x
立项的首要目标就是对nvue
的兼容,目前uView2.0也全面实现了兼容nvue
。
我们也知道,nvue
的背后其实是weex
,在渲染上有出色的效果,但是其也有很多无法填平的兼容问题,导致某些情况下费尽心思依然无法实现理想的效果。
在1.x
中,prop
参数不支持a.b.c
的写法,2.x
实现了支持,同时对form
组件引入了validateField、resetFields、clearValidate
等方法,从各个方面对表单功能 进行了加强,让您在移动端依然能对表单校验游刃有余。
在2.x
中,我们对弹窗进行了优化,有如下:
1.x
中快速切换可能会卡死;scroll-view
组件,让popup
内的内容可以超出边界;bgColor
参数,设置为transparent
可以方便去掉背景色,实现个性化的中部弹窗;我们为每个组件都提供了一个customStyle
,一般作用于组件内部的根节点,可以方便设置一些基础样式,它同时能接受对象或者字符串的样式形式,如下:
// 对象形式
// 字符串形式
copy
微信小程序中,默认情况下,自定义组件本身的那个节点是一个“普通”的节点,使用时可以在这个节点上设置class style 、动画、 flex
布局等,但是在复杂的 布局下,这可能会导致我们无法控制组件的整体布局,所以在2.x
中,我们统一将所有组件设置为“虚拟的”,让其能更好的按我们的预期进行工作。
// #ifdef MP-WEIXIN
// 将自定义节点设置成虚拟的,更加接近Vue组件的表现,能更好的使用flex属性
options: {
virtualHost: true
}
// #endif
copy
在2.x
中,我们加入了多个控制参数,让您能够对日历进行各个方面进行细致的操作,如通过formatter
参数,可以自定义日历提示语,角标等;允许控制日期最大和最小范围; 可以通过滚动的形式,同时展示多个月份;总之,相比1.x
,我们从每个方面进行了细致的考虑,并提供了对应的处理方法。
在1.x
中,我们提供了picker
和select
组件,这些组件存在一些不足与混乱,同时可能无法配置出我们想要的场景,在2.x
中,我们对此进行了梳理,拆分为典型的picker
组件, 用于普通的非时间类型选择,同时提供datetime-picker
组件,用于专门的时间选择,并针对时间的格式化,最小和最大时间等方面,提供了多样化的控制参数。
在1.x
上,由于历史原因,此组件存在更新值时可能会有异常的问题。在2.x
中,我们对此组件进行了重构和加强,加入异步控制,以及样式完全自定义的特性,让它能适用于 任何您需要它的场景。
在1.x
中,我们将上传的核心功能集成在组件内,导致在某些特殊返回状态,以及有前端直传oss
时,可能会操作不方便的问题。
所以,在2.x
中,我们重构了此组件,此后,组件内部只提供图片(新增了视频和文件类型)的选择与展示,将上传的步骤交由外部用户自定义的逻辑进行操作,实现更好的解耦。
在1.x
中,我们没法控制这两个组件的排列形式,所以在2.x
中,我们提供了一个placement
参数,可以对调图片与文本的位置,用于在特殊场景的布局,同时我们在组件内部进行了 特殊处理,让他们能更好的配合form
组件进行表单校验。
在1.x
中,该组件能够满足正常使用,在2.x
中,我们对它进行优化,比如加入更好的loading
效果、切换动画、以及提供space
参数让您配置出另一种风格的样式。
在2.x
中,我们对此组件进行如下优化:
在2.x
中,我们针对不同的平台,采用不同的方案去实现此组件的效果,在nvue
上,我们采用了BindingX
方案,在APP和微信小程序,H5上,我们采用了wxs
的方案, 这些优化 ,能让我们滑动单元格时,有丝滑和细腻的效果。
在1.x
中,普遍的做法是在组件初始化完成后获取内部元素的尺寸,这导致在内容变化而导致尺寸变化后,可能导致不准确,或者需要通过调用组件的方法重新进行初始化。
而在2.x
中,我们对此进行了反思,采用的方法为每次需要进行操作的时候,重新获取元素的尺寸,典型的为collapse
折叠面板组件,在每次打开的时候,组件都会重新 计算该展示的高度。
在uView中,有很多组件都采用父子嵌套的做法,比如radio
组件,就由u-radio-group
和u-radio
组件,1.x
中对类似的组件采用了统一的处理方法,该方法存在一定的缺陷, 导致反复操作一些子组件时,重复加入一些实例到管理状态中,从而导致卡顿或者混乱。在2.x
中,我们对类似的问题进行了优化,保证了状态的正确性,以及在组件被卸载的时候,进行移除。
在1.x
中,我们需要给骨架屏组件提供类名,以及初始的模拟数据,让组件内部进行尺寸获取以及在对应的位置绘制占位图,在便捷性的同时,舍弃了可控性。
所以,在2.x
中,我们采用了另一种实现方式,让用户可以通过参数的形式,配置出想要的占位图信息,可以获得更强的自定义性。
在1.x
中,我们提供了基本可用的http
支持,它也存在一些缺陷,比如不支持upload、download
,其他各项配置不够细化等。
在2.x
中,我们引入更专业的luch-request
插件,它能全面的支持一个企业应用在各种复杂场景下的请求配置需求,我们对此插件进行了进一步的封装,并提供了详细实践用例, 您可以在Http请求 (opens new window)章节中查阅更多关于它的用法。
我们知道,每个组件都有很多的props
参数,在调用组件的时候,通过修改对应的参数,可以覆盖组件的默认值。但是在对于某个常用的组件来说,如果组件的某个参数 默认值不符合自己的需求,就需要在每次调用的时候,都去覆盖它。
在2.x
中,我们对此提供了一个解决方案,假设u-text
的color
为#333333
,而您应用的默认色值为#555555
,就需要每次使用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
。
为了让组件库更加专注和简洁,我们在演示demo中,移除了1.x
中关于模板
和js
的模块,同时优化了组件的演示效果,不再使用1.x
切换按钮的形式去动态切换效果, 而是提供更直观的形式对组件的重要效果进行罗列演示。
同时,在官网中,我们也移除了模板
模块。
在2.x
中,我们对tag
组件进行了加强,相较1.x
,它具有如下优势:
在2.x
中,我们对swiper
组件进行了加强,让它可以配置出更加灵活的指示器样式,同时加入加载中的状态,以及可以嵌入视频播放的特性。
在1.x
中,我们采用的是监听元素状态的形式,通过js
方案进行吸顶,但是随着时代的进步以及设备的升级,大部分设备以及某些平台已经实现了对css sticky
支持, 所以在2.x
中,我们采用了两种方案,在各个平台,比如nvue, App, Ios,Android,微信小程序,H5
等,通过各种手段,去判断当前平台或者设备是否支持css sticky
, 如果支持则优先使用css
方案以获得更细腻的效果。如果不支持css
方案,则自动降级为js
方案。
在1.x
,可能会存在动态增减菜单下,底部滑块位置可能会错乱的问题,得益于2.x
的整体架构调整,我们在每次移动滑块时,都会重新获取菜单的尺寸,再进行移动,保证了滑块 能准确移动到如期的位置。同时,我们对此组件还进行其他细节优化,比如可以禁用某个菜单,显示角标,可以配合u-sticky
进行吸顶等。