feat(nuxt): experimental option for rich json payloads

[pi0]

🔗 Linked issue

Resolves #19201

❓ 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

Started PR as a smaller refactor to switch to devalue v4. However other than the uneval function that works identically to the current version of devalue in Nuxt, devalue now supports native JSON and reduces/revives with it. This has many advantages over self-evaluating scripts we had been always using for Nuxt since devalue.

Note: This PR is a work in progress and needs more testing, iterations, and reactors. Will be working with @danielroe on it. Meanwhile, feedback is more than welcome regarding the direction and API.

New features:

• Using devalue v4
• Using <script type="application/json"> for payloads (instead of injecting a self-evaluating window.__NUXT__ payload)
• Payload scripts are loaded using cross-origin fetch now (instead of inline import in HTML)
• Custom Types can be registered

TODO:

• Discuss and validate the proposed custom types system
• Benchmark JSON performances over the current self-eval
• Verify XSS not happening
• Verify payload extraction mode behavior

Custom Payload Types

Custom Payload types need to be globally registered by users so that we can reduce (serialize) them on rendering and revive (desrialize) them when initializing the Nuxt application. Previously things like custom classes were considered non-pojos and ignored.

// plugins/vector.ts
class Vector {
  x: number
  y: number
  constructor (x: number, y: number) {
    this.x = x
    this.y = y
  }

  magnitude () {
    return Math.sqrt(this.x * this.x + this.y * this.y)
  }
}

definePayloadType('Vector',
  value => value instanceof Vector && [value.x, value.y],
  ([x, y]) => new Vector(x, y)
)

export default defineNuxtPlugin(() => {
  return {
    provide: {
      Vector
    }
  }
})

<script setup lang="ts">

const test = [1, 2, 3]
const { $Vector } = useNuxtApp()

const s = useState('s', () => ({
  vector: new $Vector(30, 40),
  test,
  nested: {
    test
  }
}))

</script>

<template>
  <div>
    {{ s }}
  </div>
</template>

HTML:

Output (hydrated!)

{ "vector": { "x": 30, "y": 40 }, "test": [ 1, 2, 3 ], "nested": { "test": [ 1, 2, 3 ] } }

📝 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

[danielroe]

Some key changes for consideration:

1. The feature is now opt-in, so we can merge and iterate over the 3.4 release cycle, and hopefully release stably in 3.5.
2. Registering custom types is now done in Nuxt plugins to avoid the risk of XRSP. Once we add object syntax plugins, we can add an easy way for users to ensure their plugin runs at the right time. We can still consider adding global type support later (maybe for $fetch integration? 👀).
3. We support default Vue types of ref/reactive/shallowRef/shallowReactive as well as NuxtError, which will automatically be handled. This allows us to decrease memory usage on client by using shallowReactive for payload. I plan to add support shortly for using shallowRef for their useAsyncData/useFetch requests by passing default: shallowRef, resolving AsyncData with a shallow ref #12406.

Would very much appreciate any thoughts/review, particularly from @pi0 ❤️

[pi0]

Thanks for the updates specially making it opt-in @danielroe 💯 Changes look good to me overall.