项目开发中对前端数据管理的理解

现在的SPA开发中,提到数据(状态)管理不得不提Redux和Vuex,它们都是基于Flux思想的前端状态管理解决方案。但本文的重点不是介绍Redux或Vuex的技术细节,而是基于真实的业务场景谈谈在不同的场景下该如何管理数据

图片描述

上图是一个简化后的页面,整个页面是一个父组件,它包含3个子组件,子组件1是一个按钮,子组件2是一个数据展示Bar,组件3是一个tab,子组件3中每个tab的内容又是一个子组件(相对于页面是孙组件)。关系如下图所示。

图片描述

数据:
子组件1是一个触发打开表单填写Dialog的按钮,没有数据
子组件2包含绑定客户数
子组件3是一个tab组件,负责tab展示和切换,没有数据
孙组件包含要展示的具体列表数据

事件和数据之间的关系:
点击子组件1手动绑定客户按钮进行增加一个新客户的操作后,子组件2的客户数会+1,孙组件绑定客户Table中的数据会增加一条;
点击子组件1手动绑定客户按钮进行增加一个失效客户的操作后,子组件2的客户数会+1,孙组件绑定客户Table中的数据会增加一条,孙组件失效客户Table中的数据会减少一条;
点击孙组件中解绑按钮后,孙组件绑定客户Table中的数据会减少一条,失效客户Table中的数据会增加一条,子组件2中的客户数会-1;

简单看下组件之间的数据关系:
子组件2的数据受到子组件1和孙组件中的事件影响;
孙组件的数据受到子组件1和自身的事件影响;

这个页面的数据管理具有一定的复杂性,不同层级的组件的数据存在互相影响。这里我们该如何管理数据呢?

方案一
把这个页面的所有数据交给Redux/Vuex管理
优点:所有组件从Redux/Vuex中拿数据,所有组件的事件触发Redux/Vuex中的数据更新,不用关心组件的事件会触发其他哪些组件的数据更新

方案二
父组件管理所有数据(单向数据流思想),通过属性将数据层层往下传,子组件或孙组件通过事件触发父组件中的数据更新
优点:简单,无需引入Redux/Vuex库
缺点:组件层级比较深时,数据传递会比较繁琐(这里react和vue都有各自简单处理方法)

方案三
从产品的维度考虑,我们可以在某些地方新增一个刷新按钮,部分层级比较深或者没必要立马刷新的数据(比如绑定客户列表中进行解绑操作,失效客户列表这时并不可见,也可以不立马刷新数据,等用户切换tab时再去请求数据或者让用户手动刷新一下列表)
优点:不用考虑数据之间的影响
缺点:用户体验不够好

这里我们从一个真实的业务场景看到数据之间存在相互影响关系,使用Redux/Vuex不是为了用而用,在某些场景确实能解决我们的问题,这时应该去使用它。有些简单的父子数据共享,为了减少复杂度,也可以不使用Redux/Vuex。

方案三在某些场景下,也能更简单解决我们的问题,某些表格中确实也有使用刷新按钮的场景。最近在使用企业微信中发现,收藏页面在每次打开会请求数据,如果这时再新增一个收藏,收藏列表不会刷新,而需要关闭收藏再打开,这时就能看到最新增加的那条收藏。这种体验不好吗?可能不够优雅,但用户第一次使用时,应该也是知道关闭再打开这个逻辑的,更重要的是我们打开收藏一般是去查找以前的一些东西,而很少立马查看刚才的那个收藏。考虑业务场景,考虑用户的使用习惯,能更好的帮助我们开发出简单易用稳定的产品。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值