DEV Community: Diego Coy

Asynchrony in JavaScript: A Brief Look Back

Diego Coy — Mon, 29 Apr 2024 20:52:49 +0000

It is the year 2024. AI has taken over the world (sort of), I shifted my focus from the web platform to Cloud Technologies and AI, but I had to come back for another round to talk about a topic I see new web devs struggling even today: asynchrony.

Many words have been put together one in front of the other by many acclaimed experts, but still, I want to share my side of the story. So let me take you back in time to 2010, an age when developer tooling for JavaScript was basically non-existing, IDE auto-completion was not a thing, and you had to carefully consider the performance impact of CSS border-radius and box-shadow, the good ol’ days.

But before diving in, why is asynchrony something we even need to consider? It so happens that JavaScript is single-threaded (I’m intentionally avoiding talking about workers here to keep things simple), meaning that it can only do one thing at a time. You may be thinking “Hmm that doesn’t sound like what I see every day. I can do many things at once: clicking here, handling events there, making requests, and updating the DOM all at the same time”, and yes, that might look like everything is being executed all at once, however, that’s not the case, it’s all part of a really efficient event loop. If you want to learn more, here’s a talk from Jake Archibald that I consider to be the best follow-up to Philip Robert’s talk on the event loop. So yep, we need to start tasks off and then have the ability to let the event loop do its thing until our results are ready.

Making an HTTP request

Nowadays you probably use a framework that abstracts away the complexity behind sending an HTTP request to a server, and to be honest, we sometimes did the same when using libraries such as jQuery, Backbone.js, or MooTools. However, from time to time we had to use plain vanilla JavaScript to communicate with a server, which meant using XMLHttpRequest directly.

XMLHttpRequest, allowed us to handle server requests asynchronously without requiring a page reload (you may have heard of AJAX or Asynchronous JavaScript, this is where the term comes from). This approach was fundamental in allowing background data loading without interrupting the user experience, however, even though XMLHttpRequest was available since Internet Explorer 7 (let’s not talk about the times before that and ActiveXObject), it wasn’t widely used ¯\(ツ)/¯. In any case, here’s how you’d make a GET request to https://example.com/api/v1/plants

var xhr = new XMLHttpRequest();
xhr.open("GET", "https://example.com/api/v1/plants");

xhr.onreadystatechange = function () {
    if (xhr.readyState === 4 && xhr.status === 200) {
        console.log(xhr.responseText);
    }
};

xhr.send();

The first line creates a new XMLHttpRequest object that is then prepared by specifying the method to be used, and the URL.

After that, a callback function is created where the readyState of the client is checked (4 means the client is good to go) along with the server response. If those conditions are met, then you can check the responseText and do something with the data you just got from the server without having to reload the page, pretty neat, right? Well, it was back then.

Oh, but what about the last line there? Well, the “ready state change “listener will only listen after the send method is invoked, so this part here is crucial and is the one I must admit I forgot to include more than once.

Callbacks and Drawbacks

The example we just saw up there is a bit basic, but serves as the building blocks of an actual “server request” function we can include in our code to reuse later on. To do so, we will make use of callbacks, which have been a fundamental feature of JavaScript since its very beginnings. In JavaScript, functions can be passed as arguments to other functions, a feature leveraged extensively when handling asynchronous tasks.

Here’s our XMLHttpRequest code packed into a single function we can call from different parts of our app:

function serverRequest(url, method, body, callback) {
  var xhr = new XMLHttpRequest();
  xhr.open(method, url);
  xhr.onreadystatechange = function() {
      if (xhr.readyState === 4 && xhr.status === 200) {
          callback(null, xhr.responseText);
      } else if (xhr.readyState === 4) {
          callback(new Error("Request failed"));
      }
  };
  if (body) {
    xhr.setRequestHeader('Content-Type', 'application/json')
    xhr.send(JSON.stringify(body));
  } else {
    xhr.send();
  }
}

The XMLHttpRequest logic is abstracted away into a function we called serverRequest. This function will take in the URL we want to interact with, the method to use, the body (if we’re sending a POST or PUT request), and finally, a callback function that will be invoked whenever the onreadystatechange listener gets either a response or an error.

This serverRequest abstraction is called like this:

function responseHandler(err, data) {
  if (err) {
      console.error(err);
  } else {
    console.log(':\n', data);
  }
}

serverRequest("https://example.com/api/v1/plant", “GET”, undefined, responseHandler);

Here we created a simple responseHandler function to take care of whatever the serverRequest function returns, but in a real world scenario, you’d call different handlers for different types of requests. You oftentimes chained these callback functions when you wanted to make subsequent requests, for instance, based on the response you received, which would eventually lead to what we knew as the “callback hell”.

The “callback hell”

Also known as "the pyramid of doom," is the term used to refer to multiple nested callbacks, which lead to deeply indented code that is a headache to read and debug.

Example of Callback Hell

