删除确认、删除异步及删除延时，delete confirm，aysnc and delay

本文是对删除操作的一个优化的思考及实践的纪录。这里的删除也适合于更新等其他update操作。这里确认、异步和延时也适合其他非删除，但需要征询用户的情况。

首先要解决的问题是删除同步（sync），要变成删除异步（async）。当前在 -gMIS 中进行删除时，需要更新前端页面，办法时重新请求一下整个页面，这很不友好，也不节能，为了去掉一行，需要重新获取其他所有无关的数据再一次。这个可以使用异步的方法进行，就是在删除当前行时，不动其他的，在前端打个删去标记，通过 -GTAjax 给后台一个删除某行的命令即可。如果采用类似JSON的通信格式，则可以将通信成本控制到最低。

这里解决了两个问题，在服务器端减少了重新生成页面到各种计算，在通信层减少了传输信息量。在前端的影响几乎没有，已经通过JavaScript和DOM对待删除的纪录打了删除标记。在此之前 -gMIS 实现的inline edit （行内编辑），就是出于这样的考虑, 现在终于可以爱删除这个动作上也应用上了。 扩大些，这个思维适合所有前端需要局部更新，单传统做法需要更新所有页面组件的情况。

这里的异步，更多的是从前端的视角，当前端还能够看到某条被删除的纪录时，后台已经没有了。

然后要对删除确认做点革命性的创新。其实，早就对删除确认（Confirm）不满了，所谓删除确认，是在操作系统、信息管理系统中，总是会在删除之前，要求用户进行确认才继续进行。偶尔遇见用一下还能够忍受。在使用   -gMIS 管理的 -people-fwnews 时，每天会遇到很多需要删除移除和修正的内容。觉得对于已经明确需要删除的内容再进行确认是某种浪费，不可忍。需要找到另外一种更人性，或者更舒服一些的做法。

传统的删除确认：Mac OS X的删除确认

Windows 10的删除确认

传统的删除确认在管理信息系统中的样子：
-gMIS 改造前的删除确认

通过前端或者后台生成一个确认对话框，用以对用户对提示，征询用户对资源纪录的移除动作的确认。这是常规的、靠谱地通常做法，偶尔用一下也不觉得有问题，用久了多了就会发现很费神。

但从另外一个角度说，如果不进行确认，删除之后无法进行找回，也是灾难。如何中庸地处理，有没有一种方法来进行中和？如果有新方法，应该能满足预期的三点：1）删除命令执行时，不需要用户二次交互，2）以某种方式警示用户进行删除，3）在第一步失误的情况下，可以回滚或终止。

在这种情况下，候选的方案是，变删除确（confirm）认为删除延时（delay），其步骤如下：
1. 删除命令（意愿）发出，
2. 给出提示，延迟一定时间后将实际执行删除操作，
3. 在延时期间，给出取消／终止删除操作的选项，
4. 当用户在延时倒计时期间，选择了取消／终止操作，则删除命令撤回，没有进一步地执行，
5. 当用户在延时倒计时期间，没有任何操作，则删除命令按预期进行。

这样，在删除一个对象时，用户只要交互一次即可完成最终删除，同时在发行删除有误时可以在延时期间随时取消删除行为。

对比如下两图，可以知道，传统的是阻塞模式，新的是非阻塞模式。

传统的阻塞模式的删除

新的非阻塞模式的删除

改进后的删除延时使用实例：

从此不用非得再点击一次，才能继续往下。

此想法已经汇报演示给技术大家 @ownhere，评价是更人性一些的改进，演示给人民网的同学 @wangchen，评价是xxxx。

还需要一组数据来印证这种改进，在操作系统中，有多少次删除是进行了回滚？在管理信息系统，有多少次删除的确认中，用户选择了否？如果这两项的数据都表明，回滚和选择否的比例都很低很低，是否就不应该进行之前的设计，而应该应用新的删除延迟？

上文中，以 “-” 的拼写，都是 -NatureDNS ， -自然域名 。