Your last point is a cause of some apprehension for me. In the team I'm currently working with one of my coworkers calls himself a React Developer, and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes.

I've seen it in a couple of other individuals as well, and I feel it's becoming more widespread, though I hope I'm wrong. In these instances, I see the framework existing both in the code as well as the mind, and operating outside of it is often a leap too far.

> and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes.

this has been my experience too, I'm a full stack engineer playing a devops role right now on a greenfield govt project. Getting our CI/CD pipeline going within our environment constraints with react has been a pain in the ass. Every time something goes wrong the front end dev just kinda throws his hands up and basically tells me its my problem. I ended up having to go through all the issues opened on github to find solutions and implement them myself. I'm no javascript expert but to me the solutions seem to be super hacky when I've found other frameworks out there that handle these things out the box or more gracefully.

I was on a project supporting legacy code for a long time before this, and was quite looking forward to working with newer js frameworks but this left a sour taste in my mouth. And I already had a bad impression of react prior. I might look into pushing for some of the alternate frameworks out there.

Oof. Sorry to hear the FE dev gives up like that. You may become a JS expert if that carries on.

> the solutions seem to be super hacky when I've found other frameworks out there that handle these things out the box or more gracefully.

I'm curious to hear what alternative frameworks handled these things better? The only one I've used recently, other than React, is Vue.

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.

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

> 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

Personally, I'm super wary of any ____ developer. It's a fixed (vs growth) mindset that tells me they are specialists. I think specialists are best to be consulted by generalists, but not trusted with larger decisions outside their scope.

This is usually a smell that the person is competent at what they do, but doesn't know what's going on under the hood. Funny enough, I'd rather work with someone who doesn't know the specific technology, but knows what the language was built on top of, because they'll have a better intuition for how it actually works and be able to learn it relatively quickly.

I'd rather work with someone like that, too. All is well and good when one can crank out React components, but if that same person doesn't know how to find, for example, the tag name of a element from an event handler, a little red flag goes up for me, and as you said, probably doesn't know a great deal about what's going on under the hood.

Maybe bring it up to him with constructive criticism? Tell him the wind tends to change direction and one shouldn't typecast themselves in this field.

I agree. Though this person can be a bit touchy when constructive criticism is aimed at them, this would most likely be beneficial for them, and also the team, in the medium/long run.