serverRequest("https://example.com/api/v1/plants/1", "GET", undefined, function(err, data1) {
    if (err) {
        console.error(err);
    } else {
        var dataSheetPage = data1.data_sheet_page;
        serverRequest("https://example2.com/api/v1/data-sheets/" + dataSheetPage, "GET", undefined, function(err, data2) {
            if (err) {
                console.error(err);
            } else {
                  var plantId = data1.plantId;
                var isEdible = data2.isEdible;
                var recipe = data2.recipe;
                serverRequest("https://example3.com/api/v1/recipes/", "POST", {"plantId": plantId, "isEdible": isEdible, "recipe": recipe}, function(err, data3) {
                    if (err) {
                        console.error(err);
                    } else {
                        console.log("Recipes API Response: ", data3);
                    }
                });
            }
        });
    }
});

Despite their drawbacks, callbacks were the go-to solution for handling asynchronous operations in JavaScript for a long time because there was basically no better way of providing a method to handle asynchronous events and operations. You could avoid the “pyramid of doom” shape by using named functions (like when we used responseHandler), but the complexity was still there. Their limitations became more apparent as applications grew in complexity, leading to the adoption of more robust solutions with structured control flows and error handling capabilities. This transition marks a significant evolution in JavaScript programming practices, aiming for greater readability, maintainability, and efficiency in managing asynchronous code.

From Callbacks to Promises

The idea of representing something that hasn’t been completed yet (successfully or otherwise) in JavaScript had existed for a long time before the official ECMAScript Language Specification was completed. There were many libraries that aimed to achieve this goal, however, the fact that there were different kinds of implementations to represent a Promise, meant that interoperability between libraries that used different approaches was a headache. Fortunately, Promises were finally introduced officially as part of the language in ES6, back in 2015.

Having a standard meant that we could all use the same syntax and terminology when handling async processes.

function serverRequest(url) {
    return new Promise((resolve, reject) => {
        fetch(url => {
            const result = false // Simplification: here you'd bring your data from somewhere / perform an actual task to obtain it
            if (result) {
                resolve("Success")
            } else {
                reject("Failure")
            }
        }, 1000)
    })
}

serverRequest(url)
    .then(successMessage => {
        // Do something on success
        console.log(successMessage)
    })
    .catch(errorMessage => {
        // Handle error
        console.error(errorMessage)
    })
    .finally(() => {
        // Do something after the async process has completed, either fulfilled or rejected
        console.log('Async task perfomed.');
    })

Promises significantly improved the readability of async operations, their error handling processes, and lifecycle operations. Here the the Promise’s resolve callback passes the result of the async operation, which will be captured by the then method later on, and on the other hand, the reject callback function being called will make the catch run, allowing you to define the specific logic for both cases in a separate context. The finally method is called regardless of which of the Promise callbacks is executed, allowing you to perform operations that would happen after the async task is completed, such as updating the UI.

Continuing with our previous set of examples around HTTP requests, let’s move forward into the future to an era where the global fetch method is present in all JavaScript engines and use the promises it returns along with the then, catch, and finally methods we just saw:

function serverRequest(url, method, body) {
    return fetch(url, {
        method: method,
        body: JSON.stringify(body),
        headers: {"Content-Type": "application/json"}
    })
    .then(response => {
        if (!response.ok) {
            return response.json().catch(errorData => {
                throw new Error(`Server responded with status ${response.status}: ${JSON.stringify(errorData)}`);
            });
        }
        return response.json();
    });
}

serverRequest("https://example.com/api/v1/plants/1", "GET")
    .then(successMessage => {
        // Do something on success
        console.log(successMessage)
    })
    .catch(errorMessage => {
        // Handle error
        console.error(errorMessage)
    })
    .finally(() => {
        // Do something after the async process has completed, either fulfilled or rejected
        console.log('Async task perfomed.');
    })

This is definitely better, compared to the first code snippet up top. The readability improved quite a lot but can be even better, as you will see in the next section.

Promises came along with several methods that greatly improved the developer experience when handling several async operations at the same time, such as Promise.all which takes in an iterable (let’s say an array) of Promises. If all of the Promises are fulfilled, then a new Promise is created with the aggregate values. If at least one of them fails, the whole async operation is considered to fail and the catch method will be invoked. Other useful methods are Promise.race, Promise.any, or Promise.allSettled, and you can check them out over MDN.

A new era: Async/Await

Building on promises, async/await was introduced as a method to simplify the way we write asynchronous JavaScript code. The async and await operators were first released in 2016 with Chrome 55.

These new operators allow us to write code that handles async operations more straightforwardly. Let’s check out an example, and what better way to talk about a modern operator than upgrading our initial XMLHttpRequest example code to the current standard, fetch, and a few other “modern” JavaScript additions:

async function serverRequest(url, method, body) {
    const response = await fetch(url, {
        method: method,
        body: JSON.stringify(body),
        headers: new Headers({"Content-Type": "application/json"})
    });
    const data = await response.json()
    return data
}

This approach reduces the boilerplate associated with promise chains and improves the legibility and maintainability of the code. But the best part comes when we compare the “pyramid of doom” with its modern counterpart:

async function pushRecipe() {
    const plantData = await serverRequest("https://example1.com/api/v1/plants/1", "GET")
    const dataSheet = await serverRequest(`https://example2.com/api/v1/data-sheets/${plantData.data_sheet_page}`, "GET")
    const recipes = await serverRequest("https://example3.com/api/v1/recipes", "POST", {"plantId": plantData.id, "isEdible": dataSheet.isEdible, "recipe": dataSheet.recipe})
    console.log(recipes)
}
pushRecipe()

