Introducing VS Code Working Sets 💼

Bernardo Pacheco — Tue, 21 Apr 2020 20:05:43 +0000

Picture this, you're happily coding an awesome feature for your product and you have a few VS Code tabs open specific to that feature. Suddenly, you receive a message, there is a bug in a totally unrelated part of the site and you need to investigate. You start opening new files as you debug the issue, next thing you know you have 37 tabs open. You fixed the bug (nice job!), but now you want to go back to your awesome feature and there's a lot of clutter, you start closing one-by-one the unrelated tabs until your editor is back to the state it was before the bug.

Does that sound familiar? Have you ever been in that situation before? Wouldn't it be nice if you could "save" the files related to your awesome feature, work on your bug, and then come back to your saved files with just a few clicks?

Well, I wrote a VS Code extension that allows you to do just that. I call it Working Sets.

What are Working Sets?

The idea is simple--a way to manage and organize groups of resources--but is not new. Other editors like Eclipse and Facebook's Nuclide offer versions of this concept. The VS Code team has discussed this before too. And although they may offer a baked-in solution in the near future, I still wanted to share my take on it. I've wanted to contribute to open source for a while and I thought this was the perfect opportunity.

How does it work?

In a nutshell, it shows a new sidebar view where you'll have access to all your saved working sets. From there you can create, restore and delete them as well as add/remove files from them. You can find more details on the extension README.

I would love for you to take it for a spin and let me know what you think.

VS Code Working Sets

Cover photo by Russ Ward

Exploring the Broadcast Channel API

Bernardo Pacheco — Thu, 20 Feb 2020 19:59:05 +0000

You know those digital menu boards that you see at quick service restaurants? Well, last year I got to work on one of those.

Ok, but what does that have to do with the Broadcast Channel API?

A little bit of background

In our particular case, the menu board is a React web app running in a Chromebox at the restaurant. It supports two displays and we control which page of the menu it shows based on the URL route.

One of the requirements was that we needed to animate certain elements in the menu, but there was a catch. The animations had to be synchronized across the displays. We couldn't just fire up the animation loop whenever we wanted. We needed a way for the two pages to communicate with each other to start their timers at the same time.

Enter the Broadcast Channel API.

What is the Broadcast Channel API?

It is a Web API that allows basic communication between browsing contexts (i.e. windows, tabs, iframes, webviews) on the same origin.

You start by creating a BroadcastChannel object and giving it a name. If a channel with the same name already exists, it will join the channel instead.

const channel = new BroadcastChannel("channel_name")

To send a message you call the postMessage() method on the created object, which takes any object as an argument.

channel.postMessage("is this thing on?")

This will dispatch a message event to each of the contexts that have joined the channel. We can then run a function for this event with the onmessage event handler.

channel.onmessage = ev => {
  console.log(ev.data)
}
// is this thing on?

To disconnect from the channel you call the close() method on the object.

channel.close()

Back to our app

We were able to leverage this API to communicate back and forth between the two displays and make sure they start their animation loop exactly at the same time. Keep in mind that each display "boots up" independently at slightly different times, so we need some negotiation up front to know when both of them are ready.

The basic logic looks something like this:

/**
 * In this example I will refer to the first display to finish 
 * booting up as "display 1". The second one to be ready will
 * be "display 2".
 */

// display 1 creates the channel; display 2 joins it
const syncChannel = new BroadcastChannel("animation-sync")

syncChannel.onmessage = ({ data }) => {
  switch (data.type) {
    // display 1 receives the "READY" message from display 2
    // and posts a message to start setting things up
    case "READY": {
      syncChannel.postMessage({ type: "START" })
      break
    }
    // display 2 receives the "START" message
    case "START": {
      // record the current time (just to be safe we pad it 5s
      // to allow display 1 to receive the next message)
      const syncTime = new Date().getTime() + 5000

      // outside function that schedules the animations
      scheduleAnimations(syncTime)

      // send "SYNC" message to display 1 with the syncTime      
      syncChannel.postMessage({ type: "SYNC", syncTime })
      break
    }
    // display 1 receives the "SYNC" message with the syncTime
    case "SYNC": {
      scheduleAnimations(data.syncTime)
      break
    }
    default:
      break
  }
}

// display 2 sends the "READY" message to display 1
animationSyncChannel.postMessage({ type: "READY" })

Play with it

I made a simplified demo of this in Codesandbox. And here's a short preview of it:

Pretty cool, right?

Caveat

Not every browser supports this natively. Fortunately, there's a npm package called broadcast-channel that has the same API and uses the native implementation in browsers that support it. Plus, it allows you to use it in Node too!

Cover photo by Prince Abid

Forem: Bernardo Pacheco