从一个需求来讲前端代码设计

这是一个很常见的需求,为什么我要把它单独拎出来讲,那是因为从这个小小的需求上,能看见一个人独有的思考,我们该如何从业务,时间,工作量上来平衡这个点,选择合适的方式来释放业务的能动性。

需求:一个展示表格,能添加,能删除

从上图来看,整个需求的功能点其实在于数据的展示,数据的操作。但是由于工作中,随着时间(可能这个需求会比较赶),也可能随着体验(希望在用户体验上有更好的体验),在实现这一个小小需求上,可能会选择不同的方案来处理这个问题

设计一(reload|无二次确认)

设计二(将获取列表的请求函数传递|二次确认)

删除的逻辑也于此相同,这样的方式比之前的刷新式,要好了许多,唯一不足的是,请求也是需要开销的,也许之后的刷新还是会有一些慢。

伪代码:

functiongetList(){

ajax(function(){

//更新dom

})}

functionadd(info){

ajax(function(){

getList()

})}

//HTML添加

设计三(添加一个小型基础的数据管理器)

之前的一个设计中有说到用重复请求的方式存在着网络开销的,对于一个Web应用而言这依然是一个不好的体验,假设用户网络情况很慢,其实这里与第一种设计无意中类似了,请求依然会挂起,等待服务端的响应。在没有使用React或Vue这些框架的情况下,我们依然可以来添加一个小型基础的数据管理器,来完成这个操作。

通过表格的分析,其实我们可以看见,最终我们操作的可能会是如下的数据:

[

{ id:'',

...args }

]

一条数据对应着表格中的一行cell。我们可以定义两个方法pushItem和removeItem,来操作这些。

在添加(Modal)按下确定提交服务端成功之后,调用一下pushItem方法,将一条新的数据push到原始数据的数组中,然后再调用一下renderHTML,重新渲染一次DOM。

在删除(Modal)按下删除提交服务端成功之后,调用一下removeItem方法,这个方法传递一个参数,就是这一条数据在原始数据中的下标值,使用.splice删除之后,再调用一下renderHTML,重新渲染一次DOM。

这样的方式,其实比第二个设计,又提升了不少的体验,思考一下,在这里我们不去重刷请求,只是添加删除数据,来完成对表格的操作,是不是会好很多?

设计四(使用redux等数据流管理库)

目前的前端开发几乎已经无法告别React,Vue等现代JS Web框架,于是我们需要添加一个类似redux的数据流管理库,有了数据流管理库,再配合上React的优化,可以比设计三,又有了一次体验优化的空间,Why? 因为要重新渲染一次DOM,我们都知道Web应用最大的开销就是DOM重绘。在这里,可以利用数据的pre next的对比来提供一个是否要渲染的机制,这一点上会很帮助。

它的设计也会比较简单,定义两个action分别是pushItem和removeItem,分别在reducer里面去做remove和push的动作,在props透出时,可以来进行一次对比,颗粒化的更新机制的好处,就是你能控制组件节点的每次一次渲染的动作。

你也可以关注我的新浪微博,搜索i_icepy,很期待和大家交流

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180324G01C5K00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券