Pass request to the meta function

[Apsysikal]

This problem showed up when needing to generate Open Graph tags like og:image or og:url. These take a url in the form of http(s)://host/pathname. As these are generated in the meta function it would be handy to have access to the request, so we could parse out the hostname. Currently we only have the pathname from matches or location.

The current workaround for me and others (https://discord.com/channels/770287896669978684/1193584644994629702) is to parse the parameters out of the request in the root loader and then access it via the matches[0].data.

[xHomu]

Is there a reason why we don't get the request object in meta? It's always a bit odd to me, how different the props are between all the Remix server exports.

[sergiodxa]

Because MetaFunction runs client side too, so it can't access the request your server received.

[sergiodxa]

MetaFunction runs client side, so it can't have access to the request.

Instead you should return from the loader whatever your MetaFunction needs, eg return request.url or even better the og:image value.

[xHomu]

Which exports are server side? Only action, loader, headers? What about exports like handle?

[sergiodxa]

Yea only those three, handle is also sent to the browser because you can access it with useMatches, similarly because Meta component needs the MetaFunction and Links component needs LinkFunction that's why those run client side and server side

[Apsysikal]

Thank you for clarifying. I guess it's not an easy fix 😅
It just felt weird to send the host to the client as the client knew it to make a connection.

[meglio]

So, how do I read some content from a config.ini file and pass it through to meta if it is not reading any loader data when rendering root ErrorBoundary?

[kiliman]

Ok, I'm almost finished with my example.

It supports global app data that is initialized at startup and is available in your loaders, route components, and ErrorBoundary. It even supports Promises, so if you need to fetch or use fs promises, you can.

It also supports access to request data (for example, hostname). The handleError export is used to marshal the request data via the error.message property.

It handles both server and client-side errors.

Here's a snippet of code. Once I clean up the example and types, I'll push it to GitHub.

// global-data.ts
export const init = serverOnly$(async () =>
  setAppGlobals({
    APP_NAME: "Remix App",
    NODE_ENV: process.env.NODE_ENV,
    VITE_TEST: import.meta.env.VITE_TEST,
    CLIENT_KEY: process.env.CLIENT_KEY,
    ENV_FILE: (await readEnvFile()).split("\n"),
  })
);

function readEnvFile() {
  return fs.readFile(path.resolve(process.cwd(), ".env"), "utf-8");
}

// entry.server.ts
export function handleError(
  error: Error | ErrorResponse,
  { request }: LoaderFunctionArgs
) {
  const url = new URL(request.url);
  if ("data" in error) {
    const e = error as ErrorResponse;
    e.data = JSON.stringify({ message: e.data, hostname: url.hostname });
  } else {
    const e = error as Error;
    e.message = JSON.stringify({ message: e.message, hostname: url.hostname });
  }
}

// root.tsx
export function ErrorBoundary() {
  const error = useRouteError();
  let message = "";
  let hostname = "";
  if (isRouteErrorResponse(error)) {
    message = error.data;
  } else {
    message = (error as Error).message;
  }
  if (message.startsWith("{")) {
    const d = JSON.parse(message);
    message = d.message;
    hostname = d.hostname;
  }
  return <ClientErrorBoundary error={{ message, hostname }} isServerError={true} />;
}

export function ClientErrorBoundary({
  error,
  isServerError,
}: {
  error: Error & { hostname: string };
  isServerError: boolean;
}) {
  const appGlobals = getAppGlobals();
  let { message, hostname } = error;
  if (!hostname) {
    if (typeof document !== "undefined") {
      hostname = document.location.hostname;
    }
  }

  return (
    <>
      <h1>
        {message} @ {hostname}
      </h1>
      <h2>{isServerError ? "Server Error" : "Client Error"}</h2>
      <pre>{JSON.stringify(appGlobals, null, 2)}</pre>
    </>
  );
}

[meglio]

This looks promising, thank you. Is there a way to see it as a "diff", so that it is visible what is the default template and what is the new code that made this magic happen?

[kiliman]

Yeah, I'm going to push as a series of commits so you can see what changes were made.

[meglio]

Also, Remix should support some serverside-only export function getRuntimeGlobalPublicApplicationData() and make it available everywhere through some hook useRuntimeGlobalPublicApplicationData() to avoid gymnastics like the above. Runtime global application-wide data is a typical use of data in applications.

Alternatively, since you now have Layout, there can be a serverside-run export getLayoutData(), which is then accessible through useLayoutData(), and from there, it can be passed down through react context (or used in components deep down the tree via the same hook).

Yet, to be fair, I still don't get it why the root loader data is not available in the ErrorBoundary. I would assume since it is root, it is called always, and unless it fails, the data it loads should be available to everyone through the hook, including root ErrorBoundary (since the root ErrorBoundary is in some sense the root page, just the "error" version of it, but it's still root, so there can still be the loader data).

[kiliman]

I finally got my example finished and deployed. Check it out here.

https://github.com/kiliman/remix-global-data

There's even a link to a deployed app.