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

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

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

设计一（reload|无二次确认）

这个方案是可以在最短时间内解决问题的，能保障功能的瞬间可用，只需要在操作中添加一个“删除”按钮，点击按钮发起一次请求，当请求回来后调用一下window.location.reload方法，刷新一下页面即可，这个方案可以在最短的时间能完成功能，保障业务可以按期进行。

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

从体验的角度上来说，没有二次确认，用户可能会误删，在一个非常重要的系统上来说，这个设计是一个badcase，于是从之前的代码中，增加一个Modal来进行二次确认，解决用户可能会误删的情况。而window.location.reload的刷新式体验，就比较糟糕了，操作任何一个事项，都要把页面刷新一次，对于要求比较高的用户而言，这会让人家很崩溃，如果时间上稍微允许，可以选择一个折中的方案，将获取列表的请求封装成一个函数，把这个函数传递给添加（Modal）和删除（Modal），当你使用添加（Modal）按下确认之后，会将待添加的信息提交给服务端，服务端响应之后，调用一下这个函数，这个函数又会去获取一次新的列表，来局部刷新页面。

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

伪代码：

function getList(){   
    ajax(function(){      
        // 更新dom
    })
}
function add(info){   
    ajax(function(){      
        getList()
    })
}
// HTML<button onclick="add">添加</button>

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

之前的一个设计中有说到用重复请求的方式存在着网络开销的，对于一个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透出时，可以来进行一次对比，颗粒化的更新机制的好处，就是你能控制组件节点的每次一次渲染的动作。