-
-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
fix(server-renderer): getSSRProps can get exposed property #7502
Conversation
packages/runtime-core/src/index.ts
Outdated
@@ -79,7 +79,7 @@ export { | |||
|
|||
// For getting a hold of the internal instance in setup() - useful for advanced | |||
// plugins | |||
export { getCurrentInstance } from './component' | |||
export { getCurrentInstance, getExposeProxy } from './component' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that we should expose this from runtime-core, as this way it will be re-exposed from the main vue package. But really it's an internal API.
I think we should move to the shared
package like other stuff that's internally shared between different renderers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What you said makes sense, but moving getExposeProxy
to shaerd
seems to be more costly, because the publicPropertiesMap
it uses involves a lot of internal APIs.
Import getExposeProxy
directly through the path, how do you think this is possible?
import { getExposeProxy } from '../../runtime-core/src/component'
Because I see that there are similar writing in customFormatter.ts
and packages/vue-compat/src/index.ts
What is the current status here? |
Hey, how is this standing? I've heard nuxt-speedkit would need it and then kodadot/nft-gallery is happy to use it 😁 |
@baiwusanyu-c @LinusBorg when will you merge the fix into the main branch? |
# Conflicts: # packages/server-renderer/src/render.ts
# Conflicts: # packages/server-renderer/src/render.ts
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
@baiwusanyu-c Thanks to the PR 🙂 Now this PR is almost half a year old, not really feel like waiting until this reaches its first year of life 😉 Seems to be only minimal changes and slowly the excitement rises. Could you also alternatively use a workaround here for now without this PR? |
# Conflicts: # packages/server-renderer/__tests__/ssrDirectives.spec.ts
Size ReportBundles
Usages
|
@@ -188,7 +188,7 @@ function renderComponentSubTree( | |||
const prev = setCurrentRenderingInstance(instance) | |||
try { | |||
ssrRender( | |||
instance.proxy, | |||
getExposeProxy(instance) || instance.proxy, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't really the right fix as for the component's own render function, it should be using the default (internal facing) proxy.
See the correct fix in df686ab (reusing tests from this PR)
close: #7499