Understanding the react dev environment for beginners

If you're like me you probably made the mistake of jumping straight into react after you've gotten used to coding JS in the browser.

And if that's the case you probably felt lost like I did because you're trying to learn the framework inside a giant black box of other complicated stuff like Webpack, Babel, Typescript, NPM, etc. If that's you at the moment then maybe this high level overview from the perspective of a fellow junior could help you de-mystify this combination of tools.

What is NPM and Node.js?

You probably heard a brief explanation for these before, Node.js is used to run JS outside the browser and NPM is used to manage your dependencies. That's really all it is but if you're still confused then for now treat NPM like a manager for adding third-party libraries to your app, like embedding a <script /> tag for Bootstrap or Bulma. And then your package.json file contains a list of the dependencies you've added.

How does my code get run on the browser?

Well first we need to understand that when you type "npm run dev" or "npm start" in your command line, you're actually starting a local server (if you've used the Live Server Extension then it's just that). The local server then hosts your app on a port, hence why you see your application on localhost:XXXX.

// start
- run the command: "npm run dev"
- NodeJS creates a local server
- local server hosts your app on a port

This server will be running until you close the active terminal or stop the process with Ctrl + C. Whilst it's running, whenever you make changes to your code, it will listen to that change and update the app on the browser.

// running
- you save your changes to your code
- server picks up on that change
- server then updates the app on the browser

Note that it doesn't refresh the entire page but only updates what needs to be updated, this method is called Hot Module Replacement (HMR).

Where does Webpack and Babel come in?

These tools actually have been doing it's job the whole time, Webpack is the one responsible for listening for changes and compiling your code and uses Babel to compile modern code to old code so that your app can run in older browsers, as well as converting JSX into regular JS. At the very start and whilst your updating your code, Webpack is doing it's job:

// start
run the command: "npm run dev"
NodeJS runs Webpack which spits out a local server
Webpack compiles your code
Webpack hosts your app on a port

// running
- you save your changes to your code
- Webpack picks up on that change
- Webpack compiles the new changes
- Webpack then updates the app on the browser

Note that even though I'm using Webpack in this example, this also applies to other tools like Vite. Also, this process of listening and re-compiling is optimized so you don't have to worry about Webpack having to recompile your whole app every time you save.

What exactly is the server hosting?

It's actually hosting an index.html file, the JS bundle, and other static assets you've included. Webpack then attaches a <script /> tag to the html file that points to the JS bundle so that the browser will load your JS.

// start
- ...
- Webpack compiles your JS into a bundle
- Webpack hosts the other static assets and index.html
- Webpack adds a <script /> tag to html file
- Webpack hosts your app on a port

This is also what happens after we run "npm run build", we get a folder that contains all the files needed to host our app on the web:

- index.html
- js_bundle.min.js
// other static assets...

Note that vite does do things a bit differently, instead of bundling your code into one file, it serves all of them as ES Modules, it will still bundle them in production (when you run "npm run build").

What about ESLint and Prettier?

ESLint doesn't do any transformations on your code, it's a tool used for highlighting errors and code smells. Nothing much to do with the main process above.

Prettier is just a code-formatting tool, you can download the extension to have it be your default code formatter when you press Alt + Shift + F on VS Code, or install it through NPM.

What's up with all these files in my root?

Most files that have names such as ".config.*", ".json", etc. Are configuration files for the various tools the project is using. Even ESLint and Prettier can be configured with such files ".eslintrc", ".prettierrc", and so on.

Some tools allow multiple names for their config files, but you can usually tell which is which. It could be a bit daunting seeing a weirdly named file at the root but it's most likely there to configure some internal stuff your environment is using.

For the most part you wouldn't need to worry about configuration, memorizing every config property isn't necessary, the defaults should be good enough for most.

More on JSX and Babel

As mentioned before, Babel will handle compiling your JSX code to React.createElement calls. The thing with JSX is that it isn't natively supported in JS, you can call it an extension of JS, where we add new syntax to JS and then convert it back with Babel so that the browser can read and execute it properly. Babel actually has a playground where you can see the converted code as you type it!

What about Typescript?

Typescript is kind of the same as JSX but in a much more larger scale. We still need to trans-pile it to JS to run it in the browser. As to what is trans-piling your .ts and .tsx files varies depending on what you've used to bootstrap your project, CRA uses Babel for everything and Vite uses the Typescript Compiler (tsc).

Conclusion

Pretty nifty right? I'll be honest I am pretty sure this isn't even everything, there could be more config files from other tools that your project will use, like testing with jest or integrating storybook, its... its a lot, but don't worry about it, it's not a deal breaker if you don't know the exact specifics of the tools you're using, but it's important to know how they all come together.

Cover image by Tim Hüfner on Unsplash