nuxt-modules / nuxt-modules/sanity

Difference in resources loaded on client when having visual editing configured

Open
#1,024 13 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

question
Dominant language
TypeScript
Stars
265
Forks
43
Avg merge
11h
Merged PRs (30d)
18

Description

As per request from @rdunk in https://github.com/nuxt-modules/sanity/pull/1023, here's more info on what I've found in relation to resources loaded when having visual editing configured.

Wasn't sure what to label this as, not really a bug and not really a feature request 😅

I might be totally off here and just looking at this from the wrong angle, but to me, it looks like that when having visualEditing section configured in the nuxt.config.ts, the page will load with quite a lot more resources.

What I did is create a blank Nuxt project with this module and set up a page that loads a document from Sanity. That page is using the useSanityQuery. In my Nuxt config, I'm just toggling the visualEditing section on/off, running a build and then opening the page with nuxi preview. I have not gone into Sanity Studio (not even running it) and the Presentation tool. I am just loading this page as any regular non-editor user would.

With visual editing configured
sanity: {
    projectId: process.env.SANITY_PROJECT_ID,
    dataset: process.env.SANITY_DATASET,
    minimal: false,
    useCdn: true,
    apiVersion: '2024-05-30',
    visualEditing: {
      token: '<token here>',
      studioUrl: 'http://localhost:3333',
    },
  },

Results in
loaded with visual editing

Without visual editing configured
sanity: {
    projectId: process.env.SANITY_PROJECT_ID,
    dataset: process.env.SANITY_DATASET,
    minimal: false,
    useCdn: true,
    apiVersion: '2024-05-30',
  },

Results in
loaded without visual editing

What I think this stems from is the way the module is set up. We are checking the visual editing config in build time and swapping out the client composables with those meant for visual editing. These composables import additional dependencies and therefore will cause more resources to be loaded on the client no matter if you're actually using visual editing at the moment or not.

The best scenario would be if we'd only load the additional resources when visual editing has been enabled. Only way to achieve this currently, is to deploy two versions of the same site. One "public production build" for all normal traffic where visual editing config is removed, and one "editing production build" that Sanity Studio would connect to and has the visual editing config set up.

In addition, if we can figure out a way to load the visual editing stuff conditionally, it would open up for further optimisation by allowing us to use the "minimal client" (minimal: true) when a user is not currently using visual editing.

As a comparison, using the minimal client results in these resources being loaded
loaded with minimal client

Let me know if I can help with anything!

Versions

module: 1.11.4
nuxt: 3.12.3

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how the visualEditing section in nuxt.config.ts changes the useSanityQuery composables and client bundle. Reproduce the comparison with a blank Nuxt project, a build, and nuxi preview, then inspect which resources are loaded. Done means visual-editing resources are loaded conditionally without affecting regular users or the minimal client option.

Written by the indexing model from the issue text.

Assessment

Tech stack
nuxt, typescript
Domain
frontend, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.