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, blur and 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:
When asked to select a framework, select vanilla to create a vanilla javascript project. And once finished, go to the new folder, install the necessary 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. 🙂
Back to /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 /index.html:
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 https:// or wss:// URLs.
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. :8080).
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 origin, lastEventId, source, and ports.
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 /index.html and /main.js files inside.
The /new-origin/index.html will be a new HTML boilerplate with a #quote div inside:
In the /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.
The 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 Intl.DateTimeFormat constructor’s 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 timeZone option.
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 dateAdded date.
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!
