DEV Community: Shane Mitchell

How to: Enable JavaScript auto-import suggestions in VS Code

Shane Mitchell — Wed, 09 Mar 2022 00:00:00 +0000

Auto-import problems

If you work on JavaScript projects in VS Code, you’ve almost certainly been frustrated with the hit-or-miss nature of the auto-import suggestions. When you try to import code from elsewhere in your project, the correct suggestion is nowhere to be found.

There are extensions to help with this, but it turns out VS Code now handles this natively – using the jsconfig.json file – and luckily it’s very simple to setup.

Create the `jsconfig.json` file

As of 2018, VS Code treats all JS files as separate from one another. In order to tell it that your files are all part of an Explicit Project , you need to create and configure a jsconfig.json file (this is a descendant of tsconfig.json, which is required for TypeScript projects).

Here’s how:

Create the jsconfig.json file at the root of your project.
(Optional) Configure the compiler options.

Technically an empty file will suffice to tell VS Code this is a project, but you’ll likely want to configure a few things.

There’s a lot of options that can be set, but a few that I like to set for React projects are:

// jsconfig.json at project root

{
  "compilerOptions": {
    "module": "ES6",
    "jsx": "preserve",
    "checkJs": true
  },
  "exclude": ["node_modules", "**/node_modules/*"]
}

See the docs for details and more config settings.

And it works! 👍

Now that VS Code knows to treat all your JS files as an explicit project, auto-import suggestions will populate with all your relevant exported code.

Hope that helps! For more VS Code import tips, see my post on automatic import sorting.

How to: Enable automatic import sorting in VS Code

Shane Mitchell — Wed, 09 Mar 2022 00:00:00 +0000

There’s a VS Code setting that enables automatic organizing of imports on file saves.

It primarily does two things:

sorts imports based on ESLint settings
removes any unused imports

Aside from being a timesaver, this also avoids linting errors (which is especially useful in CI/CD codebases where linting errors will stop a job from completing).

What’s great is you can set it in your user or project settings and forget about it, and it’s only a couple lines.

// settings.json

{
  // put this in your settings object
  "editor.codeActionsOnSave": {
    "source.organizeImports": true,
  },
}

And that’s it! Now when you save, your imports magically sort themselves out!

Next.js Custom Link Attributes

Shane Mitchell — Fri, 07 Jan 2022 16:35:00 +0000

Next.js provides a nifty little Link component, which allows internal linking within your React application without causing a page refresh.

<Link href="/">Home</Link>

While this works great, there are situations where you want to pass additional attributes to your anchor tag, such as aria attributes or custom data attributes.

Since Link is a React component and expects specific props to be passed, you can’t simply pass in the attributes as props to the Link component.

// This doesn't work, the rendered anchor tag ignores
// the additional attribute
<Link href="/" data-name="custom">Home</Link>

Lucky for us, Next provides a simple solution to this:

<Link href="/">
  <a data-name="custom">Home</a>
</Link>

Note: It's important that your href stay as a prop in Link rather than an attribute in the anchor tag.

This renders out to <a href="/" data-name="custom">Home</a> in the DOM and maintains the internal linking speediness we love about Next!

Remote Pair Programming in VS Code

Shane Mitchell — Mon, 26 Apr 2021 00:00:00 +0000

Pair programming – two programmers working together on one workstation at the same time – is easy enough to do when both people are sitting at the same computer. But when attempting to pair program remotely, there is a little bit of setup required to get an effective workspace. Fortunately, if both programmers are using Visual Studio Code, it is easy to setup using a few great extensions – Live Share, Live Server, and Live Share Pomodoro.

Background

As part of the curriculum for The Odin Project, I worked on an assignment to create a Pomodoro Timer application. But the real purpose of the project was to introduce students to pair programming. And seeing that the course is all online, the first step (after finding a partner) was setting up the workspace to replicate in-person pair programming.

I use VS Code, and lucky for me Microsoft has developed the Live Share extension that allows collaborative coding on a hosts local files to all invited participants. This, coupled with a couple other extensions, makes for a very effective pair programming environment, which should be as effective as in-person pairs.

Setup

If you don’t already have VS Code installed, download and install for your operating system.

Important Note: VS Code and the extensions must be installed on both programmers’ computers in order to be used together.

Install Extensions

You’ll need to install two extensions, and one optional extension. Open up VS Code, navigate to the Extensions tab, then search for and install the following (alternatively just open the links and install from the browser):

With these extensions installed, close and reopen VS Code. You’re now ready to start the Live Share server.

Hosting and Collaborating

There’s a few steps to take, but once it’s setup you will be ready to collaborate!

Open VS Code and a new Workspace.
Open the Live Share tab, and click Start collaboration session…
This should create a Live Share server and copy a link to your clipboard. This can now be shared with your programming partner and will allow them to join.
With your index HTML file open, right-click in the editor window and select Open with Live Server.

This will launch a local version of the HTML file in your browser, and also create a shared server that your partner can click to load the file in their browser (look for Live Server in the Shared Server dropdown).

Any changes that are saved to this file will update the browser view for both you and your partner. Pretty rad!

Wrap Up

In only a few minutes you can have a really nice pair programming environment setup for you and your partner(s).

What’s great about this setup is that you can see live code updates as your buddy codes along, and see the HTML page reflect the changes even if the file is not local to your computer! No need to constantly push and pull from GitHub.

I also find the installed Pomodoro Timer extension to be really useful. If you both have this installed, you can start a 25min timer that is great for switching roles between driving and navigating.

There is also built-in voice chat within Live Share, however I have not used that feature. But great to know that it has all the tools you need in one clean package!

