feat(nuxt): add <NuxtClientFallback> component

[huang-julien]

🔗 Linked issue

resolve nuxt/nuxt#14885

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 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)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Hi 👋 , this PR adds a <ClientIfFail> component to render its children even if it fails in SSR.
If it fails, the children will only be rendered onMounted hook. An @ssr-error event will also be triggered server-side.

This PR can be improved and i'd like to have your opinion:

• About the name of this component
• Currently, this component needs a uid prop to know if it has failed to render in SSR. I think this can be improved by avoiding the users to set manually a random uid. Maybe by using a transform plugin to auto-generate a uid="randomString" on every <CleintIfFail> ?
• support a component to capture component ssr failed and then automatically render it on client nuxt#14885 @danielroe suggested enhancing <NuxtErrorBoundary>, do you think we can merge this component's behavior with <NuxtErrorBoundary> ?

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[netlify]

✅ Deploy Preview for nuxt3-docs canceled.

Name	Link
🔨 Latest commit	d3c0e69
🔍 Latest deploy log	https://app.netlify.com/sites/nuxt3-docs/deploys/635fd7cacd950400089c3693

[pi0]

LOVE THIS!

For the naming component, I suggest using <ClientFallback>. I thought we could have more client-fallback strategies such as timeout and a more generic name could cover them.

Merging with NuxtErrorBoundary once it supported SSR error capturing, might be a really nice idea but we don't need to wait for it. Also same as ClientOnly (component vs .client) we might have more specific implementation that differs from <NuxtErrorBoundary> that is directly exposed to user-land, which might cause more logic into it.

[huang-julien]

This PR has been reworked to have the same behavior with ClientOnly if at least one children fail to render.

It also correctly handles the different environment (prod/dev) behavior.

At first, the PR was trying to handle only the components that has failed to render but handling it in client-side became a bit too complex. The new behavior is to render a div or its fallbackTag without any children if one child of the slot fails to render. As if we were using ClientOnly.

There's now a runtime uid for each ClientFallback based on:

• a hash of the relative ID of the file
• the attrs of the component
• the number of ClientFallback in the component

[huang-julien]

Added the fallbackTag|placeholderTag and the fallback|placeholder props + the fallback slot (just like <ClientOnly>).

There's a [Vue warn]: Component <Anonymous> is missing template or render function. each time a component fails to render in ssr once build, i'm not sure if this should be documented or not.

[huang-julien]

I'm thinking about splitting the component into a server and client version to avoid having the server-side logic (ssrRender + createBuffer + parts of vue/serverRenderer + parts of @vue/shared) into the client build (dev+prod).

I wanted to use mode: 'client' in addComponent() but this automatically convert it to createClient() so it doesn't work.

Using const component = process.server ? ... : ... then export default defineComponent(component) works + extracting createBuffer to a helper file removes around 10kb from the client build.

What do you all think about this (leave it like this, apply the new suggestion or any other idea) ?

[danielroe]

The bundle test is flagging up that importing from vue/server-renderer in the client app, there are side-effects.

If possible, we should avoid importing from there, or manually mark it as without side effects to rollup.

[huang-julien]

I think splitting it into .server/.client is a bit cleaner, it would also avoid to include 'vue/server-renderer' in the client bundle.

This is a special use case but do we need a mode such as client-no-wrapper for client side components that don't need createClientOnly() ?