> 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
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.
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
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