Skip to content
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

OldChildren is null with modified component #6385

Open
huang-julien opened this issue Jul 30, 2022 · 0 comments
Open

OldChildren is null with modified component #6385

huang-julien opened this issue Jul 30, 2022 · 0 comments
Labels
has workaround A workaround has been found to avoid the problem

Comments

@huang-julien
Copy link
Contributor

huang-julien commented Jul 30, 2022

Vue version

3.2.37

Link to minimal reproduction

https://stackblitz.com/edit/vitejs-vite-n192fc

Steps to reproduce

Open the inspector, to console or debugger and there is a error shown by vue

What is expected?

components should be shown twice on the rendered HTML

What is actually happening?

components are shown once. Every components passed in createClientOnly throws, while the components passed in workaroundClientOnly works

System Info

No response

Any additional comments?

This happened during a fix on Nuxt 3. The createClientOnly function modify component that will render only after the component has been mounted.

A workaround is available by wrapping the render function with a Fragment here (function: workaroundClientOnly)

From what i can understand at the doc, render functions should return a VNode so returning directly the original render function should be working. But on some components that has been modified with createClientOnly(), vue triggers a oldChildren is null error similar to #2820 when it tries to call its original render function after being mounted.

Even if we can workaround this by wrapping the original render function with a Fragment, is this a normal behavior ?

@haoqunjiang haoqunjiang added the has workaround A workaround has been found to avoid the problem label Mar 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has workaround A workaround has been found to avoid the problem
Projects
None yet
Development

No branches or pull requests

2 participants