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

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

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

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

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

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

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

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

化多路由为单路由

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

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

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

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

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

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

猜你喜欢

转载自blog.csdn.net/u012443286/article/details/113648879
今日推荐