๐ The bug
When generated files are produced, async functions or serverPrefetches don't correctly populate the Nuxt context.
Note: I believe this is an issue with Nuxt rather than with nuxt-composition-api.
๐ ๏ธ To reproduce
Steps to reproduce the behavior:
interval: 2000 from test/fixture/nuxt.config.jsyarn nuxt generate -c test/fixture/nuxt.config.js./dist/ssr-ref/index.html to see not all ssrRefs injected in pageโน๏ธ Workaround
You can add time between pages being generated to allow for any async functions to resolve, if you are pre-generating any of your pages.
nuxt.config.js:
js
{
generate: {
// choose to suit your project
interval: 2000,
}
}
Hi, I was curious about this bug so I tried to reproduce it. My experience:
interval: 2000 but I commented out the interval line under generate:../dist/ssr-ref/index.html, but there do appear to be values for all the fields in the output.'async-prefetched async' is not found on the /no-setup page.yarn nuxt generate -c test/fixture/nuxt.config.js and manually inspect the generated no-setup/index.html, 'async-prefetched async' is present.I'm not sure I can get anywhere on fixing this, but is that failing test the thing that needs to be fixed?
@eostrom I appreciate your looking into this! The issue seems to be not that the data isn't in the generated HTML, but that it isn't in nuxtState. Possibly using a vue-renderer hook might allow us to solve this, e.g. https://github.com/nuxt/nuxt.js/issues/8852#issuecomment-789946319 and https://github.com/nuxt/nuxt.js/issues/8620#issuecomment-779133184.
Will you plan to fix this to correctly retrofit this functionality in a nuxt 2 project or should we avoid this functionality altogether? I'm planning to introduce @nuxtjs/composition-api in a project that will go live in june, but I'm not sure because of this caveat. (It's not feasible to generate a 4-5k pages website with an interval between pages)
Ah! So, looking at the inline JS with and without interval, I see:
__NUXT__ function โ probably not important.interval, there's an extra entry in globalRefs: "taekfimpnaxhAVnvsFWIbQ==":0.I... don't really know what I'm looking at. But with or without interval, I see five entries in ssrRef. Their values are:
"runs SSR or client-side" โ this must be funcValue"only SSR rendered" โ must be refValue{v:{deep:t}} and t โ these should be shallow and noChange, except I think the injected value should be "server" and "initValue" respectively, so... maybe I'm in too deep here"result" โ this is the onServerPrefetch one that the bug report seems to be talking about, but it's not missingThinking it might be a race condition, I raised the fetcher delay in ssr-ref.vue to 5000. The build appeared to wait five seconds for /ssr-ref to complete, and the output still had "result" in it. Also worked when I raised it to 50 seconds.
I tried rolling back this repo to 0.8.0 (the first minor version I found with an interval to comment out), and in that version the only ssrRefs generated were refValue, funcValue, and shallow โ prefetchValue and (surprisingly) noChange are missing.
Seems possible this bug got fixed by Nuxt at some point? But nuxt/nuxt.js#8852 (comment) was reported 17 days ago on a very recent version of Nuxt, so I don't know.
This is not quite as thorough as I would like, but I have to leave off and I'd rather share it than forget about it, so I'm posting what I have so far.
If a missing ssrRef from onServerPrefetch is the symptom, then git bisect suggests it was fixed in commit 61a3b550afa1ffbeb285aad69c0cba62234da9be (Dec. 12), "ensure ssrRef doesn't share state across requests when used in setup()." That commit is definitely about ssrRefs โ whether it solved the async problem, or just serverPrefetches, or just shuffled around where the bug is, I don't know.
Both of these results (and all the others I got while running git bisect) are with interval commented out.
Before:
window.__NUXT__ = {
layout: 'default',
data: [{}],
fetch: [],
error: null,
serverRendered: !0,
routePath: '/ssr-ref',
config: { globalInject: 'injected' },
ssrRefs: {
'az7O9pBYRKHNFepJZ7cA1Q==': 1,
'ol3L31Q278V6UERkKfCPoQ==': 'runs SSR or client-side',
'l/lQeqSfcCkg14ujE8MvkA==': { v: { deep: 'server' } },
'CfZaYpEA7G1eCb7DcuLcKA==': 'only SSR rendered',
'taekfimpnaxhAVnvsFWIbQ==': 0,
},
}
After:
window.__NUXT__ = function(e) {
return {
layout: 'default',
data: [{}],
fetch: [],
error: null,
serverRendered: !0,
routePath: '/ssr-ref',
config: { globalInject: 'injected' },
globalRefs: { 'az7O9pBYRKHNFepJZ7cA1Q==': 1, 'taekfimpnaxhAVnvsFWIbQ==': 0 },
ssrRefs: {
'ol3L31Q278V6UERkKfCPoQ==': 'runs SSR or client-side',
'l/lQeqSfcCkg14ujE8MvkA==': { v: { deep: e } },
'CfZaYpEA7G1eCb7DcuLcKA==': 'only SSR rendered',
'AwWsPnLHZSNcjcLAqrKvAQ==': e,
'coipqoB5y7ONatlBjVGnXw==': 'result',
},
}
}('server')
I also bisected based on a different criterion and found a different, earlier inflection point: d2b8af173631a177934883c6a4f8c0cfa8f7d400 (June 19), "test: upgrade testcafe and increase export delay."
Before that commit, with interval disabled and the onServerPrefetch delay set to 10 seconds, each page generated takes, oh, 1-5 seconds โ suggesting that page generation is kind of slow, but is not waiting for the prefetch to complete.
After the commit โ which raises the (disabled!) interval from 2 to 3 seconds, and also makes other changes โ most pages are much faster (because, no interval), but ssr-refs takes about ten seconds, suggesting that page generation is waiting for the prefetch to complete.
I don't know whether this means anything.
@eostrom I appreciate you diving into this. This should now only be an issue if ssrRef is used outside of setup context.
Hi @danielroe, this issue is present only when using nuxt-cmposition-api fetch methods or also with nuxt asyncData and fetch old methods?
@liqueflies This should only be present in rare circumstances with this library and not at all if using built-in Nuxt methods.
@danielroe could you detail these rare instances so we can document them and update the docs accordingly?
@Rigo-m I am referring to https://github.com/nuxt-community/composition-api/issues/44#comment-65900
Most helpful comment
@eostrom I appreciate you diving into this. This should now only be an issue if
ssrRefis used outside of setup context.