假设有一个订单保存需要经过多个页面进行状态收集,并且在最后一个页面内向后端提交数据
如 /订单名称 -> /收货地址 -> /收货时间 -> 订单确认
|
|
|-> /收货地址选择页
对于这样的流程,大家在SPA中,对于这样的长流程,大家平时都是如何处理的。
如果对这些视图,每个都对应的建立一个路由,在这些路由间进行状态传递与回退时进行状态保留也是很困难。
如果将这些视图不进行拆分,全在一个路由页面下,使用内存对象进行控制流程,单个页面内逻辑又过于复杂。
想问问大家,在angular/react/vue这类框架下,如何处理这些问题。
烦请指教,谢谢大家。
正好项目中也有类似问题,说下我的理解和解决方案,可能不够好,期待其它的思路:
首先楼主的第二个方案是有风险的,全放在一个页面下,但看起来又是多个页面多个步骤,用户在最后一步刷新页面怎么办?回到哪一页?数据还在不在?
在移动端,有时候刷新甚至不是用户触发的,可能页面扔后台,过一会儿再回来就被刷新了,而用户不知道什么是SPA,只知道填了半天的东西要重新来过他们会骂娘。
我的观点是:即使是SPA,WEB的每个页面也都应该具备可访问性,浏览器的意见很重要的,SPA也要按照基本法。
要保证页面的可访问性,每个页面就应该是独立的,而上下文的数据和API一样,都一样属于
外部资源
(External resource
)。因此目前我的解决方式(项目使用flux,以下按flux + react举例)是在前端再造一层类似API的异步数据池(因为可能需要存到LocalStorage保证刷新不丢)。
每步提交的时候发action,action就像post到API一样把数据存到数据池里,下游页面再在componentDidMount的时候发action去请求这个资源,当然这个资源有可能不存在,不过好在是异步的,我们可以走异常处理流程,一切都跟API一样。
这么做的好处是页面与上下文耦合度低,都被封装到action的实现中了。
坏处是增加了一层数据池的概念和相应的代码。团队里经常就有人问我明明感觉上这些都是同步的东西(不考虑页面刷新的话确实是),存取的过程好像额外又兜了一圈。
我感觉这个问题的核心,是前端正在应用化,而应用的页面结构和Web是有本质差别的:应用可以看作单一入口的树状结构,而Web由于url的存在,结构强制扁平,每个url都可能是入口。
应用没有刷新,没有url单独访问(多数情况下),这意味着上下文是可靠的,而Web端不是,每个页面,都必须校验自己所处的上下文。
我的方法其实粗暴且没技术含量,缺啥补啥,缺上下文就自己写,就当抛砖引玉,希望看到其它人更好的思路