第一章
通过列表分页展示数据是最基础常用的功能
架构设计
通常而言,在短期内初、中、高级程序员实现的功能是没什么差别的。对用户来说也是没有任何感知的。 架构的设计意义在于长期,很多项目最后陷于泥沼的原因往往是因为初期没有架构概念,追求快速实现功能而忽视了后期的可维护性和可扩展性。 追求速度并不是不可取,一个成熟的架构只要按照规范开发,同样可以兼顾速度、可扩展性、可维护性。
封装ajax请求
封装ajax请求通常是最容易也是见效最快的方式。 以axios为例,通常我们会封装一个基础的request类,然后在api中定义具体的请求方法,假如我们有一个请求列表数据的方法list,那么通常情况下是这样使用的。
随着开发经验的提升,你会发现请求数据的代码中通常会有大量的重复的判断是否请求成功的代码,那么这一部分代码是否可以简化,只需要处理请求成功逻辑呢,如下。
答案当然是可以的,在axios这一章节我会做详细讲解。
全局数据
通常情况下,一个管理系统或者一些移动端应用在业务中会有一些字典数据或者业务数据在很多模块或者页面都是需要用到的。
通常情况下,大部分开发都是在具体的页面,多次请求相同的数据,这对后端会产生一定的压力,并且在前端造成一定的性能浪费。
那么在这一方面我们可以考虑通过vuex来做一个全局数据来处理,这样可以减少不必要的请求,减轻后端压力同时也能提升前端性能。
例如说一般的系统通常会有权限模块,权限模块中会有对应的组织管理功能,这个组织是一个树形结构,那么我们可以要求后端只返回一个完整的组织树形数据。如
然后通过一系列代码逻辑来把它处理成我们需要的的数据格式,比如说树形数据转扁平数据,转级联数据等。如
最后通过固定的更新逻辑来实现增删改后能够时实更新数据,依次类推,类似的数据我们都可以通过固定的逻辑来处理。具体的实现方式在后面的课程我会讲到。如
交互设计
对应前端开发来说,交互设计同样重要,好的交互设计能提高操作效率,客户满意度。
增删改交互
列表数据增删改查是最常见的交互逻辑,这里有很多细节需要注意 1. 新增 通常来说在新增数据后,都是直接刷新列表来保证新增数据能够显示出来。 最好的解决方案是新增数据后直接让后端把新增的数据直接返回,然后前端直接手动插入到列表第一行。这样不紧能减少一次请求数,也能得到最好的用户体验。 其次的解决方案是新增后保留当前列表的参数,把页面设置为第一页,并且要求后端将列表数据按时间倒叙来进行排序,保证新增数据能够被显示。这种方案有一定的缺陷。
编辑 编辑的交互逻辑比较简单 最好的方案还是更新成功后直接更新对应的数据,不过这里要设计好交互逻辑,避免出现更新失败后列表数据仍然更新的情况。 其次就是直接保留列表参数重新请求刷新数据,这种方式比较简单。
删除 从列表中删除一条数据,我们可以直接从列表数据中移除掉这条数据。 需要注意的是,假如这一条数据是在最后一页,并且只有一条,这个时候我们需要保持查询条件不变,但是页码减一重新请求数据。
增删查改这些逻辑看似简单,却是最常用的功能,也是对用户体验影响最大的,所以一定要在交互设计上做好处理。如果不能提供完美的的解决方案,那么退而求其次也一定要保证交互体验的一致性。不能保证交互体验一致性会大大的破坏用户体验的。
缓存逻辑
不论是管理系统的页面模块切换,还是移动应用的页面切换,做好缓存都能够使用户满意度提升。 1. 管理系统 缓存列表页,是很好的选择。用户在切换到其他模块页面后,如果做了缓存会是很好的体验。 更深一步,如果针对详情页面做了缓存。比如用多个tab页签方式打开多个用户详情页时,如果能够缓存多个用户页面,不仅仅是提高用户体验,也能减少不必要的请求数。 1. 移动应用 移动应用的的缓存逻辑更为复杂,比如用户从主页进入到列表页面,然后再从列表页面进入到详情页面,我们就需要在从主页进入到列表页面时缓存主页,再从列表进入到详情页时缓存列表页面。 然后用户从详情页面退回到列表页面时,列表页面因为被缓存了可以直接展示。注意了,这个时候我们再从列表页面回到主页时需要清除掉列表页的缓存,保证用户再次进入列表页面看到的是最新的数据。 所以移动端的缓存逻辑更为复杂,我们需要根据具体的业务需求来确定不同的缓存策略。
最后更新于
这有帮助吗?