An Introduction to REST APIs

Shane Mitchell — Wed, 07 Apr 2021 00:00:00 +0000

The term “REST API” (aka “RESTful API”) is thrown around all the time when talking about web applications. But what exactly does the term REST mean? And why is it important to API design?

There’s a number of guidelines that define REST, but there are a couple of key points that will help to introduce and understand REST APIs.

First, what is an API?

Before getting into what REST is, let’s briefly describe an API.

An API (Application Programming Interface) is a way of communicating with an application and tapping into some of its functionality.

For example, an API can be used to request information (data) from an application, or used to run complex computations on data passed into an API request. The application’s API exposes its functionality as methods, operations, endpoints, etc., and the specific language of the API depends on the application.

Note: in order to use an API, you need to know the functionality available and the format which it expects the request/response to be in.

As an analogy, imagine a vending machine. A customer walks up to the vending machine, sees a bunch of buttons for different sodas, and presses the button for the one they want. The vending machine then does a bunch of stuff behind the scenes and pops out the soda.

The front of the machine is like the API, and the buttons are like available methods of an API. Pressing a button is like calling a method, i.e. requesting something from the application. The machine and the application both perform some magic behind closed doors and respond to the request.

The customer doesn’t really care what happened behind the scenes, they just want a soda. The same is true of one application using another application’s functionality through its API.

In the context of web applications, server APIs are often used to pull data from the server and/or database into the client (or vice versa, sending data from the client to the server). This is where the practice of REST comes into play.

RESTful APIs

REST stands for Representational State Transfer. These three words do a great job of describing the essence of a REST API, but require a little deciphering first.

Put another way, REST defines a standard way for web applications to share information, by transferring a representation of the state of some data.

If we break this down:

Representational State: A snapshot of the data saved in a database, or the data sent from the client. This represents its state at the moment of the transfer.
Transfer: The HTTP requests and responses between the client and the server, which allows standardized operations across the web.

So, an application using a REST API uses HTTP requests/responses to transfer a snapshot of some data.

Using the vending machine analogy, the “buttons” of a REST API are endpoints (i.e. URLs) and HTTP methods, and the “soda” is the representational state of the data.

As an example, a client might make an HTTP “GET” request to a server (using the JavaScript Fetch API here), a little like this:

fetch('some-server.com/api/tacos', {method: 'GET'});

The server would receive this request, do some magic based on what was requested, and respond back with a snapshot of the data at that point in time. Without going into details, the response might look a little like this:

{
  "data":
    "tacos": ["carnitas", "cheese", "carne asada"]
}

The client could then go off and use this data as it pleases, for instance to display a menu of available tacos!

Why is this important for web APIs?

One component of reliable and scalable web applications is separation of concerns. This is where REST guidelines shine.

When the client and server communicate via the REST API, they are sending snapshots which represent the data state at the time of transfer. The data could change one second after the API transfer, but what the client received remains unchanged. In other words, outside of the API call, neither knows anything about the state of the other.

Additionally, different clients can use the API to communicate with the server, and the server will happily perform its functions for them all. And once the client has received its snapshot of the data in response, it doesn’t care what the server does afterwards.

Again, outside of the API, the server and any of its clients are not concerned with each other.

When the client and the server are decoupled from each other like this, the code on either end can change independently of each other, so long as the API remains the same. This allows independent scalability and improved reliability on both sides.

Wrapping up

So there you go, a brief introduction to what REST APIs are and why they are important in web applications.

Key points:

APIs allow communication between clients and a server, in accordance with a defined “language”.
REST APIs adhere to a standard format for transferring information to and from the application.
REST APIs ensure separation of concerns by decoupling the logic of the client/server, instead transferring snapshots of data then carrying on independently.

Named vs. Default Exports in ES6 Modules

Shane Mitchell — Sat, 02 Jan 2021 18:08:54 +0000

JavaScript Modules using ES6 syntax have two different types of exports: named and default.

There are differences in how they are declared as well as how they are imported.

Named Exports

Named exports can be used to export several variables from a module. The export keyword can be used for each variable that you want to export. When importing, you use object destructuring to assign the exported variables. The imported variables must use the same name as the exports.

// foo.js

export const foo = () => {
  console.log("foo");
}

export const bar = 123;

foo.js has two named exports, foo and bar, which can be imported from any other JavaScript file like:

// anotherComponent.js

// import the foo and bar named exports from foo.js
import { foo, bar } from "./foo";

// both variables can now be used
foo(); // logs 'foo' to the console
console.log(bar); // logs the number 123 to the console

Named exports can be used to export and import several variables from a module.
When using named exports, the imported variables must use the same name as the exported variables.
If you want to rename imported variables, you can use the as keyword:

  import { foo as myVariable, bar } from "./foo";

  myVariable(); // logs 'foo' to the console

Default Exports

You can only have one default export in a module. You use the default keyword to specify which variable is the default export. When importing default exports, any name can be used for variable assignment.

// baz.js

const baz = () => {
  console.log("baz");
}

export default baz;

Now that baz.js has defined its default export, any other JavaScript file can import and use the baz variable by importing as so:

// anotherComponent.js

// import the default export from baz.js
import bazDefault from "./baz";

// the imported variable can now be used
bazDefault(); // logs 'baz' to the console

We've successfully imported baz into a variable called bazDefault.

Each module can only have one default export.
You define the default export using the default keyword.
When using default exports, we can choose any name for the variable we import into. I chose bazDefault, but could have just as easily called it baz, someVariable, or apples and it would have been perfectly valid.

Summary

So that's it, the differences between named and default exports in ES6 and how they are used.