App Proxy Pages don't work

[nboliver-ventureweb]

Trying to set up an app proxy page that renders a form using React. The page should render in the context of the theme (ie. show the header and footer), but even with a bare bones example on a brand new app, it is not functional.

Following the examples from here: https://shopify.dev/docs/api/shopify-app-remix/v3/app-proxy-components/appproxyprovider and here: https://shopify.dev/docs/api/shopify-app-remix/v3/authenticate/public/app-proxy and using a fresh app created today.

Request url: https://test.myshopify.com/apps/proxy/test-page/
Shopify.app.toml:

[app_proxy]
url = "https://reform-mason-managed-capable.trycloudflare.com"
subpath = "proxy"
prefix = "apps"

Route markup (app/routes/test-page.jsx)

import { authenticate } from "../shopify.server";
import { useLoaderData } from "@remix-run/react";
import { AppProxyProvider } from "@shopify/shopify-app-remix/react";
import { useState } from "react";

export async function loader({ request }) {
  await authenticate.public.appProxy(request);

  return { appUrl: process.env.SHOPIFY_APP_URL };
}

export default function App() {
  const { appUrl } = useLoaderData();
  const [count, setCount] = useState(0);

  return (
    <AppProxyProvider appUrl={appUrl}>
      <div>
        <p>You clicked {count} times</p>
        <button onClick={() => setCount(count + 1)}>Click me</button>
        <div>{appUrl}</div>
      </div>
    </AppProxyProvider>
  );
}

Problems:

1. In the documentation and responses to other github issues it implies that the route file should be located at app/routes/proxyPrefix.proxySubpath.route.tsx. This does not work and results in a 404. Moving the route file to app/routes/route.tsx does return the markup correctly.

2. CORS errors: after digging through a bunch of issues, I found this: Update vite cors settings #977. Since I'm using a new app, those changes are already configured. I added an origin property to Vite config, which seems to resolve the CORS thing, but this is not scalable and doesn't seem like a recommended solution.

export default defineConfig({
  server: {
    allowedHosts: [host],
    cors: {
      preflightContinue: true,
      origin: [
        `https://test.myshopify.com`
      ],
    },
...

4. After resolving (maybe) the CORS issues, there are hydration errors. The html momentarily shows, then this error appears:

In the console there are numerous errors:
Uncaught Error: Hydration failed because the initial UI does not match what was rendered on the server

Hoping for some guidance in how to resolve this, as it seems like the basic functionality of app proxy within the template, including theAppProxyProvider component is not functional, or there is some critical piece of documentation that is missing.

[lizkenyon]

Hi there 👋

A couple of things

The page should render in the context of the theme

Only if you return liquid will it render with the header and the footer. If you are not returning liquid you will not get the header and the footer.
Docs

Because of limitations with Remix you will want your route for you app proxy page to match the route in your app exactly.

e.g. In my app I have my route apps.appProxy_.next.tsx

This is a good call out for adding the cors headers for production, that is not something we have documented. You will probably want to look into a custom server.

I do find I sometimes run into instances when I am frequently changing my app proxy configuration that I may run into caching issues on Shopify's side, that eventually do resolve itself. (Just sharing in case you also happen to run into this. I have shared internally this issue)

[nboliver-ventureweb]

@lizkenyon Thanks for the reply.

The screenshots helped with some things that the docs are not really clear about, particularly that you need the prefix and subpath also included in the url configuration. We have a different Remix app in production that uses a proxy route as a resource route (ie. form data is posted from the theme, and json is returned) and it works fine without the prefix and subpath. Would definitely be beneficial to clarify that to the docs (maybe with a screenshot :) )

Our desired approach is to return "Content-Type", "application/liquid" AND use client side JS (ie. Remix route components). The route component would be a form that would mutate data in an action, just like you do on the admin side.

It's not mentioned in any documentation whether you can actually do this, but from my testing, it does not seem possible. We have the route set to return content type Liquid in entry.server.jsx, which results in showing the theme header / footer momentarily, then renders the page on its own (no theme context) with a bunch of hydration errors.

Can you confirm if this is possible? If it is indeed not possible, it would also be good to document, as there is a fair amount of confusion on this topic across the various Shopify community surfaces. Would be happy to assist with improving documentation if that would be helpful.

[leighgibbo]

Bumping this one to see if there's been any further development.
Also to add, isn't it a potential issue that the Remix routes need to match the app proxy path/subpaths exactly, because as per these docs, merchants could change the paths to their installed app and therefore break it?

[wind4gis]

@nboliver-ventureweb I've encountered the same issue. Have you resolved it on your end?

[nboliver-ventureweb]

@wind4gis Unfortunately it doesn't seem possible, which is a shame because it could be a really powerful feature. I think the alternatives are to use theme app blocks and customer account extensions, but neither have the same level of integration with the backend logic of the main Remix app, so it creates a disjointed experience, requiring adapter code and extra dev workflows.

[wind4gis]

@nboliver-ventureweb Our team used a very unique approach: handling SSR separately within React Router, using Fastify to process page requests for the App proxy, and then manually constructing script requests by reading manifest.json during the manual SSR process to avoid asynchronous script loading. It's currently working, but I still feel this solution is too much of a hack and doesn't align with the principles of React Router at all. Manually handling SSR in a framework that already supports SSR is truly ridiculous.

[nboliver-ventureweb]

@wind4gis Agreed! That sounds like a good workaround though. Are you returning "Content-Type", "application/liquid" for those requests?

[wind4gis]

@nboliver-ventureweb yes