在 ensureURL 中使用 recoverMeta 会出现的问题

[Dante-dan]

在源码 ensureURL 中会会执行以下操作：

feb-alive/src/index.js

Line 52 in cd4a9a5

Vue.location.recoverMeta(from, to)

目的是使用缓存的 meta 信息。

然而 ensureURL 的执行周期和 beforeEach 并不是完全对等的，在 popState 的时候，会执行 TransitionTo . 从而执行 ensureURL 。

---

由此引发的问题，当我想要对特定组件支持手势返回。一般思路如下：

1. 将当前路径推入路由，pushState
2. 监听 popState，并绑定关闭组件的事件
3. 等待手势返回。

此时返回， router.beforeEach 并没有执行，因为没有发生路由切换。但是 popState -> transitionTo -> ensureURL ， 而 ensureURL 中的 febRecord 来源其实是 beforeEach，这就导致了两个路由栈的不统一。

所以可以考虑将 ensureURL 所执行的内容改到 afterEach 吗？

[Dante-dan]

所以缓存上一次的 meta 的意义何在呢？

是因为你们业务中有类似 消费 meta 的场景存在么？

[hangaoke1]

@Dante-dan 感谢反馈
Q1：使用ensureURL而不使用afterEach，是因为开发此插件时候，发现vue-router在调用afterEach钩子时，浏览器的url还没有改变，这会导致无法拿到history.state中存储的key，详见vuejs/vue-router#2292

Q2: 缓存上次meta的意义是因为插件是基于页面缓存的，所以理论上a -> b 回退到a的时，所有状态都应该被恢复，包括页面数据、页面meta数据。业务场景也是有此需求的，因为原生的meta只有一份，在同步路由的情况下，例如/a/1 -> /a/2，如果在/a/1页面进行meta修改，/a/2页面也进行meta修改，此时在回退到/a/1页面时，应该显示/a/1的meta信息，而非/a/2

[Dante-dan]

那现在版本的 vue-router 是可以用 afterEach，而且 afterEach 和 beforeEach 生命周期上更匹配。

另外从 meta 的含义看是 元数据, 对于浏览器而言 <meta> 标签也是在 dom 构建之前就准备好的。

语义的角度讲，meta 是不是不应该被改变。

[hangaoke1]

@Dante-dan 嗯，这部分我会升一个大版本修改成afterEach，至于meta，这个算是相对来说偏向业务性的东西，目前插件设计就是跟页面历史栈保持同步的，每个页面历史栈对应一份meta。如果你那边比较个性化的话，可以考虑fork一个出去，进行针对性的改造。

[Dante-dan]

为啥 afterEach 的改动，需要升级大版本呀？会带来什么 breaking changes 吗？还是只是在发版计划中的大版本顺带带上这个改动。

我已经 fork 了一个，然后我想改成 afterEach ，如果有别的风险的话，我就直接去掉 recoverMeta了。

[hangaoke1]

@Dante-dan 因为已经有一些业务在使用了，vue-router版本不能保证，所以需要做版本升级，不然会导致已经使用的业务因为包自动升级导致出现问题