A few months back I started the Web platform's hidden gems blog series. The idea behind the series is to cover the native API enhancements to the web platform and shed some light on how these APIs can be used to create some really interesting experiences on the web. Even though these APIs are in very early stages at the moment, they seem to be really promising and tend to provide an idea on how web development in the coming years would look like. Having said that, I feel that it's important for developers to know about these specifications and understand the possibilities that the native web has to offer! In the previous blog post, I explained the Battery Status API, using which developers can fetch information about the system's battery charge levels and use it in web applications to make adjustments to resource usage. Feel free to read through it and try it out if you'd like. This is the fourth blog post of the series and in this post, I'll be talking about the Shape Detection API.

Web platform's hidden gems - Shape Detection API


![](/img/blogs/web-platform's-hidden-gems---shape-detection-api/1.png)

A few months back I started the [**Web platform's hidden gems**](<https://arunmichaeldsouza.com/blog/web-platform's-hidden-gems-(series)>) blog series. The idea behind the series is to cover the native API enhancements to the web platform and shed some light on how these APIs can be used to create some really interesting experiences on the web.

Even though these APIs are in very early stages at the moment, they seem to be really promising and tend to provide an idea on how web development in the coming years would look like. Having said that, I feel that it's important for developers to know about these specifications and understand the possibilities that the native web has to offer!

In the previous blog post, I explained the [Battery Status API](https://arunmichaeldsouza.com/blog/web-platform's-hidden-gems---battery-status-api), using which developers can fetch information about the system's battery charge levels and use it in web applications to make adjustments to resource usage. Feel free to read through it and try it out if you'd like.🙂

This is the fourth blog post of the series and in this post, I'll be talking about the [Shape Detection API](https://wicg.github.io/shape-detection-api/).

Just a disclaimer though, this API is in very early stages and may undergo major changes in terms of implementation and usage.

## Shape detection on the web

> The shape detection API enables developers to detect shapes (faces, text, bar codes etc.) from still images or live image feeds.

Detecting shapes or patterns from images can be a computationally expensive task and may require different kinds of libraries or third party APIs. But the Shape Detection API makes it a readily available feature in the browser that web developers can use. Using the Shape Detection API web developers can detect faces, text, bar codes and even QR codes which can be used for user identification, URL redirection, facial tagging etc.

The Shape Detection API uses the underlying hardware for detection capabilities which provides accelerated operation.

## Face detection API

The Face Detection API is a subset of the Shape Detection API which enables the detection of human faces in images. The **window.FaceDetector** interface can be used to create a new instance of the face detector. It provides a **detect()** method that receives the image as an argument and returns a promise, which when resolved, returns an array of detected faces. The image provided to the method may come from any type of image buffer source such as an image, video or canvas tag.

The **window.FaceDetector** interface supports the following options -

- **maxDetectedFaces** \- Hints the user agent to try and limit the number of detected faces in the scene.
- **fastMode** - Hints the user agent to try and prioritize speed over accuracy.

![](/img/blogs/web-platform's-hidden-gems---shape-detection-api/2.png)

Each detected face consists of a **bounding box** that defines the exact location and extent of the face in the image, as well as **landmark locations** for facial features such as eyes, mouth and nose. The landmark locations contain an array of points defining the vertices of a simple polygon surrounding the feature.

![](/img/blogs/web-platform's-hidden-gems---shape-detection-api/3.png)

As of now, the Face Detection API is available on Chrome and Opera behind the **Experimental Web Platform features** flag. You can enable it by going into **chrome://flags/#enable-experimental-web-platform-features** and selecting **Enabled**.

I prepared a demo for the Face Detection API running on Chrome 88. Please feel free to check out the code below -

[https://gist.github.com/ArunMichaelDsouza/ffe8b8eedf5909732a22907283f86430](https://gist.github.com/ArunMichaelDsouza/ffe8b8eedf5909732a22907283f86430)

## Barcode Detection API

The Barcode Detection API is another subset of the Shape Detection API which enables the detection of linear or 2D barcodes in images. The **window.BarcodeDetector** interface can be used to create a new instance of the barcode detector. It also provides a **detect()** method that receives the image as an argument and returns a promise, which when resolved, returns an array of the detected barcodes. The image provided to the method may come from any type of image buffer source such as an image, video or canvas tag.

The **window.BarcodeDetector** interface supports an optional bar code formats list setting. Using this list, developers can explicitly specify the bar code formats that are required to be supported by the application.

> Note: Limiting the search to a particular subset of supported formats is likely to provide better performance. To see a complete list of  supported formats please see [this link.](https://developer.mozilla.org/en-US/docs/Web/API/Barcode_Detection_API#supported_barcode_formats)

In order to see which formats are actually supported by the Barcode Detection API in your browser, you can use the **window.BarcodeDetector.getSupportedFormats()** method. This returns a promise which resolves to an array of supported formats.

![](/img/blogs/web-platform's-hidden-gems---shape-detection-api/4.png)

![](/img/blogs/web-platform's-hidden-gems---shape-detection-api/5.png)

Each detected barcode consists of a **bounding box** that defines the exact location and extent of the barcode feature in the image. It also contains the X, Y coordinates of the **corner points** of the feature, the **format** of the barcode and the **raw value**.

![](/img/blogs/web-platform's-hidden-gems---shape-detection-api/6.png)

Bounding box and other data of the detected barcode

As of now, the Barcode Detection API is available by default starting in Chrome 83, Edge 83 and Opera 72.

I prepared a demo for the Barcode Detection API running on Chrome 88. Please feel free to check out the code below -

[https://gist.github.com/ArunMichaelDsouza/b29459609fdd4247a096e9e052ad99dc](https://gist.github.com/ArunMichaelDsouza/b29459609fdd4247a096e9e052ad99dc)

## Text Detection API

The Text Detection API is another subset of the Shape Detection API which enables the detection of text in images. The **window.TextDetector** interface can be used to create a new instance of the text detector. It also provides a **detect()** method that receives the image as an argument and returns a promise, which when resolved, returns the detected text as an array. The image provided to the method may come from any type of image buffer source such as an image, video or canvas tag.

![](/img/blogs/web-platform's-hidden-gems---shape-detection-api/7.png)

Using the Text Detection API

The **bounding box** information and the X, Y coordinates of the **corner points** of the detected text are returned by the resolved promise. On some platforms, the recognized characters or the raw text value is also returned.

![](/img/blogs/web-platform's-hidden-gems---shape-detection-api/8.png)

Bounding box and corner points of the detected text

As of now, the Text Detection API is available on Chrome and Opera behind the **Experimental Web Platform features** flag. You can enable it by going into **chrome://flags/#enable-experimental-web-platform-features** and selecting **Enabled**.

I prepared a demo for the Text Detection API running on Chrome 88. Please feel free to check out the code below -

[https://gist.github.com/ArunMichaelDsouza/fc95a5fb574cb2295d2d092aa0c03fbf](https://gist.github.com/ArunMichaelDsouza/fc95a5fb574cb2295d2d092aa0c03fbf)

> Note: It is advisable to reuse the same detector instance for several detections as it may allocate and hold significant system resources.

All detectors work asynchronously and they do not block the main thread. They are also available to be used by web workers.

## Browser support

As mentioned above, both the Face detection API and the Text Detection API are available on Chrome and Opera behind the **Experimental Web Platform features** flag. You can enable it by going into **chrome://flags/#enable-experimental-web-platform-features** and selecting **Enabled**.

Whereas the Barcode Detection API is available by default starting in Chrome 83, Edge 83 and Opera 72.

![](/img/blogs/web-platform's-hidden-gems---shape-detection-api/9.png)

Barcode Detection API browser support

I would like to point out again that this specification is in very early stages so it may undergo major changes in terms of implementation and usage. But that shouldn't stop you from experimenting with it. So go ahead and give it a try!

You might be interested in the previous blog post about the [Battery Status API](https://arunmichaeldsouza.com/blog/web-platform's-hidden-gems---battery-status-api), using which developers can fetch information about the system's battery charge levels and use it in web applications to make adjustments to resource usage. Feel free to read through it and try it out as well if you'd like.🙂

In the next blog post of the series, I would be covering the [File System Access API](https://wicg.github.io/file-system-access/). So keep an eye out on this space for more info.

That pretty much sums it up! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


A few months back I started the Web platform's hidden gems blog series. The idea behind the series is to cover the native API enhancements to the web platform and shed some light on how these APIs can be used to create some really interesting experiences on the web. Even though these APIs are in very early stages at the moment, they seem to be really promising and tend to provide an idea on how web development in the coming years would look like. Having said that, I feel that it's important for developers to know about these specifications and understand the possibilities that the native web has to offer! In the previous blog post, I explained the Device Orientation API, using which developers can develop web applications with device orientation detection capabilities. This can be really useful for a variety of use cases like gaming - for controlling a character or an object and even for gesture recognition in web applications for enhanced accessibility. Feel free to read through it and try it out if you'd like.This is the fourth blog post of the series and in this post, I'll be talking about the Battery Status API.

Web platform's hidden gems - Battery Status API


![](/img/blogs/web-platform's-hidden-gems---battery-status-api/1.png)

A few months back I started the [**Web platform's hidden gems**](<https://arunmichaeldsouza.com/blog/web-platform's-hidden-gems-(series)>) blog series. The idea behind the series is to cover the native API enhancements to the web platform and shed some light on how these APIs can be used to create some really interesting experiences on the web.

Even though these APIs are in very early stages at the moment, they seem to be really promising and tend to provide an idea on how web development in the coming years would look like. Having said that, I feel that it's important for developers to know about these specifications and understand the possibilities that the native web has to offer!

In the previous blog post, I explained the [Device Orientation API](https://arunmichaeldsouza.com/blog/web-platform's-hidden-gems---device-orientation-api), using which developers can develop web applications with device orientation detection capabilities. This can be really useful for a variety of use cases like gaming - for controlling a character or an object and even for gesture recognition in web applications for enhanced accessibility. Feel free to read through it and try it out if you'd like.🙂

This is the third blog post of the series and in this post, I'll be talking about the [Battery Status API](https://www.w3.org/TR/battery-status/).

> Update: The Battery Status API has been deprecated and is no longer recommended for use. Some  browsers might  still support it, but the standard itself is in the process of  being dropped.

## Fetching the battery status

> The Battery Status API specification defines a means for web developers to programmatically determine the battery status of the hosting device.

This means that using this API, developers would be able to fetch information about the system's battery charge levels and use it in web applications to make adjustments to resource usage.

The Battery Status API exposes the **getBattery()** method on the navigator object that returns a promise which, when resolved, returns the information about the battery's state.

![](/img/blogs/web-platform's-hidden-gems---battery-status-api/2.png)

The returned data shows whether the system is being charged or not, what is the charge level or the percentage of the battery left and also returns some useful event handlers that can be used to detect certain changes in the battery usage.

![](/img/blogs/web-platform's-hidden-gems---battery-status-api/3.png)

## Detecting change in charging level

The **levelchange** event type can be used to detect any changes in the charging level. This event is fired whenever the charging level either increases (while charging) or decreases (while discharging).

![](/img/blogs/web-platform's-hidden-gems---battery-status-api/4.png)

The returned data shows the charging level which is a value between 0 and 1, multiply that by 100 and you have the battery percentage.

![](/img/blogs/web-platform's-hidden-gems---battery-status-api/5.png)

## Other event types

**chargingchange** \- This event is fired whenever a change in charging state takes place, that is when the charging unit is connected or disconnected.

**chargingtimechange** - This event is fired whenever the battery charging time gets updated. The **chargingTime** attribute represents the time remaining in seconds until the system's battery is fully charged.

**dischargingtimechange** - This event is fired whenever the battery discharging time gets updated. The **dischargingTime** attribute represents the time remaining in seconds until the system's battery is completely discharged and the system is about to be suspended.

## Browser support

As mentioned above, the standard itself is in the process of being dropped due to privacy concerns. But it's still worth checking out what potentially would've been a nice addition to the web platform.

![](/img/blogs/web-platform's-hidden-gems---battery-status-api/6.png)

You might be interested in the previous blog post about the [Device Orientation API](https://arunmichaeldsouza.com/blog/web-platform's-hidden-gems---device-orientation-api), using which developers can develop web applications with device orientation detection capabilities. Feel free to read through it and try it out as well if you'd like.🙂

In the next blog post of the series, I would be covering the [Shape Detection API](https://wicg.github.io/shape-detection-api/). So keep an eye out on this space for more info.

That pretty much sums it up! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


I've been a huge fan of construction toys since I was a kid, be it Lego, Duplo, Meccano, or Mechanix! I had them all and I never used to get tired of playing with them.  I don't mean to brag but I used to build some of the most interesting towers, houses, games, mini-cities, puzzles, and mazes, that too without any manuals or guides. Just pure imagination and creativity. Ah! those were the days.  Anyway, this isn't about me reminiscing about the fun times I had building those sets and playing with them. Rather It's about a new set that I got the chance to build (which is amazing by the way), and I want to share my experience here.

Building the BRXLZ Liverpool FC Anfield Stadium


![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/1.jpg)

I've been a huge fan of construction toys since I was a kid, be it [Lego](https://en.wikipedia.org/wiki/Lego), [Duplo](https://en.wikipedia.org/wiki/Lego_Duplo), [Meccano](https://en.wikipedia.org/wiki/Meccano), or [Mechanix](https://www.google.com/search?q=mechanix+sets&tbm=isch&ved=2ahUKEwiS3LPc4MvsAhUJyxQKHUtJB_kQ2-cCegQIABAA&oq=mechanix+sets&gs_lcp=CgNpbWcQAzIECCMQJzoECAAQQzoCCAA6BggAEAgQHjoECAAQGDoGCAAQChAYUMJZWOteYKpqaABwAHgAgAE5iAH_AZIBATWYAQCgAQGqAQtnd3Mtd2l6LWltZ8ABAQ&sclient=img&ei=IliTX5JDiZZTy5KdyA8&bih=701&biw=1440)! I had them all and I never used to get tired of playing with them.

I don't mean to brag but I used to build some of the most interesting towers, houses, games, mini-cities, puzzles, and mazes, that too without any manuals or guides. Just pure imagination and creativity. Ah! those were the days.

Anyway, this isn't about me reminiscing about the fun times I had building those sets and playing with them. Rather It's about a new set that I got the chance to build (which is amazing by the way), and I want to share my experience here.

So for my birthday this year, I got the [BRXLZ Liverpool FC Anfield Stadium](https://uk.foco.com/products/liverpool-fc-anfield-brxlz-stadium) construction set as a present and since I am a huge [Liverpool FC](https://www.liverpoolfc.com/) fan, I was totally blown away!

The overall quality of the set is top-notch and the level of detail is absolutely amazing! Believe me cause I've seen the real thing. From the main stand's roof to the Kop end even the brick patterns on the outside of Anfield road stand - it's just perfect!

The set contains 4,650 pieces (also includes extra pieces just in case you lose a few here and there) and a 126-page manual that has all the step by step instructions.

Since many of the pieces that come along are really small and can have different color shades, my suggestion would be to identify the pieces from the chart and sort them out based on shape and color. That way it's easier to locate the pieces and use them in the steps.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/2.png)

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/3.png)

Once you have all the pieces sorted out, you can pick the ones required in a particular step and start placing them together.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/4.png)

## Day 1

So I started off by setting up the foundation for the entire structure, this sets up the base for the stairs, the field, and all the stands.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/5.jpg)

## Day 2

The stairs have started to shape up and fresh grass has been laid out on the field. The groundwork for the seating area has also started.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/6.JPG)

## Day 3

The lower end of the seating area is complete and the exteriors of the stands are starting to shape up. At this point, I would suggest placing the pitch sticker on the field because there is more room available for easy movement.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/7.JPG)

## Day 4

The upper end of the seating area is starting to shape up and the entrance/exit tunnels are now complete.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/8.JPG)

## Day 5

The roof on the Kop end has been placed and the upper level seats are almost complete.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/9.jpg)

## Day 6

With the seating area and the exteriors complete on all sides, its time to work on the roof structures. The roof on the Kop end has been extended and the base has been set up to place roofs on rest of the sides.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/10.JPG)

## Day 7

The roofs are starting to shape up with the Anfield road stand roof complete.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/11.JPG)

## Day 8

The roof on the Sir Kenny Dalglish stand is now complete. The main stand's roof has been extended, on top of which the truss would be placed.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/12.JPG)

## Day 9

And its complete! Anfield stadium - home of Liverpool FC, the Premier League Champions!

With the roofs of the main stand and the Kop end in place. The truss and the extended roof have been put together to complete the massive main stand

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/13.JPG)

Here is the complete set with all the stickers placed - the LFC crest on the outside of the main stand, the Kop end and the Anfield sticker on the front.

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/14.png)

Complete BRXLZ Liverpool FC Anfield Stadium set

![](/img/blogs/building-the-brxlz-liverpool-fc-anfield-stadium/15.png)

BRXLZ Liverpool FC Anfield Stadium

I would say it's not complex to build the overall set if you sort the pieces out correctly from the very beginning. Like I said some pieces have different color shades which can be a bit tricky to identify.

The set has a lot of tiny pieces and for the entirety of it, you would be building all the structures end to end using a lot of different pieces and placing them together. And if you are an avid builder like me, you will definitely enjoy building it. I did for sure! And it would give you a real sense of accomplishment once you complete the set.

It took me 9 days, where I was spending around 3-4 hours per day building it, that's approximately 36 hours or 1.5 days in total. Not bad at all if you ask me!😄

That pretty much sums it up! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92).

Cheers!

PS: [Erica Louise](https://ericalouise.com/), If you are reading this - thank you again for the wonderful present!😄


A few months back I started the Web platform's hidden gems blog series. The idea behind the series is to cover the native API enhancements to the web platform and shed some light on how these APIs can be used to create some really interesting experiences on the web.   Even though these APIs are in very early stages at the moment, they seem to be really promising and tend to provide an idea on how web development in the coming years would look like. Having said that, I feel that it's important for developers to know about these specifications and understand the possibilities that the native web has to offer!  This is the third blog post of the series and in this post, I'll be talking about the Device Orientation API.

Web platform's hidden gems - Device Orientation API


![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/1.png)

A few months back I started the [Web platform's hidden gems](<https://arunmichaeldsouza.com/blog/web-platform's-hidden-gems-(series)>) blog series. The idea behind the series is to cover the native API enhancements to the web platform and shed some light on how these APIs can be used to create some really interesting experiences on the web.

Even though these APIs are in very early stages at the moment, they seem to be really promising and tend to provide an idea on how web development in the coming years would look like. Having said that, I feel that it's important for developers to know about these specifications and understand the possibilities that the native web has to offer!

In the previous blog post, I explained the [Gamepad API](https://arunmichaeldsouza.com/blog/web-platform's-hidden-gems---gamepad-api), using which developers can connect gamepads and similar input devices to the browser and use them in their gaming applications. Feel free to read through it and try it out if you'd like. 🙂

This is the second blog post of the series and in this post, I'll be talking about the [Device Orientation API](https://w3c.github.io/deviceorientation/spec-source-orientation.html).

Just a disclaimer though, this API is in very early stages and may undergo major changes in terms of implementation and usage.

## Detecting device orientation

> The Device Orientation specification provides several new DOM events for obtaining information about the physical orientation and movement of the hosting device.

The information returned by the events is provided by sources such as gyroscopes, compasses, and accelerometers. Using the data provided by these sources, we can determine information about the orientation as well as the motion of the device.

This can be really useful for a variety of use cases like gaming - for controlling a character or an object and even for gesture recognition in web applications for enhanced accessibility.

> Note : The events are only fired in a **secure browsing context** (https).

The **deviceorientation** event is emitted whenever a significant change in orientation occurs.

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/2.png)

## 3-dimensional coordinate system

To use the values returned by the events we need to understand the **3-dimensional coordinate system** used by device orientation -

- The **X-axis** runs from the left side of the device to the right side of the device.
- The **Y-axis** runs from the bottom of the device towards the top of the device.
- The **Z-axis** runs from the screen of the device up to the sky.

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/3.png)

Device orientation defines the following rotations along the 3 axes -

- The rotation around the **Z-axis** is called **Alpha**.

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/4.png)

- The rotation around the **X-axis** is called **Beta**.

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/5.png)

- The rotation around the **Y-axis** is called **Gamma**.

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/6.png)

The change in orientation returned by the event is expressed in terms of these values - **Alpha**, **Beta** and **Gamma**.

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/7.png)

Using these values we can determine the change in rotation with respect to the 3 axes.

## Simulating device orientation using chrome dev tools

In order to simulate the device orientation event and visualize the change in the values, we can make use of the chrome dev tools in-built device orientation sensor and simulate different types of device orientations such as portrait, landscape, and even custom ones.

To launch the simulator, simply open the dev tools window and press **Command+Shift+P** (Mac) or **Ctrl+Shift+P** (Windows or Linux) to open the command menu. Type "sensors" and select show sensors. From the orientation list select one of the preset or you can select a custom one as well.

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/8.gif)

On actual mobile devices, it's rather different. Most mobile browsers don't allow access to sensor data due to security reasons. It can only be made available for use by the web page after the user has granted permission to access the data.

For requesting user permission to access the orientation data, the [Permissions API](https://www.w3.org/TR/permissions/) can be used as follows -

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/9.png)

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/10.gif)

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/11.gif)

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/12.gif)

## Detecting device motion

Similarly, there's the **devicemotion** event that can help us to determine how fast the device is accelerating.

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/13.png)

The device motion event uses the same 3-dimensional coordinate system and provides acceleration values with respect to the 3 axes.

The event object returns the following information -

- **accelerationIncludingGravity** and **acceleration** - Acceleration values for the 3 axes (**X**, **Y** and **Z**) with and without the effects of gravity.
- **rotationRate** \- Rotation values for the 3 axes represented as **alpha**, **beta** and **gamma**.
- **interval** - Represents the time interval in milliseconds during which the data is obtained from the device.

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/14.png)

For requesting user permission to access the motion data, we can again use the Permissions API as follows -

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/15.png)

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/16.gif)

## Browser support

As of now, the API is a work in progress and is subject to change but the events themselves are supported by all modern browsers.

![](/img/blogs/web-platform's-hidden-gems---device-orientation-api/17.png)

I would like to point out again that this specification is in very early stages so it may undergo major changes in terms of implementation and usage. But that shouldn't stop you from experimenting with it. So go ahead and give it a try!

You might be interested in the previous blog post about the [Gamepad API](https://arunmichaeldsouza.com/blog/web-platform's-hidden-gems---gamepad-api), using which developers can connect gamepads and similar input devices to the browser and use them in their gaming applications. Feel free to read through it and try it out as well if you'd like. 🙂

In the next blog post of the series, I would be covering the [Battery Status API](https://www.w3.org/TR/battery-status/). So keep an eye out on this space for more info.

That pretty much sums it up! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


A few weeks back I started the Web Platform’s hidden gems blog series. The idea behind the series is to cover the native API enhancements to the web platform and shed some light on how these APIs can be used to create some really interesting experiences on the web. Even though these APIs are in very early stages at the moment, they seem to be really promising and tend to provide an idea on how web development in the coming years would look like. Having said that, I feel that it's important for developers to know about these specifications and understand the possibilities that the native web has to offer! This is the first blog post of the series and in this post, I'll be talking about the Gamepad API.

Web platform's hidden gems - Gamepad API


![](/img/blogs/web-platform's-hidden-gems---gamepad-api/1.png)

A few weeks back I started the [Web platform's hidden gems](<https://arunmichaeldsouza.com/blog/web-platform's-hidden-gems-(series)>) blog series. The idea behind the series is to cover the native API enhancements to the web platform and shed some light on how these APIs can be used to create some really interesting experiences on the web.

Even though these APIs are in very early stages at the moment, they seem to be really promising and tend to provide an idea on how web development in the coming years would look like. Having said that, I feel that it's important for developers to know about these specifications and understand the possibilities that the native web has to offer!

This is the first blog post of the series and in this post, I'll be talking about the [Gamepad API](https://w3c.github.io/gamepad/).

Just a disclaimer though, this API is in very early stages and may undergo major changes in terms of implementation and usage.

## Connecting a gamepad to the browser

> The Gamepad specification defines a low-level interface that represents gamepad devices.

This means that using this API, developers would be able to connect gamepads and similar input devices to the browser and be able to use them in their gaming applications. There would be no need to design any complex mouse/keyboard based interfaces for game controls that can be tricky to operate and can take some time to get used to. Game developers would be able to provide more natural controls to their users like joystick driven character movements.

The **gamepadconnected** event is emitted whenever a new gamepad is connected to the page. If the gamepad is already connected when the page loads and gains focus then the event is emitted when a button is pressed or an axis is moved on the gamepad.

![](/img/blogs/web-platform's-hidden-gems---gamepad-api/2.png)

The **window.navigator.getGamepads()** method returns an array of Gamepad objects, one for each gamepad connected to the device. The Gamepad API supports up to 4 simultaneous connections at the moment.

If you log out the 0th index (the first connected gamepad) you can see the gamepad info -

![](/img/blogs/web-platform's-hidden-gems---gamepad-api/3.png)

The Gamepad interface stores information about the connected gamepad

The **gamepaddisconnected** event is emitted whenever a gamepad (which has previously received data from the page) has been disconnected.

![](/img/blogs/web-platform's-hidden-gems---gamepad-api/4.png)

## Tracking button press and axis movement

Currently, the gamepad API only supports these two events - **gamepadconnected** and **gamepaddisconnected**. There is no standardized way to detect gamepad button presses or axis movements. The [Gamepad interface](https://developer.mozilla.org/en-US/docs/Web/API/Gamepad) does return useful information about the gamepad buttons, axes and their current states (button press and axis movement values) but there is no actual event that is dispatched when these actions are performed by the user.

But there is a way to continuously **poll** for button and axis value changes using **[window.requestAnimationFrame()](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame)** \-

![](/img/blogs/web-platform's-hidden-gems---gamepad-api/5.png)

In the context of a video game, a **game loop** is something that continuously checks for user input, updates the game state and renders the scene. **requestAnimationFrame()** seems to be fitting well for this as we can perform all these operations in its callback and it would remain in sync with the repaint tasks in every frame.

Ideally that's how user input should be polled in a gaming application.

I'd highly recommend checking this article - [Anatomy of a video game](https://developer.mozilla.org/en-US/docs/Games/Anatomy) if you want to know more about how a typical game loop workflow can be implemented in JavaScript.

This does give us the user input states as expected but we still need a way to store and discard these values in an efficient way. Ideally in the form of an API that can be exposed and reused in any gaming application.

That is the very reason why I created **[joypad.js](https://github.com/ArunMichaelDsouza/joypad.js)** \- a JavaScript library that lets you connect and use various gaming controllers with browsers that support the Gamepad API. It's less than 5KB in size with zero dependencies and has support for button press, axis movement events and vibration play effect.

Subscribing to events is as simple as specifying an event name and a callback that is fired whenever the specified event is triggered.

![](/img/blogs/web-platform's-hidden-gems---gamepad-api/6.png)

For more details on how to use it or to know how it works under the hood (Spoiler alert: it uses the requestAnimationFrame() polling technique), please feel free to go to its [Github page](https://github.com/ArunMichaelDsouza/joypad.js).

Now coming back to the Gamepad API, the button/axis layout is as follows -

![](/img/blogs/web-platform's-hidden-gems---gamepad-api/7.png)

This is the **Standard Gamepad** button layout which is supported by most controllers in which button locations are laid out in a left cluster of four buttons, a right cluster of four buttons, a center cluster of three buttons (some controllers have four) and a pair of front-facing buttons (shoulder buttons) on the left and right side of the gamepad.

Please note that since the Gamepad API is in very early stages, the standard gamepad button layout may differ from browser to browser. The image shown above describes the default button mappings as on **Chrome**.

## Browser support

As of now the Gamepad specification is a work in progress and was published by the [Web Applications Working Group](https://www.w3.org/2019/webapps/) as a working draft. The specification is intended to become a W3C recommendation.

The API itself is [supported by all modern browsers](https://caniuse.com/#search=gamepad).

![](/img/blogs/web-platform's-hidden-gems---gamepad-api/8.png)

I would like to point out again that the Gamepad API is in very early stages so it may undergo major changes in terms of implementation and usage. But that shouldn't stop you from experimenting with it. So go ahead give it a try, add gamepad support to your existing games or maybe develop some new ones!

In the next blog post of the series, I would be covering the [Device Orientation API](https://w3c.github.io/deviceorientation/spec-source-orientation.html). So keep an eye out on this space for more info.

That pretty much sums it up! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


The web has certainly grown a lot over the last half a decade and continues to grow at an enormous pace. The highlight of this explosive growth is the continuous addition of feature-rich APIs that enables developers to create much more interactive and efficient web applications. Enhancements such as GPU accelerated graphics/computation, lower-level APIs that provide better control and hardware access not only allow developers to cater to a wider spectrum of users but also to support various other platforms and use cases. This makes the web portable and extensible in the true sense. Even though these specifications are in very early stages at the moment, they seem to be really promising and tend to provide an idea on how web development in the coming years would look like. Looking beyond the JavaScript framework landscape, there are a lot of nifty features that the web platform offers natively and it's important for developers to know about these specifications and understand the possibilities that the native web has to offer!

Web platform's hidden gems (series)


![](</img/blogs/web-platform's-hidden-gems-(series)/1.png>)

The web has certainly grown a lot over the last half a decade and continues to grow at an enormous pace. The highlight of this explosive growth is the continuous addition of feature-rich APIs that enables developers to create much more interactive and efficient web applications.

Enhancements such as GPU accelerated graphics/computation, lower-level APIs that provide better control and hardware access not only allow developers to cater to a wider spectrum of users but also to support various other platforms and use cases. This makes the web portable and extensible in the true sense.

Even though these APIs are in very early stages at the moment, they seem to be really promising and tend to provide an idea on how web development in the coming years would look like.

Looking beyond the JavaScript framework landscape, there are a lot of nifty features that the web platform offers natively and it's important for developers to know about these specifications and understand the possibilities that the native web has to offer!

![](</img/blogs/web-platform's-hidden-gems-(series)/2.png>)

The browser has become more than just a renderer or a document viewer. Developers have been constantly pushing the boundaries of the web which has led to its common adoption as a software platform!

As an attempt to shed some light on these web platform APIs, I have decided to start the blog series - **Web platform's hidden gems**. The first blog post of the series would cover the [Gamepad API](https://w3c.github.io/gamepad/) and would be published soon. So keep an eye out on this space for more info.

That pretty much sums it up! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


I still vividly remember playing games on my PC, the times when detailed polygon models weren't a thing, open worlds were small and well, not that open (to be very honest) and online multiplayer gaming was still underway. For most games, controls mapped to a standard keyboard were fine to play with. But for games with more complex controls, it was just more viable to switch to a standard gamepad.

Using joypad.js for a better gaming experience on the web


![](/img/blogs/using-joypad.js-for-a-better-gaming-experience-on-the-web/1.png)

I still vividly remember playing games on my PC, the times when detailed [polygon models](https://en.wikipedia.org/wiki/Polygonal_modeling) weren't a thing, open worlds were small and well, not that open (to be very honest) and online multiplayer gaming was still underway. For most games, controls mapped to a standard keyboard were fine to play with. But for games with more complex controls, it was just more viable to switch to a standard gamepad.

Desktop games provide this flexibility to gamers majorly because they have native support for connecting external devices like gamepads and joysticks. But on the web it's totally different, you just need a browser and either your mouse or keyboard becomes the controller.

Using a mouse to move around is fun, but it can turn out to be quite a daunting task for gamers that prefer more natural controls like a directional pad or a joystick for character movements.

For long there has been no native support in the browser for connecting gamepads or joysticks. Developers had to design mouse/keyboard based interfaces for game controls that can be tricky to operate and can take some time to get used to.

## Press start to play 🎮

Turns out a few years back the W3C introduced the [Gamepad specification](https://w3c.github.io/gamepad/) which has been under constant development since then and has been implemented by various browser vendors (but is still subject to change). As stated in the spec -

> The Gamepad specification defines a low-level interface that represents gamepad devices.

This means that using this API, developers would be able to connect gamepads and similar input devices to the browser and be able to use them in their gaming applications. Sounds cool right? It's quite the contrary when you go about implementing it.

## Enter boss stage ⚔️

As of now, only 2 events are supported by the gamepad API -

**gamepadconnected** - indicates that a gamepad has been connected.

**gamepaddisconnected** - indicates that a gamepad has been disconnected.

There is no standardized way to detect gamepad button presses or axis movements. The [Gamepad interface](https://developer.mozilla.org/en-US/docs/Web/API/Gamepad) does return useful information about the gamepad buttons, axes and their current states (button press and axis movement values) but there is no actual event that is dispatched when these actions are performed by the user.

The **window.navigator.getGamepads()** method returns an array of Gamepad objects, one for each gamepad connected to the device. If you log out the 0th index (the first connected gamepad) you can see the gamepad info -

![](/img/blogs/using-joypad.js-for-a-better-gaming-experience-on-the-web/2.png)

The Gamepad interface stores information about the connected gamepad

Notice that there's a mapping of all the buttons present on the gamepad. This mapping stores information about the button states.

Now if you press any of the buttons and log the info out again, you would notice that the state doesn't change -

![](/img/blogs/using-joypad.js-for-a-better-gaming-experience-on-the-web/3.png)

Even though it was pressed, the value remains **false**. That is because once after you release the button, the state of the button is reverted. So you can't really capture the button state (and as mentioned earlier there is no standard event for this) and the state is lost.

What if we wrap this inside a **setInterval()** call -

![](/img/blogs/using-joypad.js-for-a-better-gaming-experience-on-the-web/4.png)

![](/img/blogs/using-joypad.js-for-a-better-gaming-experience-on-the-web/5.png)

Now we are able to catch the button state as it updates, but is this the best way to do it?

## Bonus round 🌟

Before answering that question, first let's try to understand why **setInterval()** is not the right candidate for this job.

We all know that in JavaScript everything runs on a single thread and the timer functions are no exception. To execute code using **setInterval()** we specify a callback that is executed every **x** milliseconds. The delays provided to these timer functions are some times not honored due to priority execution of resource-intensive tasks (if any in the task queue). This leads to inconsistent delay intervals.

You might have noticed a jank while using **setInterval()** to animate elements on the page. This is caused due to unnecessary and forceful reflows of the page elements even before the user's screen is ready to process and render those updates. This is called [Layout Thrashing](https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing) and should be avoided at all costs!

Now the next question is what could be the most efficient way to query the Gamepad objects if **setInterval()** is not the right solution?

### requestAnimationFrame() to the rescue!

As stated on MDN -

> The **[window.requestAnimationFrame()](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame)** method tells the browser that you wish to perform an animation and requests that the browser calls a specified function to update an animation before the next repaint. The method takes a callback as an argument to be invoked before the repaint.

This basically means that the callback provided to **requestAnimationFrame()** is guaranteed to be executed at the start of the frame. The number of times the callback function is requested is around 60 times a second but will match the screen's refresh rate.

In the context of a video game, a **game loop** is something that continuously checks for user input, updates the game state and renders the scene. **requestAnimationFrame()** seems to be fitting well for this as we can perform all these operations in its callback and it would remain in sync with the repaint tasks in every frame.

Ideally that's how user input should be polled in a gaming application.

I'd highly recommend checking this article - [https://developer.mozilla.org/en-US/docs/Games/Anatomy](https://developer.mozilla.org/en-US/docs/Games/Anatomy) if you want to know more about how a typical game loop workflow can be implemented in JavaScript.

Now coming back to the Gamepad API, querying the Gamepad objects and accessing the button/axis states can be done effectively using **requestAnimationFrame()** \-

![](/img/blogs/using-joypad.js-for-a-better-gaming-experience-on-the-web/6.png)

This does give us the user input states as expected but we still need a way to store and discard these values in an efficient way. Ideally in the form of an API that can be exposed and reused in any gaming application.

## Time to power up! 🍄

I'd like to Introduce [**joypad.js**](https://github.com/ArunMichaelDsouza/joypad.js) - a JavaScript library that lets you connect and use various gaming controllers with browsers that support the Gamepad API. It's less than 5KB in size with zero dependencies and has support for button press, axis movement events and vibration play effect.

It's a utility library that I open-sourced a few months back under the [MIT license](https://github.com/ArunMichaelDsouza/joypad.js#license). It exposes an event-based [API](https://github.com/ArunMichaelDsouza/joypad.js#api) that can be used to subscribe to certain events that are detected and dispatched internally by the library.

Subscribing to events is as simple as specifying an event name and a callback that is fired whenever the specified event is triggered.

![](/img/blogs/using-joypad.js-for-a-better-gaming-experience-on-the-web/7.png)

The following events are supported by the library -

**connect** - Fired whenever a controller is connected.

**disconnect** \- Fired whenever a controller is disconnected.

**button_press** - Fired whenever a controller's button is pressed.

**axis_move** - Fired whenever a controller's axis (analog stick) is moved.

To know more about the joypad.js events please check out the detailed documentation [here](https://github.com/ArunMichaelDsouza/joypad.js#events).

joypad.js supports the standard gamepad button layout which is supported by most controllers in which button locations are laid out in a left cluster of four buttons, a right cluster of four buttons , a center cluster of three buttons (some controllers have four) and a pair of front-facing buttons (shoulder buttons) on the left and right side of the gamepad.

Please note that since the Gamepad API is in very early stages, the standard gamepad button layout may differ from browser to browser.

The following image describes the default button mappings as on **Chrome** -

![](/img/blogs/using-joypad.js-for-a-better-gaming-experience-on-the-web/8.png)

The standard gamepad button layout can be overridden using the **[customButtonMapping](https://github.com/ArunMichaelDsouza/joypad.js#custombuttonmapping-object)** setting and can be used for better cross-browser button mappings support.

The library also has support for adjusting the threshold for the axis (analog stick) movement which can be done using the **[axisMovementThreshold](https://github.com/ArunMichaelDsouza/joypad.js#axismovementthreshold-number)** setting. To know more about all the settings please check the detailed documentation [here](https://github.com/ArunMichaelDsouza/joypad.js#settings).

joypad.js works on all modern browsers that support the Gamepad API. Please feel free to give it a try and provide your feedback. I would like to point out again that the Gamepad API is in very early stages so it may undergo major API changes. I'll try my best to keep the library up to date with the specification. Nonetheless, pull requests are welcomed for bug fixes and new features :)

That pretty much sums it up! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


Believe it or not, progressively loading images tend to degrade the overall user experience of a web application. And this can be more concerning for applications that rely heavily on high quality images. To fix this issue, a common technique is to display a placeholder image (for a short span) and replace it with the original image once it has loaded completely.  In this blog post we'll be looking at a React JS based component called react-image-appear, which applies this very same technique and helps in loading images smoothly!

Loading images gracefully with react-image-appear


![](/img/blogs/loading-images-gracefully-with-react-image-appear/1.png)

Believe it or not, progressively loading images tend to degrade the overall user experience of a web application. And this can be more concerning for applications that rely heavily on high quality images. To fix this issue, a common technique is to display a placeholder image (for a short span) and replace it with the original image once it has loaded completely.

In this blog post we'll be looking at a React JS based component called [react-image-appear](https://github.com/ArunMichaelDsouza/react-image-appear), which applies this very same technique and helps in loading images smoothly!

![](/img/blogs/loading-images-gracefully-with-react-image-appear/2.gif)

## What is react-image-appear ?

It is a React JS component which makes images appear with transition as they load. It basically wraps an image within a placeholder element and adds a gif loader in between.

## Usage

Firstly the component needs to be [installed using npm or yarn](https://github.com/ArunMichaelDsouza/react-image-appear#installation). Using it in your codebase is pretty straightforward, simply import the component and provide the required **src** prop with any of the available optional props.

## Props

Apart from the required **src** prop there are various optional props that can be used to customise the image loading experience provided by react-image-appear. You can have custom loaders, placeholders, animations etc.

![](/img/blogs/loading-images-gracefully-with-react-image-appear/3.gif)

![](/img/blogs/loading-images-gracefully-with-react-image-appear/4.gif)

![](/img/blogs/loading-images-gracefully-with-react-image-appear/5.gif)

This is the full props list -

- **src** - The image source. This is a required prop.
- **loader** \- Adds a custom loader to the component. When not provided, applies a default one.
- **loaderStyle** - Adds custom styling to the loader.
- **loaderClass** - Adds CSS classes to the loader.
- **placeholder** - Adds a placeholder background to the component.
- **placeholderStyle** - Adds custom styling to the placeholder.
- **placeholderClass** - Adds CSS classes to the placeholder.
- **animation** - Add a CSS3 powered animation to the image as it appears. Default animation is **fadeIn**.
- **animationDuration** \- Specifies the animation duration for the image to appear. Default duration is **700ms**.
- **easing** - Specifies the timing-function for the CSS3 powered animation. Default easing is **ease-in-out**.
- **showLoader** - Specifies whether to show the loader or not. Default value is **true**.

To know more about the usage and examples for all the props, you can check out the complete documentation [here](https://github.com/ArunMichaelDsouza/react-image-appear#props).

This project has also been ported to AngularJS 1.x - [ng-image-appear](https://github.com/ArunMichaelDsouza/ng-image-appear).

react-image-appear is completely free to use and has been open sourced under the [MIT license](https://github.com/ArunMichaelDsouza/react-image-appear#license). For its long term sustenance and growth I recently launched a [Patreon page](https://www.patreon.com/arunmichaeldsouza)!

If you or your company use react-image-appear or any of my other projects, or like what I'm doing, please consider backing me so I can continue maintaining and working on these projects and new ones. Your pledge could be as small as $1/month. I'd really appreciate your support!

That's it for now! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


There are a lot of options available when it comes to choosing a tool for data logging in your Node JS application. At times you would find yourself switching back and forth between different tools just to get that perfect logger configuration set up properly for your project.   But of course, due to the instant availability of multiple open source JavaScript packages and tools (thanks to NPM) this doesn't only apply to loggers. It has spread across to almost every facet of JavaScript development now. But for the purpose of this blog post, let's just stick to Node JS data logging.   A common need while developing applications is to have your data logs get aggregated in an output file, instead of just getting logged to the console or the standard output stream (stdout). This makes it easy to resolve bugs faster, gain insights from the data being logged and maybe analyse it at a later stage.  For this very purpose we are required to use third-party data logging modules, and we'll be looking at one such open source module called Woodlot.

Easy JSON logging in Node JS using Woodlot


![](/img/blogs/easy-json-logging-in-node-js-using-woodlot/1.png)

There are a lot of options available when it comes to choosing a tool for data logging in your Node JS application. At times you would find yourself switching back and forth between different tools just to get that perfect logger configuration set up properly for your project.

But of course, due to the instant availability of multiple open source JavaScript packages and tools (thanks to [NPM](https://www.npmjs.com/)) this doesn't only apply to loggers. It has spread across to almost every facet of JavaScript development now. But for the purpose of this blog post, let's just stick to Node JS data logging.

A common need while developing applications is to have your data logs get aggregated in an output file, instead of just getting logged to the console or the standard output stream (stdout). This makes it easy to resolve bugs faster, gain insights from the data being logged and maybe analyse it at a later stage.

For this very purpose we are required to use third-party data logging modules, and we'll be looking at one such open source module called [Woodlot](http://adpushup.github.io/woodlot/).

## What is Woodlot?

Woodlot is an all-in-one JSON logging module for Node JS which was open sourced by [AdPushup Inc](https://www.adpushup.com/). It supports -

- HTTP middleware logging for [Express JS](https://expressjs.com/), [Restify](http://restify.com/) etc.
- Custom logging with different logging levels.
- Log output in JSON format with request body/query params, headers and cookies.
- Apache [common](http://httpd.apache.org/docs/current/logs.html#common) and [combined](http://httpd.apache.org/docs/current/logs.html#combined) log formats as output.
- Multiple file streams for log aggregation.
- A simple to use events API.
- Node JS version 0.10 and above.

The best part about using Woodlot is that you can use it to integrate middleware logging and custom logging both in your application, instead of installing separate modules.

Woodlot logs JSON output by default which makes it easier to aggregate and understand the logged data.

## Middleware Logging

The Woodlot **middlewareLogger** can be hooked into an existing Express JS middleware chain and can be used to log all HTTP requests.

This middleware logger configuration will generate log output in JSON format.

![](/img/blogs/easy-json-logging-in-node-js-using-woodlot/2.png)

The Woodlot middleware logger supports whitelisting and strict checking for routes and user analytics (platform, country) logging as well. Apart from JSON format support, it also also has support for logging in Apache's access log formats.

Documentation on all of the different options that the middleware logger supports can be found [here](https://github.com/adpushup/woodlot#as-an-expressjs-middleware).

## Custom Logging

The Woodlot **customLogger** can be used to perform custom logging with different logging levels.

This custom logger configuration will generate log output in JSON format.

![](/img/blogs/easy-json-logging-in-node-js-using-woodlot/3.png)

The Woodlot custom logger supports four different logging levels - [info](https://github.com/adpushup/woodlot#info), [debug](https://github.com/adpushup/woodlot#debug), [warn](https://github.com/adpushup/woodlot#warn) and [err](https://github.com/adpushup/woodlot#err). It supports data logging in standard text format as well.

Documentation on all of the different options that the custom logger supports can be found [here](https://github.com/adpushup/woodlot#custom-logging).

## Events

Woodlot emits events at various operations that can be used to track critical data. This events API is what makes Woodlot truly extensible.

These events can be captured and can be sent to a third party service or to a database for aggregation and analysis.

![](/img/blogs/easy-json-logging-in-node-js-using-woodlot/4.png)

There are various middleware logger and custom logger events that Woodlot emits. Documentation of the Woodlot events API can be found [here](https://github.com/adpushup/woodlot#events).

Woodlot is completely free to use and has been open sourced under the [MIT license](https://github.com/adpushup/woodlot#license). For its long term sustenance and growth I recently launched a [Patreon page](https://www.patreon.com/arunmichaeldsouza)!

If you or your company use Woodlot or any of my other projects, or like what I'm doing, please consider backing me so I can continue maintaining and working on these projects and new ones. Your pledge could be as small as $1/month. I'd really appreciate your support!

That pretty much sums it up! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


Typing out long and error-prone paths to your Node JS modules can be a daunting task! Even with code-completion features like IntelliSense in place (which is supported by almost every IDE or text editor), this can become more challenging as your codebase grows. Just imagine changing the directory structure of your project and you're forced to change all occurrences of the modules currently being referenced multiple times throughout your project. It's a maintenance nightmare! Moreover, it looks damn ugly! Code should be easy to read and understand. And with the current module systems in Node JS or JavaScript in general, this can turn out to be a problem since these systems don't have native support for meaningful referencing. An alias to a module path clearly indicates the location and purpose of the module being used. Dots and slashes hardly tell anything!

Aliasing module paths in Node JS


![](/img/blogs/aliasing-module-paths-in-node-js/1.png)

## The "Relative path hell" Problem

Typing out long and error-prone paths to your Node JS modules can be a daunting task!

Even with code-completion features like [IntelliSense](https://en.wikipedia.org/wiki/Intelligent_code_completion) in place (which is supported by almost every IDE or text editor), this can become more challenging as your codebase grows.

Just imagine changing the directory structure of your project and you're forced to change all occurrences of the modules currently being referenced multiple times throughout your project. It's a maintenance nightmare!

Moreover, it looks damn ugly!

Code should be easy to read and understand. And with the current module systems in Node JS or JavaScript in general, this can turn out to be a problem since these systems don't have native support for meaningful referencing.

> An alias to a module path clearly indicates the location and purpose of the module being used. Dots and slashes hardly tell anything!

![](/img/blogs/aliasing-module-paths-in-node-js/2.png)

## The Solution

There might be a possible solution to this "relative path hell" problem -

**Symlinks**

> A Symlink or a [Symbolic Link](https://en.wikipedia.org/wiki/Symbolic_link) is simply a shortcut or a reference to another file. It is a file that points to another file.

Basically, you can create symlinks to your modules and have your Node JS app refer to these modules using the created symlinks.

Symlinks can be created using the **[ln](https://www.computerhope.com/unix/uln.htm)** command available on Linux/UNIX/Mac. If you're not already on Windows 10 then you're probably not leveraging the linux bash shell that comes bundled with it ([more info](https://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/)), in that case, you can use the standard Windows [**mlink**](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink) command.

But wait a minute, you don't actually have to manually create all these symlinks by yourselves. Instead, you can write a simple Node JS script which can automate the symlink creation process for you. The Node JS [file system](https://nodejs.org/api/fs.html) module exposes the **[fs.symlink](https://nodejs.org/api/fs.html#fs_fs_symlink_target_path_type_callback)** method which can be used for creating symlinks for directories or files.

## Good News!

There's an existing NPM package which can do this job for you called [**link-module-alias**](https://github.com/Rush/link-module-alias).

Simply add the required module aliases into your project's **package.json** file and add a **postinstall** script, which will automatically initialise the symlink creation process for you.

![](/img/blogs/aliasing-module-paths-in-node-js/3.png)

After your configuration is complete, simply run -

**npm install** \- Installs your project's dependencies and automatically executes the postinstall script.

or

**npm run postinstall** - Only executes the postinstall script.

Once the postinstall script executes, it makes a call to link-module-alias which creates the required symlinks for your project. Your Node JS app will then be able to resolve all references to the defined aliases.

![](/img/blogs/aliasing-module-paths-in-node-js/4.png)

Now whenever you are requiring your modules, you can simply do this -

![](/img/blogs/aliasing-module-paths-in-node-js/5.png)

No matter where you are in your project tree, all your aliased modules will resolve successfully.

## The icing on the cake

If you happen to use [VS Code](https://code.visualstudio.com/) then all of your aliased modules and directories will have their files appear in the VS Code autocompletion drop-down, which makes it super handy to use your aliased modules!

![](/img/blogs/aliasing-module-paths-in-node-js/6.png)

Another plus point to be mentioned here is that this particular approach doesn't need any runtime hooks in your app's entry point, unlike other approaches to solve this problem which rely on runtime hooks. Runtime hooks add a level of unnecessary computation and complexity to your app. If by any chance a runtime hook fails, it might crash your entire app.

## Update (2021): Subpath Imports

Support for [subpath imports](https://nodejs.org/api/packages.html#subpath-imports) was added in Node JS  v14.6.0, v12.19.0 which helps in the creation of import maps that only apply to import specifiers from within the package itself. Entries in the imports field must always start with **\#** to ensure they are disambiguated from package specifiers.

![](/img/blogs/aliasing-module-paths-in-node-js/7.png)

## Other solutions

1.  **module-alias**

    If you have no issues with require hooks then you can consider this package - [module-alias](https://github.com/ilearnio/module-alias). There are a few gotchas though that you'll need to keep in mind while using this package. For example, this package **modifies the default require behavior!** And should be used with caution.

2.  **Yarn Workspaces**  
    [Yarn Workspaces](https://yarnpkg.com/lang/en/docs/workspaces/), in particular, cater to JavaScript projects which have multiple internal packages (also called workspaces) as dependencies. Each workspace has its own dependencies and can be linked to the global workspace for easy access.
3.  **Webpack Resolve**  
    If you're bundling your modules with webpack, then you can use [webpack's module resolution options](https://webpack.js.org/configuration/resolve/) to set aliases for your modules. This obviously makes sense on the client side where you are transpiling and bundling your JavaScript code with webpack.
4.  **babel-plugin-module-resolver**  
    The [babel module resolver plugin](https://github.com/tleunen/babel-plugin-module-resolver) can be used with the babel transpilation pipeline to resolve modules with custom aliases for directories or specific files.

That pretty much sums it up! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


State is the fundamental way to store and retrieve your React application’s data. It’s nothing but a JavaScript object, which React allows you to update via the setState() method.

Updating state of a parentless component in React


![](/img/blogs/updating-state-of-a-parentless-component-in-react/1.png)

State is the fundamental way to store and retrieve your React application's data. It's nothing but a JavaScript object, which React allows you to update via the **setState()** method.

Using **setState()** is pretty straightforward, simply call the method and pass in the state variables that need to be updated, which in turn, re-renders the component tree.

![](/img/blogs/updating-state-of-a-parentless-component-in-react/2.png)

Since **setState()** updates the state of a particular React component, it needs to be called within that component's context.

![](/img/blogs/updating-state-of-a-parentless-component-in-react/3.png)

In the example above, **this** provides the context to the **setState()** call, which refers to the **InputBox** component.

> Note : **setState()** is actually asynchronous. More info [here](https://reactjs.org/docs/react-component.html#setstate).

As mentioned earlier, **this** represents the component itself. If you log it out, you'll see that it returns the **state** and **props** tied to the component.

![](/img/blogs/updating-state-of-a-parentless-component-in-react/4.png)

![](/img/blogs/updating-state-of-a-parentless-component-in-react/5.png)

Logging out **this** returns the whole React component

Now this means that updating the state of a React component can be as easy as this -

![](/img/blogs/updating-state-of-a-parentless-component-in-react/6.png)

A suitable method to update the state of a **Parentless** component would be to pass a callback as a prop, to the **Child** component, which once fired, updates the state of the **Parent**.

Pretty handy! But this obviously makes sense when you have a relatively smaller component tree, and you would want to avoid returning callbacks from a deeply nested component, all the way up to the topmost parent.

But what if we want to update the state of the topmost parent, from a deeply nested component ?

Well, we can keep a reference of the topmost parent's component instance, and call **setState()** when we want to trigger the state change.

Let's see how -

> Note : **ReactDOM.render()** returns a reference to the component being mounted.

As you can see, we can simply create a **function** at the global level and call it from our **DeeplyNestedChild** and pass the value for the state variable to be changed in the **Parent** component. Once called, we can set the state of the **Parent** component using its reference returned by **ReactDOM.render()**.

This method can majorly help in cases, where we want to update the state of a **Parent** component in one component tree, from a **Child** component of some other component tree, considering if one of the component trees is getting dynamically generated using, say for example a **[Portal](https://reactjs.org/docs/portals.html)**.

![](/img/blogs/updating-state-of-a-parentless-component-in-react/7.png)

Only want to trigger a re-render? You can do so using **[forceUpdate()](https://reactjs.org/docs/react-component.html#forceupdate)** -

![](/img/blogs/updating-state-of-a-parentless-component-in-react/8.png)

That's it for now! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


It’s been some time since Facebook released React 16.  The new release has a lot of new features to facilitate the designing of robust components and enhancements to speed up the rendering pipeline.

Getting started with React 16


![](/img/blogs/getting-started-with-react-16/1.png)

It's been some time since Facebook released [React 16](https://reactjs.org/blog/2017/09/26/react-v16.0.html).

The new release has a lot of new features to facilitate the designing of robust components and enhancements to speed up the rendering pipeline.

React 16 is supposed to be completely backwards compatible with React 15. As stated in the official React 16 [blog post](https://reactjs.org/blog/2017/09/26/react-v16.0.html#upgrading) -

> If your app runs in 15.6 without any warnings, it should work in 16.

React 16 also ships with the new [MIT license](https://opensource.org/licenses/MIT). If you haven't followed the news as to why the React team has switched to the new license, be sure to read [this article](https://medium.freecodecamp.org/facebook-just-changed-the-license-on-react-heres-a-2-minute-explanation-why-5878478913b2).

Talking about it's stability, the React team has been serving the production build of React 16 to [Facebook](https://www.facebook.com/) and [Messenger](https://www.messenger.com/). Despite the new feature additions, it is 32% lesser in size as compared to the previous release.

Now without wasting any more time, let's talk about the features of React 16.

## Fragments and Strings

React 16 gives you the ability to return elements in an **array** from the render method.

![](/img/blogs/getting-started-with-react-16/2.png)

That means, for the most part, you wont be required to perform mapping of array elements inside your render methods. Simply return the array and it'll render just fine.

The only downside here is that it still expects a **key** value to be added to every array element in order to work.

I feel it's not that big of an issue, plus the React team has assured that the future release of React will most probably have this requirement removed.

Even **strings** and **numbers** can be returned from the render method now.

![](/img/blogs/getting-started-with-react-16/3.png)

Previous versions of React used to throw this error -

![](/img/blogs/getting-started-with-react-16/4.png)

Strings and numbers cannot be returned from the render method in React 15

As you can see, only valid React elements were allowed to be returned from the render method.

With React 16, the render method can return -

\- React elements  
\- Strings and numbers  
\- Portals  
\- Null  
\- Boolean expressions

**Strings** and **numbers** are rendered as regular **text nodes** in the DOM, and as you would've guessed, **null** renders nothing.

**UPDATE** : React 16.2 was released on November 28th, which has improved support for returning multiple children (aka Fragment) from a component's render method. More info on the same can be found on the official [blog post](https://reactjs.org/blog/2017/11/28/react-v16.2.0-fragment-support.html).

## Error Boundaries

Error Boundaries help you to catch run time errors in your app and allow you to render a fallback UI.

When an error occurred, previous versions of React used to leave your app in a broken state. In order to tackle this, React 16 provides a brand new lifecycle hook called **componentDidCatch**, which helps you to catch run time errors.

Error Boundaries capture errors **inside their subtree**, which means if an error occurs in any of the child components within that Error Boundary, then the componentDidCatch lifecycle method of that particular Error Boundary will fire.

![](/img/blogs/getting-started-with-react-16/5.png)

componentDidCatch returns two parameters - an **error** object which gives you the stack trace, and an **info** object, which gives the component stack data.

### How Error Boundaries work

![](/img/blogs/getting-started-with-react-16/6.gif)

Few things to note here -

Errors in **all lifecycle methods** can be caught by an Error Boundary, including the **constructor** method.

An Error Boundary cannot catch an error within itself.

If an Error Boundary fails for some reason, the error will propagate to the closest Error Boundary above it.

Here's an example on how to create and use an Error Boundary -

In the above example, when an error is thrown in the **Child** component (line no 17), the componentDidCatch lifecycle method of the **Parent** component fires (line no 33). Based on that, we change the state and render a fallback UI in it's place (line no 38).

### What happens when an error occurs ?

Once an error occurs, **error stack trace** and **component stack data** are logged to the console, and the component tree is unmounted from the root. This prevents from showing corrupted data to the user.

![](/img/blogs/getting-started-with-react-16/7.png)

![](/img/blogs/getting-started-with-react-16/8.png)

But is there really a need to unmount the whole React component tree ? Well, the React team has debated this decision, and in their experience it is worse to leave corrupted UI in place than to completely remove it. Read more about it [here](https://reactjs.org/blog/2017/07/26/error-handling-in-react-16.html#new-behavior-for-uncaught-errors).

## Portals

Portals let you render or teleport a child node into a different DOM node hierarchy.

![](/img/blogs/getting-started-with-react-16/9.png)

The first argument passed to a portal is a **child** component, which is any renderable entity (what the render method supports) and a **DOM node**, to which the child is mounted.

Portals can typically be used to render hovercards or modals, where the content is to be shown in a visually different and non-contained fashion, out of it's parent.

### How Portals work

![](/img/blogs/getting-started-with-react-16/10.gif)

How Portals work

The above illustration shows the process of creating a portal in order to render a **Text** component from DOM hierarchy 1, into DOM hierarchy 2 via the **modal** node.

The **Modal** component creates a portal which mounts the Text component to a different DOM hierarchy.

Here's the code for the above example -

### Event Bubbling in Portals

Event Bubbling in Portals works the same way as it does for normal React components regardless of it's position in the DOM tree.

An event fired from inside a portal will propagate to ancestors in the containing React tree, even if those elements are not ancestors in the DOM tree.

In this case, the button in the Modal component has no **onClick** handler, so once a user clicks on that button, the event propagates to it's ancestor in the component tree, and the **onClick** handler of that component fires.

## Custom DOM attributes

With React 16, you can pass custom attributes to your React components.

In the past, React used to ignore unknown DOM attributes. If you wrote JSX with an attribute that React doesn't recognize, React would just skip it. But React 16 allows them to be added to the component.

![](/img/blogs/getting-started-with-react-16/11.png)

![](/img/blogs/getting-started-with-react-16/12.png)

Note that you should still use the canonical React naming for known attributes -

![](/img/blogs/getting-started-with-react-16/13.png)

### Attributes whitelist

Previous versions of React used to have an attributes whitelist, which contained a list of attributes that React can recognize and allow them to be added to components.

![](/img/blogs/getting-started-with-react-16/14.png)

React 16 gets rid of this, so there's no more attribute matching with the whitelist resulting in smaller file sizes.

![](/img/blogs/getting-started-with-react-16/15.png)

![](/img/blogs/getting-started-with-react-16/16.png)

Custom attributes are handy if you need to use a non-standard attribute, or if you need to integrate with a third-party library that relies on such attributes. Just like before, React 16 also lets you use **data-** and **aria-** attributes with your components.

## New core architecture

React 16 has an entirely re-written architecture codenamed **Fiber**.

### Async rendering

The new core algorithm is completely backwards compatible and is based on a **priority scheduling** system. Events are streamed based on priority and are scheduled to be rendered by the browser, and this method does not block the main thread.

Events such as **typing** are considered to be high priority events, where the user needs to get realtime feedback, others such as ajax are considered low priority events.

The scheduling system makes heavy use of the **requestIdleCallback** API.

This method queues a function to be called during a browser's idle periods. This enables developers to perform background and low priority work on the main event loop, without impacting latency-critical events such as animation and input response.

In browsers where this API is not supported, React provides a polyfill.

If you want to know more about how Fiber works, I would definitely recommend you to check out this [talk](https://www.youtube.com/watch?v=ZCuYPiUIONs&index=5&list=PLb0IAmt7-GS3fZ46IGFirdqKTIxlws7e0) by Lin Clark, or read about the details in this [blog post](https://code.facebook.com/posts/1716776591680069/react-16-a-look-inside-an-api-compatible-rewrite-of-our-frontend-ui-library/) by the React team.

## Improved server-side rendering

The server-side renderer in React 16 has also been re-written. It is said to be **3x faster**.

It provides faster streaming of components down the wire, to the client.

The new packaging strategy (which is facilitated by the [Rollup module bundler](https://rollupjs.org/)) gets rid of **process.env checks**, which are really slow.

React 16 supports streaming of components via the new **[renderToNodeStream](https://reactjs.org/docs/react-dom-server.html#rendertonodestream)** API. Feel free to check out the [documentation of **ReactDOMServer**](https://reactjs.org/docs/react-dom-server.html) for more details.

One of the core React team members, Sasha Aickin, wrote a great [article](https://hackernoon.com/whats-new-with-server-side-rendering-in-react-16-9b0d78585d67) about React 16's SSR improvements.

As stated in the blog post -

> When comparing against React 15 with process.env compiled out, there's about a 2.4x improvement in Node 4, about a 3x performance improvement in Node 6, and a full 3.8x improvement in the new Node 8.4 release. And if you compare against React 15 without compilation, React 16 has a full order of magnitude gain in SSR in the latest version of Node!

![](/img/blogs/getting-started-with-react-16/17.png)

## Reduced file size

Despite all the new feature additions, React 16 is actually **smaller** as compared to 15.6.1!

![](/img/blogs/getting-started-with-react-16/18.png)

The size difference is partly attributable to a change in packaging. React now uses Rollup to create flat bundles for each of it's different target formats, resulting in both size and runtime performance wins.

## Installation

You can get started with React 16 right away, it's available on NPM and Yarn.

![](/img/blogs/getting-started-with-react-16/19.png)

Detailed installation instructions can be found [here](https://reactjs.org/docs/installation.html). Details on deprecations and breaking changes can be found [here](https://reactjs.org/blog/2017/09/26/react-v16.0.html#upgrading).

I also presented a talk on React 16 sometime back, you can check out the deck [here](https://speakerdeck.com/arunmichaeldsouza/getting-started-with-react-16), which was [retweeted](https://twitter.com/amdsouza92/status/919986205168513024) by Dan Abramov as well.

That's it for now! If you have any questions or suggestions, don't forget to leave a comment down below. Also, feel free to say hi 👋 to me on [Twitter](https://twitter.com/amdsouza92) and [Github](https://github.com/ArunMichaelDsouza).

Cheers!


Ramblings on web development, JavaScript, open source and tech in general.