Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

useRouter() returns undefined when uses in setup() method in Options API component #2226

Closed
stefanseifert opened this issue Apr 29, 2024 · 2 comments

Comments

@stefanseifert
Copy link

Reproduction

https://github.com/brdgm/joan-of-arc-orleans-solo-helper

Steps to reproduce the bug

  1. Clone git repo https://github.com/brdgm/joan-of-arc-orleans-solo-helper
  2. Update "vue-router" from 4.2.5 to 4.3.2 in package.json, and execute "npm install"
  3. Start app with npm run dev and open it in browser at http://localhost:8080
  4. Hit "Play Game" button and then "Start Game" on 2nd screen

Expected behavior

The screen of first round should be displayed without errors

Actual behavior

In the browser console, several warnings and an error is displayed:

runtime-core.esm-bundler.js:47 [Vue warn]: injection "Symbol(route location)" not found. 
  at <RoundTurn onVnodeUnmounted=fn<onVnodeUnmounted> ref=Ref< undefined > > 
  at <RouterView key="/round/1/tile/1" > 
  at <App>
warn$1 @ runtime-core.esm-bundler.js:47
runtime-core.esm-bundler.js:47 [Vue warn]: Unhandled error during execution of setup function 
  at <RoundTurn onVnodeUnmounted=fn<onVnodeUnmounted> ref=Ref< undefined > > 
  at <RouterView key="/round/1/tile/1" > 
  at <App>
warn$1 @ runtime-core.esm-bundler.js:47
runtime-core.esm-bundler.js:47 [Vue warn]: Unhandled error during execution of scheduler flush. This is likely a Vue internals bug. Please open an issue at https://github.com/vuejs/core . 
  at <RoundTurn onVnodeUnmounted=fn<onVnodeUnmounted> ref=Ref< undefined > > 
  at <RouterView key="/round/1/tile/1" > 
  at <App>
warn$1 @ runtime-core.esm-bundler.js:47
NavigationState.ts:23 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'params')
    at new NavigationState (NavigationState.ts:23:33)
    at setup (RoundTurn.vue:75:29)
    at callWithErrorHandling (runtime-core.esm-bundler.js:195:19)
    at setupStatefulComponent (runtime-core.esm-bundler.js:7630:25)
    at setupComponent (runtime-core.esm-bundler.js:7591:36)
    at mountComponent (runtime-core.esm-bundler.js:5917:7)
    at processComponent (runtime-core.esm-bundler.js:5883:9)
    at patch (runtime-core.esm-bundler.js:5351:11)
    at ReactiveEffect.componentUpdateFn [as fn] (runtime-core.esm-bundler.js:6027:11)
    at ReactiveEffect.run (reactivity.esm-bundler.js:177:19)

Additional information

the problem is, that useRoute returns nothing in this case, relevant code snippet for the example above:
https://github.com/brdgm/joan-of-arc-orleans-solo-helper/blob/9c9ae389e7de2b5057e3870e49a437cbd35e7a9c/src/views/RoundTurn.vue#L70-L78

i suspect the problem is that the route is already created in some way to fill the global $route variable (which cannot be accessed in setup function), and then the call to useRoute in setup fails. but: it worked without problems for the last ~2 years with vue-router versions < 4.3.0.

it seems this mixture of Options API component and setup methods is a rare use case, but it's "officially supported" following this documentation: https://vuejs.org/api/composition-api-setup.html#composition-api-setup - bullet #2. this is our use case and worked well for a lot of components.

@skirtles-code
Copy link
Contributor

skirtles-code commented Apr 30, 2024

If you run npm list vue-router, I believe you'll see that you have two versions of vue-router installed.

Your project uses 4.3.2, but brdgm-commons is still pulling in 4.2.5. They both need to use the same Vue Router, otherwise the symbols used by provide/inject won't match.

@stefanseifert
Copy link
Author

yes, indeed - that solves the problem!

i was under the assumption that the version in packages.json overwrites the version inherited from brdgm-commons (i'm coming from java backend development where this is the case for transitive maven dependencies).

sorry for the noise.

@vuejs vuejs locked and limited conversation to collaborators May 5, 2024
@posva posva converted this issue into discussion #2228 May 5, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants