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

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

需求：一个展示表格，能添加，能删除

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

设计一（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，很期待和大家交流。