Replies: 4 comments 8 replies
-
|
It looks like this is possible today via injecting into window, but it might be worth thinking about a more formal way that's more coupled to environment vars. This is important as it's the standard most folks use today when deploying applications (as far back as the Heroku era). It ends up being the way to config kubernetes deploys, to configure most hosted platforms (e.g. Vercel), and is the known-known for folks. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps we could provide a simple // In your route module(s):
export function env() {
return {
SENTRY_DSN: "xxx"
};
}
// In your root.tsx:
import { Env } from "@remix-run/react";
export default function App() {
return (
<html>
<body>
{/* ... */}
<Env />
</body>
</html>
);
}
// In your browser utils:
function trackError(error) {
track(error, window.ENV.SENTRY_DSN);
}Just food for thought. |
Beta Was this translation helpful? Give feedback.
-
|
What I like to do is to return all my client side env from root loader, then I have a useEnv hook which reads the env variables from the root loader data using useMatches. Then if some route needs that env variable I just call the hook, I never add them to window, I don’t see a reason if all your code using it is most like inside React and you can call useEnv there |
Beta Was this translation helpful? Give feedback.
-
|
In our use cases a hook wouldn't really be ideal as we need to reference this in generic memory vs only within components (it means we could not initialize the functionality before a tree, or outside of a tree). I do think hooks are an ok approach for some. I would consider starting at fundamentals: "how do we make this available, period" since this isnt really something that needs to change post-initial hydration. Hook could be convenient access, but otherwise designing that limitation IMO is not needed. |
Beta Was this translation helpful? Give feedback.
-
|
Just ran into this as well, specifically with sentry, I think we need this: // In your route module(s):
export function env() {
return {
SENTRY_DSN: "xxx"
};
}
// In your root.tsx:
import { Env } from "@remix-run/react";
export default function App() {
return (
<html>
<body>
{/* ... */}
<Env />
</body>
</html>
);
}
// In your browser utils:
import { env } from "@remix-run/react";
function trackError(error) {
// env can reference window.__remixEnv so that we don't put those env variables on window.
track(error, env.SENTRY_DSN);
} |
Beta Was this translation helpful? Give feedback.
-
|
Just implemented this here |
Beta Was this translation helpful? Give feedback.
-
|
Is it correct, that the result of the root loader is not available in the root error boundary? (Would make sense, as the root loader could fail of course) In that case, e.g. Sentry does not have access to the environment variables in an error case and would not be able to track that error. |
Beta Was this translation helpful? Give feedback.
-
What I understand from the documentation is that the variables exposed by the loader are environment variables from the server, not variables loaded at build time. So that's still not great way to pass variables that are only known during the build, like the build version. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @gustavopch did you figure out a good way to define build-time variables like build version / commit? |
Beta Was this translation helpful? Give feedback.
-
|
@richardscarrott Yes. I’m setting the version in |
Beta Was this translation helpful? Give feedback.
-
|
Ah that's a neat idea, easier to parse, modify and serialize JSON than JS. Could even just write them to a separate ./env.json file I suppose 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Yes, you can write to a separate |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Remix has decided that
process.envis off limits for build-time configuration,and instead thinks the user should query an API endpoint for this. While that might be fine in certain occasions, it is not fine in all of them.(edited: usingloader()in Root effectively loads it at build-time via exposing it as a window global)https://remix.run/docs/en/v1/guides/envvars#browser-environment-variables
For example, if I want to expose a build identifier, that would get compiled at runtime, and loaded statically (or dyanmically, but its static after all) when the server generates responses. This is important because this type of configuration often is required to produce the correct build artifacts.
Another example, which is the one I hit, was attempting to inject Sentry's SDK. This requires the
DSN(which is a perfectly acceptable build-time compile-in-and-distribute argument), which typically we would suggest you inject viaprocess.env.SENTRY_DSN. Unfortunately there is no way to inject this at build time (as far as I can tell), which means any runtime error (e.g. initial hydration) cannot be captured.I would look at peers to understand approaches. For example in Next.js this is possible as they allow you to allow-list which env variables are available to the client.
Beta Was this translation helpful? Give feedback.
All reactions