Nuxt Generate - Page not showing any content client side, works fine server side.

[drewbaker]

Versions

• nuxt: 2.14.3
• node: 10.13.0

Reproduction

This repo: https://github.com/funkhaus/fuxt

Demo is here: https://fuxt-funkhaus.netlify.app

Steps to reproduce

1. Rename .example.env to .env
2. Use nuxt generate on above repo and deploy to Netlify (or nuxt start locally)
3. Load any page on the site (https://fuxt-funkhaus.netlify.app), content loads off server fine.
4. Browse to any other page via nuxt-link and page new will be empty of any dynamic content.

What is Expected?

Client side browsing should load content from payload onto the page.

What is actually happening?

So it seems server side is working fine. But client side is not. If you look at the network inspector in your browser as you move around the site, you'll see that payload.js is loading and looks to contain the correct code, but it never makes it onto the page for some reason.

The site only contains a few fetch() methods here:
https://github.com/funkhaus/fuxt/blob/master/pages/_page.vue
https://github.com/funkhaus/fuxt/blob/master/components/WpMenu.vue
https://github.com/funkhaus/fuxt/blob/master/components/WpSeo.vue

And a request in nuxtServerInit here:
https://github.com/funkhaus/fuxt/blob/master/store/index.js#L60

It all seems to be inline with the way you recommend the use of fetch(), so I'm not sure what is not working? Perhaps it doesn't like GQL? Or the use of lodash _get in the fetch()?

I wish there was more explanation of what nuxt generate and payload is doing behind the scenes so I could troubleshoot this myself.

[Atinux]

Hi @drewbaker

It is hard to test your reproduction without any token to test actually.

Also, it seems you depend on context.req where actually it is undefined with target: 'static'

[drewbaker]

@Atinux sorry, what token do you need? They are all in .env.example. Just rename that .env.

FYI: I updated instruction to include that.

[drewbaker]

And I don't think we use context.req for anything critical, it's just used to make URL's into relative paths from our CMS. So it shouldn't break if it comes back empty, it's in a lodash _get.

[drewbaker]

@Atinux just pushed an update that removes use of req for you, it's the only way to be sure.

Also updated all packages and Nuxt 2.14.16. Can confirm still having same results.

nuxt generate followed by nuxt start on local (or on Netlify) still results in first initial load working fine, then all other pages loading empty with anything that would have been in payload.

[drewbaker]

Just tried disabling all server and router middleware. No effect.

[drewbaker]

@galvez gave me this temp solution:

I have however a super hacky workaround for you:

Create a middleware/data.js with:

export default async ({ route }) => {
    if (process.server) {
        return
    }
    window.__PAGE__PAYLOAD__ = await window.$nuxt.fetchPayload(route.fullPath)
}

Change pages/_page.vue to:

    data() {
        let page = {}
        if (process.client) {
            const hasPage = window.__PAGE__PAYLOAD__.fetch.find(i => i.page)
            if (hasPage) {
                page = hasPage.page
            }
        }
        return {
            page,
        }
    },

Add "data" to router.middleware in nuxt.config.js. I should note that fetchPayload() won't actually "fetch" anything, it's accessing pre-loaded data.

[papertokyo]

Sounds like the same issue as #7791. The 'solution' seems to be using asyncData instead of fetch but that isn't an option for us as we're calling fetch dynamically to interface with a live content editor.

[drewbaker]

@papertokyo yes that looks like the same issue we are having. I wish we knew more about what "pattern" is causing this.

[by-tim]

I've also come across this issue. I tried using asyncData, as well as setting target to server and it works as intended. It only seems that using fetch() and target: static together seems to be the issue.

[FreekVR]

I was only able to reproduce my issue due to a certain type of nesting of fetch()-implementing components when combined with nuxt-child (#7799), but it just seems that applying the payload back to the correct component isn't fully bullet-proof yet.

[drewbaker]

I just tried making sure fetch() returned a value, but still no luck.

[drewbaker]

@Atinux Do you have any insight to this? Really would like to know if this is something that will be fixed, or if I should refactor around it (replace fetch with asyncData)? For some reason I get the feeling you guys will be improving fetch in Nuxt 3.

[davydnorris]

It's partly related to my issue but not quite.

In investigating my problem I discovered that static generation calls fetch() during the generate and then it's never called again in a static site :-(

If you want code to be called on client side after a static generate, it appears you need to use one of the standard lifecycle hooks in Vue, such as created() or mounted().

I found this quite unexpected behaviour too - I would have thought fetch() should make it into a static render on the client side

[drewbaker]

We found another way to trigger this.

On a static generated site. Have a component that uses fetch(). Then set the the component :key to this.$route.path (in our case we wanted to trigger a v-show animation on page route change). It will load correctly on initial over load, and as you change route the fetch() will run again and be empty.

[realityfilter]

We ran into the same problem. We are using fetch in our default layout component and nested in our page component. When navigating client side to such a route the nested page component is getting the wrong fetchKey because the fetch inside the layout component is not recognized anymore. This is in contrast to the sever side, where layout and page component had their fetch triggered.

I think this case could be handled in setPagePayload. Do not know for the other ones. Maybe it would be better to let the fetch api consumer components pick their own unique fetchKey string.

[drewbaker]

@realityfilter yeah I agree it seems we need to have control over the fetchKey.

Makes sense to me that fetch()'s return value should be the key. If no return value, then it can do the automatic one that it currently does. Or just have a fetchKey setting like fetchOnServer? But that should take a function as often times we'd want to generate that key based on prop values.

[HerrBertling]

I ran into this with using asyncData and target: 'static' – you can see this e.g. here:

https://www.virtualsupporttalks.de/impressum/

If you open that page directly, you can see the content is there because it's correctly rendered server side. But it's gone after a moment and the page is blank.

Also, I get this warning:

The resource https://www.virtualsupporttalks.de/_nuxt/static/1608037846/impressum/payload.js was preloaded
using link preload but not used within a few seconds from the window's load event. Please make sure it has
an appropriate `as` value and it is preloaded intentionally.

What I found strange when looking into the payload.js file: It starts with __NUXT_JSONP__("/impressum", (function(a, b…

I've set the trailingSlash router property in my nuxt.config.js in order to make everything work with Netlify. Which in my wild guesses should result in the payload.js having this output: __NUXT_JSONP__("/impressum/", (function(a, b…. Or whatever handles the payload should be able to handle the trailing slash?

So I tried removing this and… everything works 😅 Could this be the problem? I have to add the trailingSlash option again, of course, because Netlify needs this. Unfortunately, this makes it impossible to link to these pages directly for now 😑

EDIT: Nevermind, this problem is already mentioned here #8476 and should be solved here: #8489 – how satisfying that I was on the right track, though 😄

[danielroe]

Closed in #8466. Would appreciate testing via nuxt-edge to confirm fix.

[drewbaker]

Thanks @danielroe this is so massive for us. Love this. Thank you for fixing!

Ran into some unrelated build errors over here #8508

Can confirm this works innuxt-edge, so happy!

When do you think this will land in a core 2.x release?

[danielroe]

@drewbaker It should land in 2.15...

[adamdehaven]

I can confirm this resolves the issue for me as well (tested in nuxt-edge 2.15.0-26830131.c15078fa) -- much appreciated. Ship it 🚢 👍🏼

[adamdehaven]

Any idea when this fix will be merged in? I have a project on hold for deployment awaiting this fix; while I'd like the answer to be "today" even just a rough guess would help me plan ahead 🙏🏼

[Atinux]

Can't you use nuxt-edge @adamdehaven ?

[adamdehaven]

@Atinux I was under the impression that nuxt is to be used for Production (i.e. more stable), and nuxt-edge is more "bleeding-edge". Is this not the case?

[Atinux]

You can fix a version of nuxt-edge if necessary, normally everything is tester before merged so it is still stable :)

[adamdehaven]

@Atinux ok good to know, I may do just that. Just out of curiosity, since we're roughly 4 weeks from the last 2.x release, does that mean this will in fact be released soon? Again, just asking so I understand the release schedule

[Atinux]

We are a bit late on schedule since 2.15 includes a bigger change regarding PostCSS 8 so we need more internal testing before 😄

[adamdehaven]

So I’m bumping this again to ask if this can be rolled out soon as part of a 2.14.x release, as nuxt is not usable with the generate command without this fix in place and it appears that 2.15 is not being rolled out yet. Possible?

[adamdehaven]

@Atinux & @drewbaker The fix for this bug, which was fixed and working in version 2.15.0-26830131.c15078fa no longer works in the current version of nuxt-edge@2.15.0-26876193.fffb1a19

Something changed between these two releases and this fix needs to be addressed again. 😭

[drewbaker]

@adamdehaven I can confirm we are seeing it NOT WORKING on 2.15.0-26876193.fffb1a19 also. Spent a few hours yesterday trying different variations of fetchKey thinking I was doing something wrong.

[adamdehaven]

@drewbaker @Atinux I just went through all the releases of nuxt-edge and figured out the commit hash that broke this fix is 2.15.0-26873315.0d497496

So to be clear regarding this fix:

• The last version of nuxt-edge that includes this fix working properly: 2.15.0-26871876.6a8339e4 🎉
• The version of nuxt-edge that caused the fix to break: 2.15.0-26873315.0d497496 ❌

[danielroe]

@adamdehaven @drewbaker Really appreciate your checking on this - you definitely caught a significant regression before release ❤️ - see #8802

[lopugit]

I seem to be having a similar problem with a very basic reproduction repo on version ^2.15.7
#10069