Skip to content

Bug: Reactivity breaks when Teleport is stubbed in unit tests, causing unexpected unmounts on teleported components #2628

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

Open
Alevagre7 opened this issue Mar 11, 2025 · 5 comments · May be fixed by #2632
Labels
bug Something isn't working

Comments

@Alevagre7
Copy link

Describe the bug
Stubbing out Teleport in unit tests causes reactivity to behave unexpectedly. Specifically, the teleport component unmounts when its props are updated, but only when the Teleport is stubbed. This behavior differs from what is observed in the browser console, where the Child component stays mounted and reactivity works correctly.

To Reproduce
A minimal reproduction is available here: https://codesandbox.io/p/devbox/adoring-water-3pxr5p

Repro Steps

  1. Fork the project using the link above
  2. Open a new terminal
  3. Run pnpm test

Expected behavior
Both unit tests should pass, with reactivity working regardless of whether Teleport is stubbed or pointing to a real target.

Observed behaviour
Only the non-stubbed teleport test is passing.

Related information:
System:
OS: Linux 6.1 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
CPU: (2) x64 AMD EPYC
Memory: 1.57 GB / 4.14 GB
Container: Yes
Shell: Unknown
npmPackages:
@vue/test-utils: 2.4.6 => 2.4.6
vitest: 3.0.8 => 3.0.8
vue: ^3.5.13 => 3.5.13

Additional context
Credits to @victor141516 for helping triaging this issue.

@Alevagre7 Alevagre7 added the bug Something isn't working label Mar 11, 2025
@Alevagre7 Alevagre7 changed the title Bug: Bug: Reactivity breaks when Teleport is stubbed in unit tests, causing unexpected unmounts on teleported components Mar 11, 2025
@cexbrayat
Copy link
Member

Hi @Alevagre7

If I run the tests, everything seems to work:

➜  workspace git:(main) pnpm test

> [email protected] test
> vitest


 DEV  v3.0.8 /project/workspace

stdout | src/teleport.spec.ts > Teleport > using appended target > should be reactive
Child Mounted
App Mounted

stdout | src/teleport.spec.ts > Teleport > using stub > should be reactive
Child Mounted
App Mounted
Child Unmounted
Child Mounted

 ✓ src/teleport.spec.ts (2 tests) 40ms
   ✓ Teleport > using appended target > should be reactive
   ✓ Teleport > using stub > should be reactive

 Test Files  1 passed (1)
      Tests  2 passed (2)
   Start at  14:01:21
   Duration  1.51s (transform 73ms, setup 0ms, collect 266ms, tests 40ms, environment 889ms, prepare 119ms)

 PASS  Waiting for file changes...
       press h to show help, press q to quit

did you forget something?

@Alevagre7
Copy link
Author

That’s correct, @cexbrayat. Apologies for the confusion.

I discovered that adding await nextTick() allows the second test to pass, but it doesn’t actually resolve my issue.

As you can see from the logs, during the second test execution, the Child component unmounts and mounts again. This behavior is inconsistent with how it works in the browser.

Do you have any insights into what might be triggering this behavior?

@cexbrayat
Copy link
Member

I don't know what triggers this behavior sorry, but as it is a stub, it's not really surprising that it does not behave like the real Teleport component. The built-in stubs are fairly basic (see

). You can try to debug what's going on in there to understand why you see this mount/unmount.

@victor141516
Copy link

Hi @cexbrayat thanks for your response!

I modified slightly the codesandbox that @Alevagre7 shared in the OP so it's more obvious the functionality is very different and it may make a lot components untestable without a major refactor.

I understand that the stub is not intended to have the same functionality, so if you consider this as a known issue I understand it.

However I think it's a pity that such a simple scenario is imposible to test with the stub. I'm debugging the library, and I'll try to provide a PR if I manage to fix it.

@cexbrayat
Copy link
Member

Hi @victor141516 thank you for updating the repro

I agree that this should work out of the box. If you find anything, I'll gladly review and merge the PR 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants