Config File in ReactJS application - reactjs

I have developed a reactjs application and have hosted in azure cloud. Now we want to implement the CI/CD process through Azure pipelines. I am quiet new in both the platforms. Need to know the process.
Currently, I have one file index.js where I have used the axios and have set the base URL to connect to the server. All my web services in different components class access this axios settings for accessing data from server. We have four environments, DEV,SIT, UAT and PROD. So for now I use to manually change the axios base URL and create the build and zip it and host it to the respective environments.
I need to understand for CI/CD what steps should I take. Most of the google finding suggested to have a config file. But how I can change my current implementation is a big challenge for me. For example my axios base URL, how it will take the value from the config file, or where I should create the config file, because when I create the build, all the js files are minified into one file and are put in the static folder. Apart from the static folder, the app icons and the files in the public folder of the project directory are listed (in the build folder). So shall I include a config file in the public folder or something else.
There are also webpack.config.dev.js and webpack.config.prod.js in the config folder of the project directory. Will it help. Because the requirement is first through Azure pipelines, the code will go to the DEV environment, then from DEV to SIT and from SIT to UAT and then to PROD. So subequently my axios Base URL should also change accordingly.
Can anyone suggest anything?

I'm not sure I fully understand your question but you could create a json file and put your config data in there, i.e. server_config.json. It would not be minified as it is not a js file. Then you will need to read the json in your code to get all the settings. Your CI/CD can also read this fille should it need to.
You should also make sure that the json config file is ignored from version control so that each environment has to have its own file.

Related

Adding connection strings to a production app

I have an app ready for production. For it to work, each client needs to set a unique url to access their data. How would i prepare the app for making it easy to add a url as an access point to the clients?
Would a correct way to do this be to add it in the manifest.json file and somehow reference it from there? (Until now in development i've only used a global URL in a js file)
You need to install the package dotenv package and create a .env file in your root directory which should contain your environment variables.
Assuming that the URl you are referring to is http://localhost:3000/some/url on your localhost, then your .env file might look like:
MY_URL=http://localhost:3000/some/url
Then in your react application, you can get the value of MY_URL by doing:
const url = process.env.MY_URL
Note that if you are using the create-react-app package, then you do not need to install the dotenv package since it already comes with the create-react-app package. Also you need to change it:
REACT_APP_MY_URL=http://localhost:3000/some/url
Also make sure to add the .env file to your .gitignore file so that you do not push it to your repo.
Assuming that you are deploying your application to Heroku. Heroku provides a simple interface which allows you to add your environment variables which looks like:
That's it.
Maybe you could store them in environment variables?
that way you can always edit them later without having to change components.

How can I read files outside src?

I understand that in react you cannot import files outside src folder.
But what is the reason for it exactly and can I disable it?
In my project react web app is only part of the whole thing, and different parts share some files (configs, build output), so folder structure looks like this
ProjectRoot/
config
build-output/
Part1/
Part2/
WebApp/
src/
...
Sure, you can copy files or create symlinks, but that's duplication and inconvenient.
This is a restriction of Create React App only.
This tool exists to get new users up and running with the react framework as fast as possible by abstracting away the tooling. The part of tooling that is limiting you in this instance is their webpack configuration, which is preset to only look for javascript files in your src directory.
That explains the why? but to answer the other half of your question:
how can I disable it?
Is that you would need to eject from Create React App and then modify your webpack config to allow it to search directories other than src/
First - this has nothing to do with react itself.
If you refer to importing javascript modules (for now using module loaders like systemjs, require, etc.) then the answer is:
It depends what directory is being served by web server. If you have set up your web server to serve WebApp/src folder only - then no, browser will not be able to get access to the files outside and so module loaders. If you will serve all ProjectRoot directory - then yes, you can.
If you prepare your web application for deployment using some sort of bundlers (webpack, browserify) - it depends on how you will configure them and instruct to include the required files in the resulting bundle.

Can I deploy react.js web app to a share hosting?

I am wondering if it is possible to deploy react.js web app that I've built to a share hosting site that does not have node.js installed?
I use webpack to build the application and it creates normal html, js, css file. I uploaded the static folder that includes all those html, js(bundle.js) and css files, but when I request the site, the server reply with 404 bundle.js not found response.
Use npm run build, you should get a folder with the index html file inside that will run your app. Try this with xampp first before you actually deploy to your server.
Here is everything step by step
npm run build
or
yarn run build
it will generate a build folder that looks like this:
Copy everything and move it to the htdocs in xampp or ftp upload the directory to the public_html file in your hosting
Yes you sure can put react on a shared hosting provider.
Seeing as you're getting a 404 error (not found), you are probably referencing your react file/bundle incorrectly. It might not even be named bundle.js if you're using a boilerplate to create your application.
Can you give more information? What does your index.html file look like? What does your directory structure look like? If you are able to post these files I can tell you what the issue is.
Update:
The answer below should be accepted. (Although this would assume that you have the ability to make a build which you have not verified or not.)
Make a build using the build command through whatever boilerplate you used. Deploy those files on your shared hosting server. Make sure that index.html is at the root of where your server is expecting the root to be and your app should be live.
For deploying a react app on a shared hosting you need to create a production build. Production build is a pack of all your react code and its dependencies.
in most shared hosting we put our site/app inside a public_html directory so if we hit www.yourdomain.com it serves the code from public_html directory.
so if your react app is ready to go, edit your package.json file add a new key value:
"homepage":"http://yourdomain.com"
then create a build using following command:
npm run build
after running the command you will see a new directory named build in your app root. It will contain js and css for the app and a index.html file. You need to upload all the content inside build directory to public_html directory, and that's all, go to your domain and your app will be working just fine.

.config vs. .env files in node.js w/ heroku

I'm in the process of doing my first deployment of a node.js app on Heroku. While running the app locally I stored API keys and other configuration variables in .config files excluded from version control.
Heroku seems to have built-in support for a ".env" configuration file in the project root and I've refactored my server code to support this. My question is where is the best place to store configuration variables that need to be accessible in the client? I'm running angularjs on the front-end and need to be able to access various API keys.
Is there some way I can reference the same .env file or should I be approaching this differently?

GAE App.yaml - separate directories for src and build static files

Is it possible to optionally override a static files directory in the Google App Engine app.yaml file if another directory exists? I have a source directory (unminified) and a build directory (minified and concatenated). I want Google App Engine to automatically use the build directory instead of the src directory, if it exists. That way I can dev using the src directory, then create a build and deploy it. Then, if I delete the build directory, GAE goes back to serving my static files from the src directory.
The reason I need to do this is because I am building an application with Backbone.js & Require.js as modules. I need to be able to optimize my code and deploy without changing my app.yaml file every time.
I'm pretty happy with my current system where my framework uses different paths in the templates to the source javascript files. Then at startup, through a combination of checking os.environ and get_application_id() I automatically detect whether I'm running locally on dev_appserver, or under my test appid or production appid on GAE.
And on to the next step, you most likely want to cache your minified JS aggressively, in which case you'd be unable to force clients to update a new version. The typical workaround is to append a hash or date string to the minified js filename whenever it's updated. This is something you'll also need to do in your framework/templating layer instead of app.yaml.
I would do this at the template layer - when you go to render the template that includes links to your assets, check to see if the minified version exists. If it does, link to that - otherwise, link to the unminified version.
This also helps if you accidentally deploy without creating a build - you'll just be serving unoptimized assets.

Resources