作者语：本文以element ui为例
何为消息提示类交互
按照交互原则之 “凡事皆有反馈”的原则，对界面的操作，会在操作前做询问，操作后做成功/失败的提示
本文会涉及到element ui的Message、MessageBox、Dialog、PopConfirm等组件
1 写库操作前需询问 - confirm
作者语：一键操作，意思为不需要繁杂的步骤，从界面展示到执行完毕，只需要点击一个按钮就可以调用操作
此处与toC端的一键三连等操作意思不同
在系统中做删除、禁用/启用、发布等一键操作的时候，需要提醒用户，避免误操作
并且写出相关的提示信息，如果操作之后 ，会有如何后果之类的
2 MessageBox or PopConfirm ？
两者均可以做 confirm操作，不同的是：
PopConfirm直接出现在操作按钮的旁边（一般为上下方），便于就近点击确定/取消按钮MessageBox直接出现在界面的中央上方，距离当前操作按钮距离比较远
对此选择，Ant Design的建议是使用 PopConfirm，原因是不阻断用户心智
不过，我推荐的是 MessageBox，而且全系统统一，原因如下：
MessageBox是直接使用this.$confirm调用的，而PopConfirm需要在模板代码中，将操作按钮包裹起来这样如果是列表的话，PopConfirm会渲染很多次，个人之前遇到过，数据量大的时候，会影响界面性能相比较开发体验而已，MessageBox这种调用，也更容易接受相同的系统中，如果有这两种不同的提示，就会显得比较错乱，因为统一为一种最佳
3 操作成功之后的提示
操作成功通常会伴随着界面刷新、界面关闭等相关动作，而且操作成功的提示，也不会那么多需要用户获取的信息，所以通常是那种自消失的小弹窗（Message）提示
4 操作失败的提示
操作失败的提示逻辑稍微多一些，因为要提示给用户具体的失败信息
一般来说，失败信息由后端接口返回，便于拓展与管理
4.1 简单的操作失败提示
如果返回的提示信息不会太长，也可以使用 Message来展示
该类型消息提示，可以通过统一的接口拦截code判断展示
4.2 复杂的操作失败提示
如果是比较复杂的操作提示，比如需要明确告诉用户，失败的具体原因，可以供用户复制信息等，这样的话，自消失的message就不够用了。可以使用this. a l e r t 来 做 简 单 的 操 作 提 示 ， 这 个 提 示 信 息 也 是 由 后 端 返 回 ， 按 行 展 示 。 这 种 alert 来做简单的操作提示，这个提示信息也是由后端返回，按行展示。 这种 alert来做简单的操作提示，这个提示信息也是由后端返回，按行展示。这种alert，默认的样式可能不够用，需要前端统一封装一下 class 样式
4.3 更复杂的操作失败提示
那种业务逻辑很复杂的操作失败提示，仅靠$alert弹窗已经不够了，需要普通的dialog来展示，里面内嵌表格之类的信息等
5 提示前置原则
有这么一个经典场景：你有一个table，单行内有删除按钮，但删除的时候后端有校验，有的数据会返回提示“不能删除”。
常规交互：
1、点击删除按钮 2、询问是否删除 3、后端返回不能删除，原因xxx
优化一下后的交互
1、点击删除按钮 2、先调用是否可以删除接口，能的话询问是否删除；不能的话，直接给出提示
优化后的交互，会提前阻断交互，避免了一些无效的操作询问。
同时也会带来一些新问题 ，就是这个事先询问的接口，返回时效要很高，要不然容易出现点击了按钮，前端没有任何交互反应的情况
6 重要操作的提示
6.1 在线考试的提交
这个时候，一次操作询问就有点不够了，需要操作人至少操作两次提交
6.2 在线文档、编辑器的离开
浏览器会做阻断提示，提醒当前界离开前的保存操作
7 不需要额外提示的场景
7.1 表单提交
一般的表单提交，都会有一些表单项，甚至有必填项的约束，这种交互就不属于“一键操作”的类型
除非那种影响流程比较大的表单提交（如公告发布、重要内容提交），一般不需要额外提示
7.2 纯前端的简单操作
比如有个table，前端点击一下“添加”按钮，会在table追加一条数据，数据内容也比较简单，没有调接口进行保存
这个时候，如果前端要删除该条数据的话，就无需调用询问操作
8 总结
如上，个人总结了几点规范/原则
写库前必询问写库后必反馈提示前置
如果觉得《前端UI交互 - 中后台系统 - 消息提示类交互》对你有帮助，请点赞、收藏，并留下你的观点哦！
