Deprecation Warning about the next() parameter shown despite valid use-case in v5.0.3

[amxmln]

Reproduction

https://play.vuejs.org/#eNqFVFtv2jAU/itn2SRAg5iyy0OWonZVtW7apeqmvSx7MImBtIlt2Q6lQvz3Hdu50dsEuZ3r952Ld0FJcx5e6yAK8lIKZWAHqWLUsFMpYQ9LJUoYbCo2SHhroERlmGq1IfGCzsT6NjoqZej9E95GHuI1SjhAWGk29O7+uxQVN8PBS3QbjIJxULsjvtiwUhboP7eG8fpofsGKQthkL2KCn04s3QNftFGCr+ZnlVKMG48ZJDXrKCa1DnY7eOUU4bIqiktUwn7vwhAfJ+Z00wS8cii/5vwGjDhOApIE808C3+FClCwmnf5JD7pASet2ar8e+MWkyRnb3hzG+p2zWyC1Xa2OSVsYrJevZWge6eg3Vgp1d5Frg49xLfRx+52etN1s+2kJutRNUxtB3dmm7ZbQgV0raUeAbZ1pKrium6Lg+ADLcGfprT3M6DHsw9HYmjhvHcEfX6Kd7y4MyADJCYTEsfFRB37vvPqGrh+H1h0Hb/4X73scTSxtn7SdR52qXBrsQM0pY0taFVhv67dgS6E8o3NuWRkxdmUZA9qbkbdCEsxUijvZcLgpR3CMY+lVAJsyXAqB9RksqBp88GKLBu8OXUYNHd6P1bqjbwQcJ7sm7kYbb/jHHWjQ48e9zZrNG6q4V7Nmr3BZLJj93i/H4dgdNLorDmiEJKGgfIXzbzTO/n9zt6Hq5IeJ/KhNSirx1BIcUzm6Sa3ADFFTgCToptmKk2BtjNQRIRWXN6sQu046i5N34TR8QzIcsZ40ZLqcLJS41fh+jdHrUibBCRqRjG2MEIWeUJk/leKB4cn78H14RIp8QTA6yXnGti520x6kaTRuyDJf3SNpBzUvmPohTY4bdECW4mF4+8XJjKpYCzRds/TmEfm13nrIl4ohuw3rkTNUrRieVFZ9/vM7DmdPWYqsKtD6GeUV06KoLEZv9rHiGcLu2Tm0n13Pcr76pc+3hnHdkLJAuyl3jTx7hnoH9034tldFbe4KpsNU29MQj9Ux2DOzXlChMqYimMktINg8g5fT6dTtWInhcj5ZCGNEGcHRVG6dXNIsQ7CtBLMkHMPCHCi8xssFrr0LtsTjpG+5nvUzd+E7AGma9gBEMMXfrI4Q7P8BT1WRTA==

Steps to reproduce the bug

Run the example, observe the deprecation warning in the console.

Expected behavior

There should not be a warning, since the function is used as documented.

Actual behavior

There is a warning.

Additional information

The official docs mention that the only way of passing data to the component instance in a beforeRouteEnter hook is via the next callback. Is there a new (undocumented) way? Or is the deprecation warning a mistake?

[posva]

This warning is initially expected 😬
Ideally it should also be removed in the future but the replacements are a little bit different so I would like some help identifying use cases. So far, I far I have:

• data fetching: set component data before entering -> replace with data loaders

Data loaders do require composition api, so I wonder if that can be a problem

[johuhype]

Sorry, I have similar problem with 5.0.3. I removed all usages of next in the guards. But still there are multiple deprecation warnings in the console for each navigation.
I am not really familiar with getting warnings shown in the console when there is nothing to warn about.
I was thinking this is a bug in 5.0.3. Or that the warning has a wrong text.

[TArch64]

I have same warning and for now I don't have any idea what I can do to not use next argument. I use beforeResolve + next to do view transition for my routes

router.beforeResolve(async (_, __, next) => {
  const transition = document.startViewTransition(async () => {
    next();
    await nextTick(); // make sure dom updated
    await nextTick(); // one more to hide loading icons
  });

  await transition.ready; // without await ready there are warning about missing next function's call
});

Related discussion: #2515 (reply in thread)

[posva]

@TArch64

router.beforeResolve(() => {
  return new Promise((resolve) => {
    document.startViewTransition(async () => {
      resolve();
      await nextTick();
      await nextTick();
    });
  });
});

or

router.beforeResolve(() => {
  await document.startViewTransition(async () => {
    await nextTick();
    await nextTick();
  }).ready;
});

[ricardo17coelho]

Sorry, I have similar problem with 5.0.3. I removed all usages of next in the guards. But still there are multiple deprecation warnings in the console for each navigation.
I am not really familiar with getting warnings shown in the console when there is nothing to warn about.
I was thinking this is a bug in 5.0.3. Or that the warning has a wrong text.

I'm facing the same issue. I also removed every next() in my app.
I also saw this issue in another too which do not have any next() at all 🧐

[TArch64]

@posva second one doesnt work, however first one works. Thank you!

[posva]

@ricardo17coelho if you have the warning you have a next() somewhere, check the stacktrace of the warning

[johuhype]

@posva Thanks for the hint. I had to show the ignore-listed frames of the stacktrace.
Now I saw that the issue is actually caused by Vuetify.

[ricardo17coelho]

@posva Thanks for the hint. I had to show the ignore-listed frames of the stacktrace.
Now I saw that the issue is actually caused by Vuetify.

This is also what i suspect ( i use vuetify in all my projects )

vuetifyjs/vuetify#22643 👀

[ix-benjaminm]

Yeah it's coming from Vuetify. I also removed all my next occurences.

[hivokas]

@posva we have this in our project:

beforeRouteEnter(to, from, next) {
  axios
    .get(`/ajax/keywords/${to.params.keyword}`)
    .then(({ data: { data } }) => {
      next((vm) => vm.setKeyword(data));
    });
},

How are we supposed to get rid of next in this case?

This seems to work, but it's not documented and I'm worried it can unexpectedly break in future updates.

beforeRouteEnter(to, from, next) {
  return axios
    .get(`/ajax/keywords/${to.params.keyword}`)
    .then(({ data: { data } }) => {
      return (vm) => vm.setKeyword(data);
    });
},

Is it safe to do the above, or there is a chance this behavior will stop working?

[posva]

@hivokas It might be removed in the future, yes. Use data loaders instead: https://router.vuejs.org/data-loaders/defining-loaders.html

[hivokas]

@hivokas It might be removed in the future, yes. Use data loaders instead: https://router.vuejs.org/data-loaders/defining-loaders.html

@posva Thank you for your quick reply.

This page (https://router.vuejs.org/data-loaders/basic/) says data loaders are experimental so I'm a bit hesitant using them in production. Do you expect to mark data loaders as stable in the near future?

[posva]

yes