谈谈前端页面式流程实现的坑及开发建议

在某些业务流程中，需要一步步的引导用户进行每一步操作。这时，假设只是静态页面，那么非常简单。
但在某些情况下，用户的每一步操作都设计到许多交互，这时情况就变得相当复杂。开发者面临的一个问题是：

如何简化页面式流程的逻辑？

之所以说简化，是因为这时，需要考虑的问题非常多，且很难考虑周全，维护性也将是巨大的挑战，这些问题包括：

• 跨页面传递数据的实现方案是什么？
• 刷新页面时是否保留数据？
• 浏览器前进/后退行为，开发者无法控制，如何防止前进/后退产生的bug？
• 从url进入是否允许访问？
• 何时清除掉多余数据？

弹窗简化

假设遇到如上困境，在产品允许的情况下，我们可以改用弹窗，逻辑将会大大减少，这是因为：

• 无需跨页面传递数据
• 无需考虑浏览器前进、后退、刷新、由url进入的问题

并且采用弹窗时的可复用性更强。

化多路由为单路由

我们可能会直接按照产品原型，设计成多个路由，以实现多页面。但更为推荐的是使用单页面，根据条件渲染对应组件，原因是：

• 多页面跨页面传递数据麻烦。
• 浏览器前进、后退、刷新、由url进入等情况处理更为简单。

尽量绕开浏览器行为的控制

我们可能已经采用多路由页面式设计，这可能是我们前期没考虑充分，时间上不允许变更方案。这时，我们的逻辑就会非常复杂。一个原则是，我们尽量绕开浏览器行为的控制，这是因为：

• 存在兼容性问题。不同平台对某一特性的支持存在很大差异，且很难完全考虑周到。
• 方案存在缺陷，易出bug。当我们强行去实现，就会发现无论采用哪种方案，或多或少都存在缺陷，难以完善。
• 更为费时。当我们的注意力被用来与浏览器较真、与兼容性较真，那么费时费精力几乎是必然的。

事实上，我们可以更关注数据，巧妙绕开这些问题，譬如：

• 通过判断是否有数据，来决定是否允许访问。这就不再需要去控制浏览器刷新、url进入、前进/后退、路由push等行为，转而只需考虑这些情况下的数据。