But what’s actually going on here, you may be wondering? Back in the day, we may have referred to async/await as syntactic sugar, meaning it was only an abstraction of the existing Promise methods – even though it brings more than that to the table, it is a good way to think about it to get started. The async operator is used to “tag” a function as asynchronous, allowing us to then use the await operator inside of it to resolve a promise and assign its result automatically. This means we don’t need to use the Promise’s then method to return a value, that is done for us and we can simply focus on capturing that value, like in the definition of the response inside the serverRequest function:

    const response = await fetch(url, {
        // …

Or when assigning the server’s response to an API call:

    // …
    const plantData = await serverRequest("https://example1.com/api/v1/plants/1", "GET")
    // …

What about error handling?

Well, there’s a statement that’s been there from the very first days of the JavaScript language that we can use: try…catch. Wrapping our calls to serverRequest would capture the errors and let you handle them with as much detail as you prefer:

async function pushRecipe() {
    try {
        const plantData = await serverRequest("https://example1.com/api/v1/plants/1", "GET")
        const dataSheet = await serverRequest(`https://example2.com/api/v1/data-sheets/${plantData.data_sheet_page}`, "GET")
        const recipes = await serverRequest("https://example3.com/api/v1/recipes", "POST", {"plantId": plantData.id, "isEdible": dataSheet.isEdible, "recipe": dataSheet.recipe});
        console.log(recipes);
    } catch(err) {
        console.error(err);
    }
}

Conclusion

The evolution of asynchrony in JavaScript, from basic event handling like XMLHttpRequest to the more sophisticated async/await syntax, demonstrates a clear trajectory toward improving developer experience and code efficiency. Each stage in this evolution has aimed to mitigate the challenges posed by its predecessors, leading to easier-to-understand, more robust code management. This progression not only makes the language more accessible but also enhances its capability to handle the complex requirements of modern web applications, making the statement “always bet on the web” an indisputable truth.

Where to go from here?

The world is your canvas! Go ahead and create your masterpiece! But if you ask me, AbortController is a pretty cool technology people should be taking advantage of. It allows you to abort HTTP requests (and this is HUGE, we couldn’t do that in the old times!) when a signal is fired, helping you use your resources wisely and further improving your user’s experience. Let me know in the comments if you want me to write a piece on that topic :D

The amazing powers of the web: Web Serial API

Diego Coy — Thu, 09 Apr 2020 19:07:20 +0000

The Web Serial API

The Web Serial API allows us to interact with serial devices by sending and receiving data from within a web browser.

Using this API we can select and connect to a serial device, and then send and receive messages in just a couple of lines of JavaScript code.

As you can imagine, this is API is only supported by modern Chromium based desktop browsers right now (April 2020) but hopefully support will improve in the near future. At this moment you need to enable your browser's Experimental Web Platform Features, just copy and paste the right URL:

chrome://flags/#enable-experimental-web-platform-features
opera://flags/#enable-experimental-web-platform-features
edge://flags/#enable-experimental-web-platform-features

Why?

Why not? This API brings one more capability to the more widespread platform, the web. Having access to physical devices will make it easier for people with web development knowledge to start diving into the waters of the IoT movement by interfacing with it through the browser, a familiar platform for them.

So dust off that Arduino you may have laying around, connect it to your computer and let's begin connecting the web and the physical world.

How?

Connection

After validating if serial is supported by the browser, we use the requestPort method to prompt the user with a Browser provided UI displaying a list of available serial devices.

We then open a port to connect with that device. Here the baudRate needs to match the baud rate used by the device. The expected baud rate values are:

115200, 57600, 38400, 19200, 9600, 4800, 2400, 1800, 1200, 600, 300, 200, 150, 134, 110, 75, 50

Using the readable ReadableStream and writable WriteableStream properties that we get from the port we create a reader and a writer.

if ('serial' in navigator) {
  try {
    const port = await navigator.serial.requestPort();
    await port.open({ baudRate: 9600 });
    this.reader = port.readable.getReader();
    this.writer = port.writable.getWriter();
  }
  catch (err) {
    console.error('There was an error opening the serial port:', err);
  }
}
else {
  console.error('The Web serial API doesn\'t seem to be enabled in your browser.');
}

Here we're storing both the reader and the writer objects globally for later use.

Reading and Writing

The data that is transferred between the browser and the device is encoded, so we need to create an encoder to use when sending a message and a decoder to be able to properly read a message.

constructor() {
  this.encoder = new TextEncoder();
  this.decoder = new TextDecoder();
}

Writing

Writing data, or sending a message, is really easy. First we take the message we wish to send and encode it, then using the write method of the global writer object we previously created.

async write(data) {
  const dataArrayBuffer = this.encoder.encode(data);
  return await this.writer.write(dataArrayBuffer);
}

The write method returns a promise that we can use to validate the completion of the write process.

Reading

The reading process is actually similar to the write one, using the reader's read method we get the data that's coming from the device and pass it to the decorder's decode method.

async read() {
  try {
    const readerData = await this.reader.read();
    return this.decoder.decode(readerData.value);
  }
  catch (err) {
    const errorMessage = `error reading data: ${err}`;
    console.error(errorMessage);
    return errorMessage;
  }
}

Here we can catch any reading error and do something with it.

That's it! that's the basic setup of a Web Serial API handler.

Examples

The basic example uses a regular Arduino without any additional hardware. When sending a 1 as a message the Arduino's onboard LED will light up, when sending 0 it'll turn off.

The "advanced" example keeps the same Web Serial API handler code, it just adds some extra bits to the client side code. It also expects the user to have a MAX7219 controlled 8x8 LED matrix, a really affordable and easy to get LED matrix.

Origin Trial

Update: Web Serial API is promoted to stable from Chrome 89. This means that an Origin Trial token is not required anymore.

Origin trials enable us to ship experimental features without having our users enable flags in their browsers. Check out more here: https://github.com/GoogleChrome/OriginTrials and here https://developers.chrome.com/origintrials/

Browser support

Chrome
- Experimental: 80+
- Stable: 89+
Edge (Chromium based)
Opera (you need to enable it's flag in opera://flags/#enable-experimental-web-platform-features)

Next steps

Chromium + Web Serial API + Raspberry Pi == Awesomeness 🔥

Connecting the musical world to the Web using the Web MIDI API

Diego Coy — Wed, 08 Apr 2020 13:27:15 +0000

Web MIDI

MIDI is a protocol that electronic musical instruments, controllers and computers (and now browsers) use to communicate with each other.

Web MIDI API supports the MIDI protocol and has been available since Chrome 43. It should be made clear that this API is not related with the playback of the MIDI/SMF files. It allows us instead to handle MIDI devices's input and output interfaces to send and receive messages through our web applications.

The messages

A MIDI message typically comprises a command or action that specifies what the interaction represents: pressing or releasing a key. Then we have the value of the note, and finally we have the velocity which represents how hard did you press a key, this can be interpreted as a higher volume the harder the key is pressed.

These three values are received by the browser as an array:

  // command, note, velocity
  [144, 119, 127]

144 is the command, this one specifically means "note on". After you release the key, a new message will be fired with a command value of 128, this is the "note off" command.
119 is the note number
127 is the speed, it ranges from 0 to 127

Web MIDI API

I'll be creating an app that can make two different MIDI devices interact with each other and the browser.

Getting MIDI access

Here I'm creating a class that will call an async init function that will first check if navigator.requestMIDIAccess() can be executed, if not, will call it a day by invoking onMIDIFailure to log a message to the user to let them know their browser can't handle Web MIDI. If it is however supported, a MIDIAccess object will be passed to the onMIDISuccess success callback.

class WebMidiDemo {
  constructor() {
    this.init();
  }
  async init() {
    try {
      const midiAccess = await navigator.requestMIDIAccess();
      this.onMIDISuccess(midiAccess);
    }
    catch (err) {
      this.onMIDIFailure(err);
    }
  }
  // ...
  onMIDIFailure(err) {
    console.log(`Failed to get MIDI access - ${err}`);
  }
  // ...

Listing MIDI devices

The first thing I'm doing in this specific example is storing the detected MIDI input and output devices list for later use.

After that I'm using a separate class I created to handle the creation of a couple of <select> elements so the user can pick the devices. I'm passing a callback function, onMidiInputPortSelected and onMidiOutputPortSelected for each to handle the onchange event of the <select>. If you're curious about .bind(this), take a look at this article.

onMIDISuccess(midiAccess) {
  this.inputDevicesList = midiAccess.inputs;
  this.outputDevicesList = midiAccess.outputs;

  // uiStuff is a custom class I created to handle UI Stuff, it has NOTHING to do with the Web MIDI API. I just wanted to keep things separate
  uiStuff.createSelect(midiAccess.inputs.values(), this.onMidiInputPortSelected.bind(this), '<Select an Input device>');
  uiStuff.createSelect(midiAccess.outputs.values(), this.onMidiOutputPortSelected.bind(this), '<Select an Output device>');
}

Attaching callbacks

Notice how I close any previous selected device port, however it's possible to skip this step and have multiple ports open at the same time.

Now it's time to use the previously stored devicesList. Since it is Map like, I can use Map's get method to query it and bring the MIDI device with the ID that matches the selection.

After creating a reference for both the selected input and output device, I can attach a callback to the onmidimessage, which we will cover next.

onMidiInputPortSelected(selection) {
  if (this.selectedInputDevice) {
    this.selectedInputDevice.close();
  }

  const selectedInputDeviceId = selection.target.value;

  this.selectedInputDevice = this.inputDevicesList.get(selectedInputDeviceId);
  this.selectedInputDevice.onmidimessage = this.handleMIDIMessage.bind(this);
  console.log('Input port', selectedInputDeviceId);
}

onMidiOutputPortSelected(selection) {
  if (this.selectedOutputDevice) {
    this.selectedOutputDevice.close();
  }

  const selectedOutputDeviceId = selection.target.value;

  this.selectedOutputDevice = this.outputDevicesList.get(selectedOutputDeviceId);
  console.log('Output port', selectedOutputDeviceId);
}

Receiving and Sending messages

Every time there's an incoming MIDI message from the selected input device, the handleMIDIMessage is executed. The event is a MIDIMessageEvent, it has a data property which is a Unit8Array containing the command, note, and velocity.

With the power of destructuring I extract the array values as individual variables and then:

Log the message properties to the console
Verify that the incoming message is a note on command
Change the body's background color, because I couldn't think of anything cooler than that ¯\(ツ)/¯
Send back that same command and note to the selected output device

handleMIDIMessage(event) {
  const [command, note, velocity] = event.data;
  console.log([command, note, velocity]);

  if(command === 144) {
    // a method to change the body's background color on each key press, not related to Web MIDI
    uiStuff.changeBackgroundColor(note);

    if(this.selectedOutputDevice) {
      this.selectedOutputDevice.send([command, note, 10]);
    }

  }
}

You may have noticed that I'm passing a static 10 as the velocity for every message. It turns out that when you send a 144 command and a 10 as the value for the velocity to the MIDI Launchpad that I have, it makes the key associated with that note light red. Different values will trigger different colors, but those are defined by the vendor, so your device may differ.

The code

Check out the repo https://github.com/UnJavaScripter/web-midi-basics

You will notice that I used TypeScript, if you use it I recommend you install @types/webmidi. Afterwards you can use it by calling WebMidi.**thing**.

If for some reason you don't like TypeScript, that's Okay too. I made TypeScript compile to ES2017 so you can check the JavaScript code without any weird additions.

The demo

Here: https://unjavascripter-web-midi-basics.glitch.me/

Browser Support

You can use the Web MIDI API in Chromium based browsers: https://caniuse.com/#search=web%20midi%20api

Things to read

You should definitely go over the W3C draft for the Web MIDI API https://webaudio.github.io/web-midi-api/

Dibujando con canvas - Manejo de historial

Diego Coy — Mon, 06 Apr 2020 17:48:13 +0000

Manejando historia

Es momento de agregar history management a nuestra app. Vamos a mantener un registro de los pixeles dibujados en el canvas.

Objetivo

Agregar las acciones que se realicen sobre el canvas a una pila, el historial
Remover elementos del historial para deshacer
Crear un historial temporal para poder rehacer
Asociar las acciones deshacer y rehacer a botones

Demo

Aquí: https://codepen.io/UnJavaScripter/pen/QWbeEpw

El código

PixelProp

Como vamos a necesitar referenciar cada pixel que se ha pintado, vamos a usar las interfaces de TypeScript para crear un tipo específico a nuestro caso particular.

Creamos un archivo llamado types.ts dentro de /src y dentro ponemos las propiedades que tiene todo pixel:

interface PixelProp {
  x: number;
  y: number;
  color: string;
  empty?: boolean;
}

HistoryHandler

Vamos al código para manejar el historial. Creamos un nuevo archivo llamado history-handler.ts dentro de /src con:

class HistoryHandler {
  private _history: PixelProp[] = [];
  private historyRedo: PixelProp[] = [];

  get history() {
    return this._history;
  }

  push(pixel: PixelProp) {
    if(this.historyRedo.length) {
      this.historyRedo = [];
    }
    this._history = this._history.concat(pixel);
  }

  clear() {
    this._history = [];
  }

  undo() {
    const historySize = this._history.length;
    if(historySize) {
      const lastHistoryElem = <PixelProp>this._history[historySize - 1];
      this.historyRedo = [...this.historyRedo, lastHistoryElem];
      this._history.pop();
    }
  }

  redo() {
    const historyRedoSize = this.historyRedo.length;
    if(historyRedoSize) {
      const lastHistoryRedoElem = <PixelProp>this.historyRedo[historyRedoSize - 1];
      this._history = [...this._history, lastHistoryRedoElem];
      this.historyRedo.pop();
    }
  }
}

export const historyHandler = new HistoryHandler();

¿historyRedo?

Cuando deshacemos una acción, queremos mantenerla en un lugar de forma temporal por si cambiamos de opinión y decidimos rehacerla. Por eso tenemos dos arrays.

Conectando

import { historyHandler } from './history-handler.js';

class PixelPaint {
  // ...
  undoBtn: HTMLButtonElement;
  redoBtn: HTMLButtonElement;
  pixelSize: number;
  lastDrawnPixel: PixelProp | undefined;

  constructor() {
    this.undoBtn = <HTMLButtonElement>document.getElementById('undo-btn');
    this.redoBtn = <HTMLButtonElement>document.getElementById('redo-btn');
    // ...
    this.undoBtn.addEventListener('pointerdown', (event: PointerEvent) => {
      this.undo();
    });

    this.redoBtn.addEventListener('pointerdown', (event: PointerEvent) => {
      this.redo();
    });
    // ...
  }

  // ...

  private drawPixel(x: number, y: number, color = "#CACA00", skipHistory?: boolean) {
    if(this.lastDrawnPixel?.x === x && this.lastDrawnPixel?.y === y) {
      return;
    }
    const pixelToDraw = {x,y,color};

    if(!skipHistory) {
      historyHandler.push(pixelToDraw);
    }

    this.lastDrawnPixel = pixelToDraw;

    this.ctx.fillStyle = color;
    this.ctx.fillRect(x * this.pixelSize, y * this.pixelSize, this.pixelSize, this.pixelSize);
  }

  private reDrawPixelsFromHistory() {
    this.ctx.clearRect(0, 0, this.canvasElem.width, this.canvasElem.height);
    this.drawGrid();
    historyHandler.history.forEach((pixel: PixelProp) => {
      if(pixel.empty) {
        return;
      }
      this.lastDrawnPixel = undefined;
      this.drawPixel(pixel.x, pixel.y, pixel.color, true);
    });
  }

  undo() {
    historyHandler.undo();
    this.reDrawPixelsFromHistory();
  }

  redo() {
    historyHandler.redo();
    this.reDrawPixelsFromHistory();
  }
}

¿Qué está pasando ahí?

Guardamos una referencia al último pixel pintado con lastDrawnPixel, esta nos servirá para evitar registros no intencionales sobre la misma posición. También nos servirá más adelante para cuando creemos la funcionalidad de borrar.

Agregamos el parámetro skipHistory a drawPixel para saber si queremos guardar esa acción en el historial o no.

reDrawPixelsFromHistory borra el canvas por completo y a continuación dibuja la grilla y en seguida cada elemento que se encuentre en la historia (que no haya sido marcado como empty).

Al final tenemos los handlers par manejar el historial. Estos son invocados a través de los botones que definimos antes. Cada uno invoca a la función de historyHandler correspondiente y procede a "re pintar" todo.

Finalmente tenemos el index.html que incluye los botones de deshacer y rehacer junto con algunos estilos.

<!-- ... -->
  <style>
    body {
      margin: 0;
      background-color: #464655;
    }
    canvas {
      touch-action: none;
    }
    .controls-container {
      display: flex;
      justify-content: center;
    }
    button {
      margin: 0.5rem 0.3rem;
      padding: 0.5rem 0.7rem;
      background-color: #262635;
      color: #eef;
      border: none;
      font-size: 1rem;
    }
  </style>
<!-- ... -->
<body>
  <canvas id="canvas"></canvas>
    <div class="controls-container">
      <button id="undo-btn">Undo</button>
      <button id="redo-btn">Redo</button>
    </div>
  <script src="dist/app.js" type="module"></script>
</body>
<!-- ... -->

¡Y listo!

Y listo.

Dibujando con canvas: trazados

Diego Coy — Sat, 14 Mar 2020 16:52:57 +0000

Trazados en el canvas

La aplicación que creamos previamente es capaz de dibujar un pixel del tamaño configurado al hacer clic sobre cualquier parte del canvas. Pero todavía no se siente tan natural. Vamos a hacer que el usuario pueda hacer trazados.

Objetivo

Cuando el usuario hace clic (izquierdo) sobre el canvas se debe dibujar un pixel
Si el usuario mueve el cursor hacia un pixel vacío adyacente
Y si el usuario mantiene el botón de clic presionado
Se debe dibujar un pixel

Ya tenemos las reglas de lo que debe pasar.

Mouse events vs. Pointer events

Los días de sólo pensar en un mouse como único dispositivo de interacción quedaron atrás. Como bien sabemos, ahora también tenemos que pensar en dispositivos táctiles y su comportamiento. Afortunadamente tenemos pointer events que capturan interacciones tanto del clásico mouse como eventos touch, así que podemos pasar tranquilamente de eventos mousedown o mouseover a pointerdown o pointerover.

El código

En la primera iteración de la aplicación agregamos un Event Listener al canvas para capturar el evento de clic. Vamos a reemplazar ese evento con el pointer event pointerdown:

this.canvasElem.addEventListener('pointerdown', (event: PointerEvent) => {
// ...

Es importante notar que ya no estamos recibiendo un evento de click en el callback, sino un evento de pointer; por esta razón cambiamos el tipo del evento a PointerEvent.

También es necesario cambiar la función que se ejecuta en el callback, se llama handleClick y pues... ya no son sólo clicks:

handlePointerDown(event: PointerEvent){
 // ...
}

Ahora sí podemos crear el handler para el evento de arrastrar justo después del evento para capturar el pointer down:

this.canvasElem.addEventListener('pointermove', (event: PointerEvent) => {
 this.handleDrag(event);
});

La función handleDrag validará si el equivalente al botón derecho se encuentra presionado a la hora de mover el pointer sobre el canvas, si es así, la función que dibuja un pixel se llama:

handleDrag(event: PointerEvent) {
 if(event.buttons === 1) {
   this.drawPixel(event.x, event.y);
 }
}

Aquí encuentras más información acerca del uso de event.buttons para determinar el botón presionado.

Finalmente, agregamos un par de estilos a index.html para que se vea un poco mejor (margin) poder interactuar tranquilamente con el canvas desde dispositivos touch:

<style>
 body {
   margin: 0;
 }
 canvas {
   touch-action: none;
 }
</style>

!Y listo¡

Ya podemos dibujar tranquilamente, pero como todavía no somos perfectos, seguramente tendremos que deshacer algun paso de nuestra expresión artística en algún momento. Trabajemos en eso en el siguiente post.

¿Y el repo?

Aquí está https://github.com/UnJavaScripter/pixel-paint

¿Y el demo?

Aquí https://unjavascripter.github.io/pixel-paint/

Dibujando pixeles en el navegador con Canvas... Y cosas extra

Diego Coy — Sun, 23 Feb 2020 18:15:50 +0000

Objetivo

Crear una aplicación web para dibujar “pixel art” usando las últimas tecnologías disponibles para navegadores modernos.

Demo

https://codepen.io/UnJavaScripter/pen/BaNpBae

El HTML básico se ve así:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Pixel Paint</title>
</head>
<body>
  <canvas id="canvas"></canvas>
  <script src="dist/app.js"></script>
</body>
</html>

El archivo app.js está dentro de la carpeta dist porque usaré TypeScript y definí este como el destino para los archivos transpilados (convertidos de vuelta a el JS de toda la vida).

Para instalar TypeScrip podemos usar NPM:

npm i -g typescript

Para crear un nuevo archivo de configuración de TypeScript usamos:
tsc --init

Dentro del archivo tsconfig.json que se acaba de crear, vamos a "descomentar" la propiedad "outDir" y le ponemos como valor "./dist" (la que definí al llamar el script en mi HTML), si quieres, si no, cualquier otro está bien. "Descomentamos" también la propiedad rootDir y le ponemos como valor cualquier nombre de carpeta que se nos ocurra, por ejemplo src ¯_(ツ)_/¯.

Un par de cosas más, la propiedad target de tsconfig.json debe tener como valor al menos es2015, con esta configuración, el compilador nos habilitará el uso de funcionalidades "modernas" (¿de hace 5 años?). Así mismo, module debe ser igual a es2015.

¡Ahora sí podemos crear la carpeta src y dentro de ella nuestro archivo app.ts!

En una terminal vamos a poner a correr:
tsc -w

Para que el compilador de TypeScript esté pendiente de cualquier cambio y automáticamente genere archivos con extensión js en la carpeta que definimos como "outDir".

Ahora sí a programar

Creamos una clase porque queremos practicar como es eso de las clases en JavaScript que ya se pueden usar desde ES6 (año 2015):

class PixelPaint {
  canvasElem: HTMLCanvasElement;
  ctx: CanvasRenderingContext2D;

  constructor() {
    this.canvasElem = <HTMLCanvasElement>document.getElementById('canvas');
    this.ctx = <CanvasRenderingContext2D>this.canvasElem.getContext('2d');
  }
}

Los <* tipo *> son para decirle a TypeScript "no me creas pendejo, no va a ser null. TU relajate y compila".

Ya tenemos nuestro context, ahora podemos empezar a dibujar en el canvas.

Grilla/Cuadricula

Empecemos por definir el tamaño del canvas y del los pixeles que vamos a usar:

class PixelPaint {
  canvasElem: HTMLCanvasElement;
  ctx: CanvasRenderingContext2D;
  pixelSize: number;

  constructor() {
    this.canvasElem = <HTMLCanvasElement>document.getElementById('canvas');
    this.ctx = <CanvasRenderingContext2D>this.canvasElem.getContext('2d');
    this.canvasElem.width = window.innerWidth;
    this.canvasElem.height = window.innerHeight;
    this.pixelSize: 50; // <-- Idealmente sería dinámico
  }
}

Estamos usando el tamaño del viewport como el tamaño total del canvas, y 50 como un número cualquiera para el tamaño de cada pixel.

Ahora podemos crear la función que generará la grilla:

private drawGrid() {
  this.ctx.fillStyle = '#666'
  this.ctx.fillRect(0, 0, this.canvasElem.width, this.canvasElem.height);

  this.ctx.strokeStyle = '#777';
  this.ctx.beginPath();
  for (let i = 0; i <= this.canvasElem.width; i += this.pixelSize) {
    this.ctx.moveTo(i, 0);
    this.ctx.lineTo(i, this.canvasElem.height);
  }
  for (let i = 0; i <= this.canvasElem.height; i += this.pixelSize) {
    this.ctx.moveTo(0, i);
    this.ctx.lineTo(this.canvasElem.width, i);
  }
  this.ctx.stroke();
}

(Color de fondo 666 porque somos rebeldes)

Con fillRect le decimos que vaya al punto 0,0, que sería la esquina superior izquierda del canvas, y que desde allí dibuje un cuadrado con el tamaño del canvas; efectivamente pintando el canvas del color definido en el fillStyle.

A continuación, con strokeStyle declaramos el color de los trazos que vienen en seguida y después iniciamos un path. El path dentro de cada for se va moviendo dependiendo del tamaño del pixel y pone el lápiz en la posición inicial con moveTo. En este momento no estamos dibujando, sólo movemos el lápiz a donde debe iniciar el trazado que realizará el lineTo. EL stroke al final hace que se apliquen los trazos.

Si seguiste los pasos, ya deberías ver la grilla en tu navegador. ¿No? bueno, será porque no has llamado a la función drawGrid en el constructor:

constructor() {
  // ...
  this.drawGrid();
}

¿Todavía nada? Ha de ser porque no has instanciado la clase... Prueba instanciándola en alguna parte, el final del archivo app.ts es una opción:

new PixelPaint();

Pintar

Ya tenemos el lienzo listo, ahora sí podemos pintar en él, para ello vamos a agregar eventos al canvas para capturar los eventos que se disparen cuando el usuario interactúe con él. Entonces vamos a usar jQuery y... NO. Vamos a usar JavaScript, como se debe:

constructor {
  // ...
  this.canvasElem.addEventListener('click', (event: MouseEvent) => {
      this.handleClick(event);
  });
}

handleClick(event: MouseEvent) {
  this.handlePaint(event.x, event.y);
}

handlePaint(x: number, y: number) {
  const pixelXstart = (x - (x % this.pixelSize)) / this.pixelSize;
  const pixelYstart = (y - (y % this.pixelSize)) / this.pixelSize;
  this.drawPixel(pixelXstart, pixelYstart);
}

Nada extraño hasta ahora, sólo que no estamos ejecutando la acción de pintar desde el callback del evento de clic, estamos delegando esta funcionalidad a drawPixel:

private drawPixel(x: number, y: number, color = "#CACA00") {
  const pixelXstart = x - (x % this.pixelSize);
  const pixelYstart = y - (y % this.pixelSize);

  this.ctx.fillStyle = color;
  this.ctx.fillRect(x * this.pixelSize, y * this.pixelSize, this.pixelSize, this.pixelSize);
}

La función es privada porque somos no queremos que quién implemente la clase PixelPaint tenga acceso a este método directamente. Nuestra clase, nuestras reglas.

Definimos un valor por defecto para el color del pixel. Por ahora sólo nos preocuparemos por pintar algo, más adelante veremos que inventamos para usar diferentes colores.

pixelXstart y pixelYstart buscan el punto de origen de la posición del evento de click y determinan a qué pixel corresponden usando el módulo. Esta es la operación matemática más compleja en esta aplicación. Con base en esto sabemos cuál es el punto de origen del pixel (esquina superior izquierda) y desde allí dibujamos un cuadrado con fillRect del tamaño de pixelSize.

Ahora sí cuando hacemos click en un cuadrado de la grilla veremos que se pinta de color CACA00.

Ya puedes arreglar ese margen horrible que tiene el body por defecto.

Quiero copiar y pegar

Entendible, me pasa igual. Aquí está:

class PixelPaint {
  canvasElem: HTMLCanvasElement;
  ctx: CanvasRenderingContext2D;
  pixelSize: number;

  constructor() {
    this.canvasElem = <HTMLCanvasElement>document.getElementById('canvas');
    this.ctx = <CanvasRenderingContext2D>this.canvasElem.getContext('2d');
    this.canvasElem.width = window.innerWidth;
    this.canvasElem.height = window.innerHeight;
    this.pixelSize = 50;
    this.drawGrid();

    this.canvasElem.addEventListener('click', (event: MouseEvent) => {
      this.handleClick(event);
    });
  }

  handleClick(event: MouseEvent) {
    this.drawPixel(event.x, event.y);
  }

  private drawPixel(x: number, y: number, color = "#CACA00") {
    const pixelXstart = x - (x % this.pixelSize);
    const pixelYstart = y - (y % this.pixelSize);

    this.ctx.fillStyle = color;
    this.ctx.fillRect(pixelXstart, pixelYstart, this.pixelSize, this.pixelSize);
  }

  private drawGrid() {
    this.ctx.fillStyle = '#666'
    this.ctx.fillRect(0, 0, this.canvasElem.width, this.canvasElem.height);

    this.ctx.strokeStyle = '#777';
    this.ctx.beginPath();
    for (let i = 0; i <= this.canvasElem.width; i += this.pixelSize) {
      this.ctx.moveTo(i, 0);
      this.ctx.lineTo(i, this.canvasElem.height);
    }
    for (let i = 0; i <= this.canvasElem.height; i += this.pixelSize) {
      this.ctx.moveTo(0, i);
      this.ctx.lineTo(this.canvasElem.width, i);
    }
    this.ctx.stroke();
  }
}

new PixelPaint();

¿Y el repo?

Aquí está https://github.com/UnJavaScripter/pixel-paint

¿Qué sigue?

Hay muchas funcionalidades que vamos a agregar, entre ellas:

Hacer que funcione con touch
Dibujar arrastrando el pointer (dedo o cursor)
Borrar
Historial
- Deshacer
- Rehacer
Seleccionar color
Dibujar canvas desde un Web Worker
Guardar imagen
Agregar música (¿por qué no?)
Social-painting: Dibujar con amigos

DEV Community: Diego Coy

Asynchrony in JavaScript: A Brief Look Back

Making an HTTP request

Callbacks and Drawbacks

The “callback hell”

From Callbacks to Promises

A new era: Async/Await

What about error handling?

Conclusion

Where to go from here?

The amazing powers of the web: Web Serial API

The Web Serial API

Why?

How?

Connection

Reading and Writing

Writing

Reading

Examples

Origin Trial

Browser support

Further reading

Next steps

Connecting the musical world to the Web using the Web MIDI API

Web MIDI

The messages

Web MIDI API

Getting MIDI access

Listing MIDI devices

Attaching callbacks

Receiving and Sending messages

The code

The demo

Browser Support

Things to read

Dibujando con canvas - Manejo de historial

Manejando historia

Objetivo

Demo

El código

PixelProp

HistoryHandler

¿historyRedo?

Conectando

¿Qué está pasando ahí?

¡Y listo!

Dibujando con canvas: trazados

Trazados en el canvas

Objetivo

Mouse events vs. Pointer events

El código

¿Y el repo?

¿Y el demo?

Dibujando pixeles en el navegador con Canvas... Y cosas extra

Objetivo

Demo

Ahora sí a programar

Grilla/Cuadricula

Pintar

Quiero copiar y pegar

¿Y el repo?

¿Qué sigue?