This course has been updated! We now recommend you take the Complete Intro to React, v8 course.

Check out a free preview of the full Complete Intro to React, v6 course:
The "Dev Environment" Lesson is part of the full, Complete Intro to React, v6 course featured in this preview video. Here's what you'd learn in this lesson:

Brian shares some tips for development including switching the node environment from development to production when the project is being shipped. A student's question regarding how the environmental variables should be set for a build is also covered in this segment.

Get Unlimited Access Now

Transcript from the "Dev Environment" Lesson

[00:00:00]
>> So I've got a couple kind of development tips for you, things that I found very, very helpful when I'm writing react code. One of them that's absolutely key. When you're writing your code, you want the NODE_ENV to be development. So when I say NODE_ENV, let me just show you here in a terminal.

[00:00:20] Let me just pop up this terminal here. So, in bash, you don't have to follow along with me too much. But if I say NODE_ENV=development echo NODE_ENV doesn't even say that. Well suffice to say what I was trying to demonstrate to you, and I could write node code that would pull this out.

[00:00:56] But the idea is that you can set this environmental variable to be development, production, test. There's a bunch of things that this can be set to. And it's really critical with React that when you're in development mode that that NODE_ENV is set to development. Because all those really nice error messages that you and I are getting of not showing the correct key.

[00:01:19] Or your hooks are called out of order, all that kind of stuff. All the instrumentation for that debugging code only comes when it's a node equals development. Now the good news for us is Parcel sets all this stuff for us automatically. You actually don't have to do anything and Parcel will set it for you.

[00:01:33] But with tools like web pack and some like less opinionated tools, you have to set those yourself. So just be very careful that you do development when you're in development mode. And then make sure it's production when it's going out to production. Because you don't want the developments tips and tools because it's like four times bigger.

[00:01:50] So by just setting it to NODE_ENV=production, as you can see here, it's literally four times smaller. Slack famously made this mistake that they were shipping the development mode in Slack for a long time. And they saw a huge speed up in Slack just by switching it to production.

[00:02:12] It's extremely easy to do. I don't fault them at all. But I wish they had found that sooner because I use Slack a lot in my day to day life.
>> And the reason the echo wasn't working was you've got two ampersands between the commands.
>> You are absolutely correct, thank you.

[00:02:29]
>> You're welcome.
>> So you can see here NODE_ENV=production. So this is like an environmental variable that you can use to. And again same here production. I might even have it set on my computer, just always be yeah, well now I've done it temporarily for my entire session, right?

[00:02:51] Anyway, there's a whole nother class on that again, Linux and the command line. You can take that, I go into this stuff pretty in depth. But as you can see, I have to retake my own course sometimes cuz I forget some of these details.
>> This just to confirm.

[00:03:05] So you're saying it's safer to just leave it as production, so that we don't accidentally ship or you're saying just remember to change it?
>> So, actually what you'll probably end up doing, this is a good question, when should you care about this? Normally, actually in my dot bash RC, so if I say like, code.

[00:03:30] Bashrc, so this is your configuration for your bash environment. If you're using Power Shell, this is not helpful to you. I would just have in here NODE_ENV=development because whenever I'm on my local computer, it's always development right? I've never shipping stuff from my local computer to the cloud.

[00:03:47] I always do that through GitHub actions or something like that. But what I am saying is if you are doing that kind of production bundling from your local computer. You do need to make sure that you're setting that before you do it. So what you really wanna do here is maybe here you would say like NODE_ENV=development, right?

[00:04:11] And then you would set those here. This will only work in Bash, this would crash on Windows if you try to do it this way. But you wanna make sure that those environmental variables are being set. Good question. How should you be setting the environmental variables for the build?

[00:04:25] One, if you're using Parcel it just happens if you say, so dev, it automatically sets the environment to be development. And then we haven't done this yet. But if you come in here and say build, parcel build, this is how you bundle it for production. It's smart enough to just switch that automatically to NODE_ENV=production.

[00:04:47] Now if you're on something like web pack or something else. Web pack has a plugin that allows you to set the the environmental variables per type of build and you would just wanna do that. So it's gonna vary by your bundler, that's what I'm gonna say. But suffice to say what I want you to do is I want you to make sure that that's happening with whatever bundle tool you're using.

[00:05:09] But yeah, with Parcel, it just happens for you. It's magic, that's kind of Parcels modus operandi, right is magic.