I did, until one day, I needed to get into the weeds on a project, and I figured I’d try and set up debugging in hopes of making my life easier. I was delighted to find out how easy it was! In this post, I’ll demonstrate how to debug a React project using VS Code and Chrome.

To demonstrate how to set things up, I’m going to use Vite and React to set up a React project. You’ll need to have VS Code and NPM installed.

Set Up a Workspace in VS Code

First, create a directory for our workspace. Then Open the directory in VS Code. Save the workspace.

I used D:devtrainingdebugging-react.

Create a React Starter Project Using Vite

From VS Code, open up this location in the integrated terminal and run the following command to create a starter project: npm create vite@latest

Follow the prompt from Vite. Give the project a name (I used vite-demo ). Select React for the framework and JavaScript for the variant.

Once that’s all set, change directories into the project folder that you assigned, run npm install.

Once the installation is complete, start Vite by running npm run dev.

We can see that our project is running on localhost, port 5173. A browser window will be opened with the project:

Create and Configure a launch.json File in VS Code

Now we need to create a launch.json file. Click the Debug icon (1), then create a launch.json file (2). The launch.json file will be located in your workspace’s .vscode directory.

Select the location:

Select Chrome for the debugging type:

This will open the launch.json file in a tab. (1) Set the port to whatever was specified by Vite earlier (5173 by default), and (2) add the subdirectory your project is into the webRoot option if you have your project in a subdirectory like I do here (/vite-demo).

Add a Breakpoint to the Code

Now open up your project’s src/App.jsxfile (1) and (2) add a breakpoint to line 20. We’re going to debug the count variable.

Start Debugging Your React Project!

OK, we’re getting close! Now click the Start button to start debugging. This will launch our app in a new Chrome window.

The app is paused for debugging.

A debugging session is now active in VS Code. We can use the debugging control bar to step through and inspect the code.

We can interact with the app and see the value of the counter increase after clicking the count button.

Here’s a quick screen capture showing this in action:

One thing to note is that, by default, React.StrictMode is enabled in dev mode, so your app will be run twice. See the docs for details on Strict Mode.

That’s all there is to setting up basic React debugging in VS Code and Chrome. I hope this helps you to more efficiently debug your React projects.

Are you struggling with WordPress security? Our free guide teaches you everything you need to know to protect your site. Download and read our “Guide to WordPress Security” to safeguard your website.

The post Debugging React with VS Code and Chrome appeared first on WebDevStudios.

We are saying goodbye to an old friend: the .dev top-level domain.

Feel free to let that one play while you read on…

What has changed? Well, to start Google bought the .dev top-level domain (TLD). Chrome 63 is the first release that forces HTTPS on .dev domains. So when you go to http://mysite.dev in Chrome 63 and get redirected to https://mysite.dev without any interaction with the server, you’ll know why.

In actuality, you can still use .dev in Chrome, but you need to enable HTTPS for it. You may also need to address any mixed-content errors—trying to load assets like CSS or JavaScript over HTTP when the site is HTTPS. These are good practices anyway, but you may not have planned on fixing that today.

If you’re working on a site that is specifically not HTTPS in production, you want to test as HTTP to make sure everything is 100%.

If you just want to get things done today, close Chrome and use Firefox, Safari, Opera or even Internet Explorer until you can change the top-level domain away from .dev.

Alternatives

Unbeknownst to all of the clever developers using .dev for development, the friendly folks over at the Internet Society hashed this out almost 20 years ago:

   To safely satisfy these needs, four domain names are reserved as
   listed and described below.

                   .test
                .example
                .invalid
              .localhost

      ".test" is recommended for use in testing of current or new DNS
      related code.

      ".example" is recommended for use in documentation or as examples.

      ".invalid" is intended for use in online construction of domain
      names that are sure to be invalid and which it is obvious at a
      glance are invalid.

      The ".localhost" TLD has traditionally been statically defined in
      host DNS implementations as having an A record pointing to the
      loop back IP address and is reserved for such use.  Any other use
      would conflict with widely deployed code which assumes this use.

Others have considered using some alternates in the face of the disruption Chrome 63 caused:

Since Google royally screwed us by snatching up .dev, let me propose a few other relevant local TLD options:

— (@JJJ) December 7, 2017

At WebDevStudios, we did a simple poll of the recommended IETF names and wound up with .test (mostly because it’s the shortest to type).

Why Standardize?

There are several reasons to standardize. When working with teams, configuration data is shared. It’s much easier to be able to transfer database data without reconfiguration.

Also, when working on client sites, if you have licensed software from Gravity Forms, Easy Digital Downloads, etc. their license/activation is based on a domain. If you standardize, only one development domain is used per project.

It’s really not a big deal to switch it up. Things will be okay. We promise. You don’t have to switch all of your development sites at once. Just switch them as needed. After you’re done, you might be asking why you didn’t start using .test back in 1999.

The post Google Chrome 63: Goodbye .dev, Hello .test appeared first on WebDevStudios.