fix(nuxt): stringify cookie values before broadcasting them

[hendrikheil]

🔗 Linked issue

#21651

❓ 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

Resolves #21651 by preparing the cookie value for the structuredClone that's used by BroadcastChannel.postMessage.

It does this simply by cloning the value which might potentially hold nested Refs. toRaw unfortunately only applies to the root Ref, not to any nested Refs.

📝 Checklist

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

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[hendrikheil]

This PR will be squashed right? I'd force push to avoid the little commits fixing my debugging artifacts if not

[danielroe]

Yes, the pr will be squashed. I guess I'm thinking that the encoder has to produce a string to save the cookie. (It won't be undefined as we have defaults.)

[danielroe]

Thank you ❤️

[hendrikheil]

@danielroe I noticed you removed the ternary. This could theoretically lead to encode or decode being undefined. {...defaults, ..._opts }, unlike defu, overwrites when a key is set to undefined.

Not sure if thats something this should really worry about as it would clearly be the users fault, but it's theoretically possible, so I wanted to mention it :)

[danielroe]

Ah, you're right. I initially thought it would error if the user did that, but I think implementation in cookie-es would actually just fallback to encodeURIComponent directly.

I think this is likely an edge case but if you want to, we could also cover this scenario. I just don't want to add too much runtime code to cover this scenario.

[Aietes]

Has this actually been merged? I'm still facing the issue on the latest nuxt release:

DOMException: Failed to execute 'postMessage' on 'BroadcastChannel': #<Object> could not be cloned.
    at SupabaseAuthClient._notifyAllSubscribers (http://localhost:3000/_nuxt/node_modules/.cache/vite/client/deps/chunk-A274CJAX.js?v=fac2f4d6:2156:31)
    at SupabaseAuthClient._recoverAndRefresh (http://localhost:3000/_nuxt/node_modules/.cache/vite/client/deps/chunk-A274CJAX.js?v=fac2f4d6:2101:20)
    at async SupabaseAuthClient._initialize (http://localhost:3000/_nuxt/node_modules/.cache/vite/client/deps/chunk-A274CJAX.js?v=fac2f4d6:987:7)
    at async http://localhost:3000/_nuxt/node_modules/.cache/vite/client/deps/chunk-A274CJAX.js?v=fac2f4d6:950:16
_recoverAndRefresh @ chunk-A274CJAX.js?v=fac2f4d6:2105
await in _recoverAndRefresh (async)
_initialize @ chunk-A274CJAX.js?v=fac2f4d6:987
await in _initialize (async)

[danielroe]

It was released in Nuxt 3.8. Are you sure the log you linked is related to this code, and not another issue in the supabase module?

[Aietes]

@danielroe I'm not sure, it could be a supabase issue. It's hard to determine what really causes this issue, I'm not sure how to even provide a reproduction. I'lll also bring this up on the supabase repo, and see if we can find a specific cause.