However, I wasn’t interested in the most used or known APIs. Instead, I was looking for the least known ones. I wanted to know which APIs we aren’t talking about enough, and among them, I found four pretty different APIs that are extremely useful:
In this article, we will see what they are, where we should use them, and how to use them.
The previous code works but not as intended. Since the
blur event is triggered when the page loses focus, it can be triggered when the user clicks the search bar, an alert dialog, the console, or the window border. So,
focus only tell us if the page is active but not if the content of the page is hidden or visible.
In general, we want to use the Page Visibility API to stop unnecessary processes when the user doesn’t see the page or, on the other hand, to perform background actions. Some specific cases can be:
The Page Visibility API brings two properties and an event to access the page visibility status:
npm packages and start the developer server:
Firstly, we will direct to the
/main.js file and delete all the boilerplate. Secondly, we will open
/index.html, and inside the
#app div tag, we will add a video element with any video file you want. I used a dancing Yoshi one. 🙂
/main.js, we will add an event listener to the
document object listening to the
visibilitychange event. We then can access the
document.visibilityState property to see when the page is visible or hidden.
If the user minimizes the window or switches the tab, the page would still fetch the quotes, creating an unnecessary network load. To solve this, we can check if the page is visible before fetching a quote.
Now, we will only fetch the quote if the page is visible to the user.
The Web Share API is also among the least-known APIs but is extremely useful. It lets you access the operative system’s native sharing mechanism, which is especially useful to mobile users. With this API, you can share text, links, and files without the need to create your own sharing mechanisms or use third-party ones.
They are pretty self-explanatory. You can use it to share content from your page to social media or copy it to the user’s clipboard.
The Web Share API gives us two interfaces to access the user’s sharing system:
To see how to use this API, we will recycle our prior example and make an option to share our quotes using the Web Sharing API. To start, we first have to make a share button in
We direct to
/main.js and select the share button from the DOM. Then, we create an
async function to share the data we want.
Now you can share your quotes with anyone through your native operative system. However, it is important to note that the Web Share API will only work if the context is secure, i.e., if the page is served over
Another API I want to talk about is the Broadcast Channel API. It allows browsing contexts to send and receive basic data from each other. Browsing contexts are elements like a tab, window, iframe, or anywhere a page can be displayed. Due to security reasons, communication between browsing contexts isn’t allowed unless they are of the same origin and use the Broadcast Channel API. For two browsing contexts to be of the same origin, they must share in their URL the same protocol (e.g.
http/https), domain (e.g.
example.com), and port (e.g.
The Broadcast Channel API is generally used to keep a page’s state synced across different tabs and windows to enhance user experience or for security reasons. It can also be used to know when a service is finished in another tab or window. Some examples are:
The Broadcast Channel API involves a
BroadcastChannel object that can be used to send messages to other contexts. Its constructor has only one argument: a string that will work as an identifier to connect to the channel from other contexts.
Once we have created a
BroadcastChannel object with the same identifier across two contexts, the new
BroadcastChannel object will have two available methods to start communicating:
To receive a message, the
BroadcastChannel has a
message event that we can listen to using an
addEventListener or its
onmessage property. The
message event has a
data property with the data sent and other properties to identify the context that sent the message, such as
Let’s see how to use the Broadcast Channel API by using our prior example. Our goal would be to make another browsing context with the same origin and display the same quote in both contexts. To do this, we will create a new folder named
new-origin with a new
/main.js files inside.
/new-origin/index.html will be a new HTML boilerplate with a
#quote div inside:
/new-origin/main.js file, we will create a new broadcast channel and select the
#quote element from the DOM:
And in our prior
/main.js file, we will create a new
BroadcastChannel object and connect it to the
"quote_channel". We will also modify the
getQuote function to send the quote as a message to other contexts.
Back in the
/new-origin/main.js file, we will listen to the
message event and change the
quote.innerHTML each time a new quote is sent.
When developing a web page or app, it’s extremely common to need to translate its content across other languages to reach a wider audience. However, just translating your page’s text to whichever language you need isn’t enough to make your content available to speakers of that language since things like dates, numbers, units, and so on are different across countries and may cause confusion to your users.
Let’s say you want to display the date “November 8, 2022” on your webpage like “11/8/22”. This data can be read in three distinct ways depending on the reader’s country:
This is where the Internationalization API (Or I18n API) comes to solve formatting issues across different languages and regions. The I18n API is an amazing tool that has several uses, but we won’t delve into them to not overcomplicate this article.
The I18n API uses locale identifiers to work. A locale identifier is a string that expresses the user’s language, country, region, dialect, and other preferences. To be precise, a locale identifier is a string that consists of subtags separated by hyphens. Subtags represent user preferences like language, country, region, or script and are formatted in the following way:
To be more precise, the I18n API provides an
Intl object that brings a bunch of specialized constructors to work with language-sensitive data. In my opinion, some of the most useful
Intl constructors for internationalization are:
For our example, we will focus on the
Intl.DateTimeFormat() constructor to format the quote’s
dateAdded property depending on the user locale. The
Intl.DateTimeFormat() constructor takes two arguments: the
locale string that defines the date formatting convention and the
options objects to customize how to format the dates.
Intl.DateTimeFormat() created object has a
format() method that takes two arguments: the
Date object we want to format and the
options object to customize how to display the formatted date.
Note: On the
options argument, we set the
timeZone property to
"UTC" so the date isn’t formatted to the user’s local time. In my case, the date is parsed to “10/23/2022” without the
As you can see, the
dateTime.format() changes the date depending on the locale’s date formatting convention. We can implement this behavior on the quotes’ date using the
navigator.language global property, which holds the user’s preferred locale. To do this, we will create a new function that takes a date string (in YYYY-MM-DD format) and returns the date formatted depending on the user’s locale.
We can add this function inside the
getQuote() function to parse the
With this, our quotes are localized to the user’s preferred language! In my case, my
navigator.language value is
"en", so my dates are formatted to MM/DD/YY.
I hope you liked this article and until the next time!