Client-side Live Preview: how to subscribe to multiple documents at once

[HarleySalas]

Link to reproduction

No response

Describe the Bug

This takes place while using the live preview for a Globals config.

Since I'm editing a Globals config, via live preview and nothing can depend on Globals, I find it quite questionable that the url /api/pages/ is getting "Too Many Requests". The page that the live-preview links to is the same page that one of my /api/pages links to, but in this instance, that is not the content I am editing.

It should also be noted that the id's for each of the pages being requested there are different pages as well, so it's not like it's only the page I'm currently on. I also don't use any of the page id's in my frontend. I use a "pathnames" field. So, I know that these requests are somehow created by useLivePreview, or Payload itself.

I know there are a lot of optimizations coming for live-preview. I just wanted to point this out, as it seems to me that live-preview attempts to use all useLivePreview instances, or something? I'm not really sure how it works under the hood, or what you're currently aware of. However, I don't think we should be able to rate-limit ourselves with live-preview, and it definitely shouldn't be sending requests for data that is not even being edited.

Payload is running separately from my frontend.

cors and csrf contain my frontend's url.

here is what my useLivePreview hook looks like, for my globals:

  const { data: companyInfo } = useLivePreview({
    serverURL: process.env.NEXT_PUBLIC_CMS_URL,
    depth: 2,
    initialData: globals.companyInfo,
  });

At any given time, 2-3 instances of useLivePreview are loaded on a page for me. It's unclear to me if that is undesirable. I would have assumed that nothing can happen with an instance of useLivePreview, unless that specific data is edited, though I'm not really sure how payload differentiates which one it should be interacting with. I don't think there is any instance where someone would realistically only have one on a page though? (ie; layout client component, managed with globals and page component(s) managed with a page client component.

To Reproduce

Go to any live-preview field. Enter characters rapidly.

Payload Version

2.0.14

Adapters and Plugins

No response

[matthijs166]

Related to #4281 and #4287?

[jacobsfletch]

Thank you for the detailed report @HarleySalas 👍

However, I don't think we should be able to rate-limit ourselves with live-preview, and it definitely shouldn't be sending requests for data that is not even being edited.

I completely agree. Others have run into this too, but it's likely a remnant of an early version and has since been fixed. I also just pushed many optimizations to Live Preview which will help with this even more, including #4306 and #4315 which are especially big.

At any given time, 2-3 instances of useLivePreview are loaded on a page for me. It's unclear to me if that is undesirable.

You should only every load a single instance of this hook. That is because it "connects" to your main window via post messages, and each time the form state changes in your document, the form state is transmitted, traversed, merged, then populated. It would be expensive / unnecessary to do this multiple times simultaneously. You should instead call the hook one time in your page then pass the page props around to wherever they are needed within your app.

BUT your problem likely lies in the fact that your header and footer are rendered completely outside of your page. You'd need to somehow lift the Live Preview result into your header and footer. This gets tricky when thinking about RSC, but its not impossible. You could still use something like context for this. I do see your issue though.

So that's likely the basic setup, but there's still the issue of that fact that your page hook will only ever subscribe to its respective document, and not the globals required of the header and footer. These are completely unknown to the page. So we might need to think through a new feature here. Like an additional flag on the hook that allows you to return more than just the page.

What do you think about all of this?

[jacobsfletch]

@HarleySalas if you are able to get onto v3, Server-side Live Preview will completely fix this issue. As changes are made to a document in the admin panel, a roundtrip is made to the server, refreshing all components that are rendered on the page—including their API requests (unless cached). No client-side hooks at all.

Since this is more question around setup, I'm going to convert this issue to a discussion now so we can keep the conversation going. If server-side is not currently an option for you, this could potentially become a feature request, pending technical limitations.