fix(nuxt): await async payload revivers

[CernyMatej]

🔗 Linked issue

❓ Type of change

• 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This PR resolves an issue where the payload reviver was not awaited if it was an asynchronous function. This could be useful for creating more versatile payload revivers (utilizing dynamic imports), for example. However, prior to this change, the revived value on the client would be a promise instead of its resolved value.

It would probably also be a good idea to add tests for this issue. However, I noticed that definePayloadReducer and definePayloadReviver are listed in skippedComposables in the tests. Is there a reason why they are not tested?

📝 Checklist

• I have linked an issue or discussion.
• I have added tests (if possible).
• I have updated the documentation accordingly.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[manniL]

@CernyMatej There are tests in place though, see

nuxt/test/fixtures/basic/plugins/custom-type-registration.ts

Lines 3 to 4 in 629461b

	definePayloadReviver('BlinkingText', () => '<revivified-blink>')
	if (import.meta.server) {

and

nuxt/test/fixtures/basic/plugins/custom-type-assertion.client.ts

Lines 1 to 2 in 629461b

	export default defineNuxtPlugin((nuxtApp) => {
	if (nuxtApp.payload.serverRendered && nuxtApp.payload.blinkable !== '<revivified-blink>' && document.querySelector('#__NUXT_DATA__')) {

[CernyMatej]

@manniL thanks for pointing that out! Didn't notice them. However, those are only fixtures. Where are they used in tests? I'd be happy to write a test case for it if you could tell me where to put it.

[manniL]

@CernyMatej That's it! the first link shows where it is set up and the 2nd link shows where it is checked in the fixture, throwing an error and failing tests when the reviving would fail ☺️
Maybe it'd be already enough to make that case async though 🤔

[CernyMatej]

I noticed that I had made changes to the devalue source code to support asynchronous revivers before making the changes in Nuxt and forgot about them. 🤦‍♂️

At the moment, parse() from devalue isn't asynchronous and doesn't actually await the reviver which causes the revived value to stay as a fulfilled promise. I'm wondering what would be the best solution for this... 🤔

Changing parse() to be asynchronous would be a breaking change, wouldn't it? I'm thinking maybe include the parsing code in Nuxt and change it to be asynchronous - so that other users of devalue are not affected by this change?

[manniL]

@CernyMatej I think it would unless introducing a parseAsync function 😋