Hmm… I’m wondering if this situation might be partially due to a mismatch between our Remix starter project (which uses an older, cookie-based preview system) vs the Web Previews plugin (which uses a newer webhooks and redirect based system)? Once we figure out what’s going on here, I’ll make sure to update the project and documentation so it’s clearer.
In the meantime, after some work, I was able to get a Remix project working with the plugin, but it was quite the hassle.
Can we see if these steps line up with what you’ve tried already?
Requirement 1: Webhook destination serverless func / handler
You’ll need to set up a new route in Remix to handle the webhook. This is the serverless func that will catch your outgoing webhook (from the plugin) and return the two URLs.
Example file here (sorry for the jank, it’s my first time working with Remix).
Some caveats, though:
- It needs a
loader
function to handle the webhook’s OPTIONS
request and return the proper CORS headers
- It ALSO needs a separate
action
function that handles the webhook’s actual POST
request. This function does several things:
- Figure out the current domain name the site is hosted at (creating a
baseUrl
, in my case in the example from Vercel or Netlify’s env vars)
- Parse the incoming webhook’s JSON (
await request.json()
) to get the webhook’s body, which DatoCMS fills with dynamic data matching whatever entry you called the plugin from
- Using this request body, look up & return the proper URLs based on rules you define. In my example, it examines the request’s item type (via the
itemType.attributes.api_key
). And if it’s a post, it returns a URL like posts/$slug
Requirement 2: Some way to start and stop the preview system, and redirect to published or draft versions of a page
IMO this is one of the more confusing parts. The plugin shows a Next.js example implementation, and that works fine with our Next.js starter app because it’s built to handle the redirect: https://github.com/datocms/nextjs-demo/blob/master/app/api/draft/route.js#L20-L26
However, our Remix starter project is NOT currently set up to do that. By default, its start/stop systems only set a cookie and then redirect back to the home page. With a little bit of work, you can modify them to work with the plugin:
In both cases, I added a new loader
function that is largely similar to the existing action
function, with a few significant differences:
- They are a
loader
because that’s what Remix uses to handle GET
requests from your browser (like when you click the preview link from the sidebar). The original action
can only handle POST
requests, which is what the starter project normally uses to set a cookie, but the plugin uses a different setup.
- They also have to parse the request URL for the
redirect
URL parameter, and redirect your browser to that page instead of back to the home page
- This still have to set/unset the
preview
cookie, because that’s what our Remix starter project uses to handle preview mode. (The Next.js project functions differently)
That’s quite a handful, isn’t it? But doing the above at least let me get a working deployment up for the preview links in the sidebar… (though not yet the side-by-side preview; will have to work on that later).
Does referencing that help at all vs what you’ve tried so far?
If not, please do provide more details and we’ll try to figure it out!