[sngz]

So the issue I'm referring to is this, which has been open since 2017 https://github.com/facebook/create-react-app/issues/2353

There's a slew of workarounds offered in that github issue, most people (including another team in my org) opted to just rebuild the app every time a docker container is created which kind of defeats one of the major pros of using docker IMO.

I ultimately ended up forking off this repository and customizing it to my needs https://github.com/beam-australia/react-env

that solution in itself is very hacky.

as far as I know, vue doesn't have this feature either but I think next.js and nuxt.js does.

[azangru]

> So the issue I'm referring to is this, which has been open since 2017

I probably don't appreciate the complexity of the issue, but I would say environment variables are not React's concern; it’s up to you how to architect your code. If you want runtime environment variables, then either add them to the html that React will render into, so that the javascript code can read these variables in before rendering, or have an api endpoint that your app will query before or during rendering and will get all the relevant config information from it.

> but I think next.js and nuxt.js does

Probably because they server-side-render. And even if your app renders on the client side; even if you don't use next, nuxt or whatever, there is no-one stopping you from dynamically serving the html skeleton with the relevant variables in it.

But then, it all probably has been mentioned in that issue. I wonder why it wouldn't be a good solution.

[sngz]

> but I would say environment variables are not React's concern; it’s up to you how to architect your code

I don't consider it part of the "code" but part of configuring the application based on the environment you're deploying it on(Precisely why the FE dev basically said its not his problem). The fact that a lot of people are suggesting you just build the app every time you deploy a docker container is really concerning to me.

> I wonder why it wouldn't be a good solution.

it just feels dirty. it's the fact that I have to add these into the code that it feels like a hacky solution for a production app. using a shell script to read read the OS environment variables to create an ENV file then convert that ENV file to a javascript file that is then read, it seems like many things can potentially go wrong.

Ideally they would just deal with this within the dotnev library

[azangru]

Dotenv runs on the server. If a part of your application also runs on the server (such as with Next, Nuxt, etc.), and your responses are generated dynamically, then it is trivial to use the dotenv. If, however, the runtime of your application is confined entirely to the browser, and what you are serving to the browser is only static assets, such as with create-react-app, then, if you still want your environment variables to be defined at runtime rather than at build time, you need to design a bridge between your server and your client specifically for injecting the environment variables.

Here, for example, is an article describing such an injection at the nginx level: https://medium.com/@jans.tuomi/how-to-use-environment-variab.... Or you can serve index.html using a full-fledged dynamic server, such as Node, and inject environment variables there (and probably cache the response for good measure as well, not to overstrain Node). This really is not something that is React’s responsibility — although it may very well be the responsibility of the frontend developer to set this all up.

[sngz]

yep i know how it works after looking into it since I didn't know anything about react before, just makes me not want to use react or vue for any enterprise level software.

All those solutions you mentioned I've considered and are mentioned in the github issue. I just think its way too much work and overly complicated for what is basically a prototype. Which is why I opted for the simple hacky solution.

> This really is not something that is React’s responsibility

This is why I'm already pushing for our team to move off react I don't think its the right fit for us. We also don't like JSX