-
Notifications
You must be signed in to change notification settings - Fork 258
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
Feature request: Trigger onServerPrefetch from test #1321
Comments
Probably dup of #1218? |
@ferencbeutel4711 Thanks for the request. I agree with Lachlan, I think we need to add SSR support and then that should give you a way to test the onServerPrefetch function. Would you like to give it a try? as @lmiller1990 pointed out, the implementation should be fairly close towhat VTU v1 was doing here https://github.com/vuejs/vue-test-utils/blob/dev/packages/server-test-utils/src/renderToString.js and you can also take inspiration in what vue core does https://github.com/vuejs/core/blob/9c304bfe7942a20264235865b4bb5f6e53fdee0d/packages/runtime-test/src/index.ts We would gladly accept a PR! |
Could something like this work? import { createSSRApp, h } from 'vue'
import { renderToString as baseRenderToString } from '@vue/server-renderer'
function renderToString(component, options) {
// Copy contents of mount function to get props, refs, slots
const props = {}
const refs = {}
const slots = {}
const Parent = createSSRApp({
name: 'VTU_ROOT',
render() {
return h(component, { ...props, ...refs }, slots)
}
})
return baseRenderToString(Parent)
} |
I was expecting something like that @wobsoriano - would you like to make a PR and add a few tests? Likely this is something we will build incrementally and add features as needed, but this seems like a great starting point. |
@lmiller1990 I'll try. Looking at the Or maybe something like this would suffice? import { mount } from '@vue/test-utils'
import { renderToString as baseRenderToString } from '@vue/server-renderer'
export function renderToString(...args: Parameters<typeof mount>) {
const wrapper = mount(...args)
return baseRenderToString(wrapper.getCurrentComponent().vnode)
}
|
Yep, we likely want all the usual mounting options to work in the same way, so you might need to move some things around. Specifically, I guess we won't want the final It'll be a bit of effort, I'm sure some other things will pop up, I'm here to lend a hand. This is a high impact feature, thanks for taking the time to look into it! |
Thanks @lmiller1990! So without moving much stuff around, the easiest way to implement would be adding another property to the mount options I guess? Something like const MOUNT_OPTIONS: Array<keyof MountingOptions<any>> = [
// other options,
'renderToString'
]
export function mount(componentOptions, options) {
// ...
if (options?.renderToString) {
return renderToString(app)
}
// mount the app!
const vm = app.mount(el)
// ...
}
export const renderToString: typeof mount = (component: any, options?: any) => {
return mount(component, { ...options, renderToString: true })
} |
Oh interesting, had not thought about doing it that way. It's better than what I had in mind. I like this - it follows the pattern we have for shallow: export const shallowMount: typeof mount = (component: any, options?: any) => {
return mount(component, { ...options, shallow: true })
} I'm guessing one of the things we want to test is if the |
I'll play around and do some tests! |
Initial PR #1572 |
This should now be fixed with the latest VTU versions, as |
Is your feature request related to a problem? Please describe.
Currently, it seems that there is no way to test the behaviour of the function defined in onServerPrefetch
Describe the solution you'd like
It would be great if there was a way to trigger the serverPrefetch lifecycle hook from the tests
Additional context
Hey, maybe I am mistaken, but I cant see a way to test the behaviour I have defined in the onServerPrefetch lifecycle hook defined in a setup function in my component. With the options API, this was possible, using the following approach:
However, I can see no replacement that can be used for the composition api.
The text was updated successfully, but these errors were encountered: