DEV Community

Cover image for Navigating the Web: Unleashing is.firefox and is.not_firefox with 'thiis'
Ivan Karbashevskyi
Ivan Karbashevskyi

Posted on

Navigating the Web: Unleashing is.firefox and is.not_firefox with 'thiis'

Browsing the web is like embarking on a grand adventure, and every adventurer needs tools to navigate the vast landscape. In the realm of JavaScript, detecting the user's browser can be essential for crafting tailored experiences. Enter the is.firefox and is.not_firefox methods from the 'thiis' package. In this article, we'll embark on a journey to explore these methods and discover how they can add a sprinkle of magic to your web development quests.

Image description

The Firefox Magic in JavaScript

Before we dive into the wonders of browser detection, let's take a moment to appreciate the diversity of web browsers. Each has its quirks, and sometimes, knowing whether your user is exploring the web through Firefox can be quite handy.

Meet is.firefox - Your Firefox Whisperer

Documentation link

Picture this: you want to tailor a specific feature or experience for users on Firefox. The is.firefox method acts as your Firefox whisperer, confirming whether the user is indeed exploring the web with Firefox. Let's see it in action:

import { is } from 'thiis'; // Import the "is" object from the "thiis" package

if (is.firefox()) {
  console.log("You're riding the Firefox wave!");
} else {
  console.log("You're exploring with a different breeze.");
}
Enter fullscreen mode Exit fullscreen mode

In this example, we use the is.firefox method to check if the user's browser is Firefox. It's like having a browser-savvy guide on your adventure!

The Exploration of Examples

Now, let's embark on a quest through six diverse examples that showcase the magic of is.firefox and its counterpart, is.not_firefox. We'll even throw in an exciting scenario involving stream$ and an array adventure for good measure.

1. Feature Tailoring for Firefox Users

Imagine you want to provide an enhanced experience for Firefox users. You can use is.firefox to tailor specific features just for them:

import { is } from 'thiis';

if (is.firefox()) {
  // Apply special Firefox-only features.
  console.log("Enjoy the Firefox-exclusive feature!");
} else {
  // Provide the standard experience for other browsers.
  console.log("Exploring with a different breeze.");
}
Enter fullscreen mode Exit fullscreen mode

2. Alert for Non-Firefox Users

Perhaps you want to gently remind users to switch to Firefox for the best experience. is.not_firefox can help you send a friendly alert:

import { is } from 'thiis';

if (is.not_firefox()) {
  alert("Psst! For the best experience, try exploring with Firefox!");
} else {
  console.log("You're already enjoying the Firefox magic!");
}
Enter fullscreen mode Exit fullscreen mode

3. Browser Compatibility Checks

When working on a cutting-edge project, ensuring compatibility with various browsers is crucial. Use is.firefox to perform specific actions for Firefox:

import { is } from 'thiis';

if (is.firefox()) {
  // Execute Firefox-specific compatibility checks.
  console.log("Checking compatibility with Firefox.");
} else {
  // Continue with compatibility checks for other browsers.
  console.log("Compatibility checks for a different breeze.");
}
Enter fullscreen mode Exit fullscreen mode

4. Stream of Browser Whispers

Let's add a twist with an RxJS stream scenario. Suppose you have a stream of user actions, and you want to filter actions only for Firefox users. Here's how you can do it:

import { is } from 'thiis';
import { from } from 'rxjs';
import { filter } from 'rxjs/operators';

const userActions$ = from(['click', 'scroll', 'hover', 'click', 'scroll']);

userActions$
  .pipe(
    filter(() => is.firefox())
  )
  .subscribe(action => {
    console.log(`Firefox user performed: ${action}`);
  });
Enter fullscreen mode Exit fullscreen mode

In this example, the filter(() => is.firefox()) ensures that only actions from Firefox users are processed by the stream.

5. Array Adventure with Firefox Filter

Arrays can be another exciting terrain for is.not_firefox. Let's filter out actions specific to non-Firefox users:

import { is } from 'thiis';

const userActions = ['click', 'hover', 'click', 'scroll', 'hover'];

const nonFirefoxActions = userActions.filter(action => is.not_firefox());

console.log(`Actions from non-Firefox users: ${nonFirefoxActions.join(', ')}`);
Enter fullscreen mode Exit fullscreen mode

Here, is.not_firefox() is used to filter out actions from non-Firefox users, creating a new array of actions specific to other browsers.

6. Browser-Specific Styling

Styling can play a significant role in providing a seamless user experience. Use is.firefox to apply specific styles only for Firefox users:

import { is } from 'thiis';

const bodyElement = document.body;

if (is.firefox()) {
  bodyElement.classList.add('firefox-style');
  console.log("Styling tailored for Firefox users!");
} else {
  console.log("Standard styling for a different breeze.");
}
Enter fullscreen mode Exit fullscreen mode

In this example, the firefox-style class is added to the body element only if the user is on Firefox.

The Adventure Unfolds

The is.firefox and is.not_firefox methods from 'thiis' are your companions in the exciting realm of web development. They allow you to tailor experiences, send friendly alerts, and even filter streams based on the user's browser. By adding the 'thiis' package to your toolkit and exploring its documentation for more tips and examples, you can navigate the web with confidence and a touch of magic.

So, continue coding, and may your web adventures be filled with Firefox wonders!

🎗 ChatGPT & DALL·E 3

Top comments (7)

Collapse
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

There are other ways to deal with browser differences, easier and more resilient in my opinion.

Let's use speech recognition core API as example, in Chrome and Chromium family it's SpeechRecognition, in Safari you can use webkitSpeechRecognition, and the feature is not available neither in Firefox nor Opera.

const recognition = window?.SpeechRecognition || window?.webkitSpeechRecognition;

try {
  const recognition = new recognition();
} catch(error) {
  printBrowserNotCompatibleErrorMessage();
}
Enter fullscreen mode Exit fullscreen mode

This way your App will work in any browser that implements the feature later on with no changes required in the code.

TLDR; as a rule of thumb, check if the feature is available and act in consequence rather than coding different paths for each browser.

Regarding CSS I'd rather apply a reset at the very beginning in the situations where you cannot leave the defaults as is.

Best regards

Collapse
 
karbashevskyi profile image
Ivan Karbashevskyi

Hello,

using try {} catch {} for feature detection can be less efficient. A better approach is direct feature detection, like:

const recognition = window.SpeechRecognition || window.webkitSpeechRecognition;

if (recognition) {
  const recognitionInstance = new recognition();
} else {
  printBrowserNotCompatibleErrorMessage();
}
Enter fullscreen mode Exit fullscreen mode

Anyway, thank you for noting this aspect! I appreciate your attention to detail.

To enhance this process, consider discussing this issue on GitHub. Such a discussion would allow for a deeper exploration of the matter and the selection of an optimal method to determine whether the portal is open in the Internet Explorer browser. You can post your questions or discussions as an issue on GitHub so that the community can make decisions based on a thorough examination of the issue and the knowledge of participants.

Thanks again for your contribution and attention to detail!

Best regards!

Collapse
 
joelbonetr profile image
JoelBonetR 🥇

Hi! It's not a matter of efficiency (if that really matters in that context), it's about the constructor being available or not, if the feature is available but not the constructor (e.g. the feature is available through an Object) you'll have an unhandled exception.

I know that this is weird but there have been instances of that happening (not sure if any in the present nor that I want to discover them the bad way 😅)

Best regards

Thread Thread
 
karbashevskyi profile image
Ivan Karbashevskyi • Edited

If I understood you correctly, you are worried that the input data may not have a constructor that will allow you to check the data type. From the prepared tests, no such problems were detected, but if you know of certain cases when this can happen, then I ask you to help me figure it out, maybe these links will give you more information about how the commands are tested:

Link to prepared data for testing is.firefox:
github.com/Karbashevskyi/thiis/blo...

Links to tests is.firefox:
github.com/Karbashevskyi/thiis/blo...

In general, only 23 395 tests have been prepared for the package so far, if there is a desire, time and opportunity to improve or supplement it, I will be grateful!

Collapse
 
blindfish3 profile image
Ben Calder

It's not just your opinion: feature detection has been the preferred approach for a very long time!
Browser detection should always be a last resort; and the above article provides no valid justification for its use...

Collapse
 
joelbonetr profile image
JoelBonetR 🥇

I know I koow... 😅I just wanted to be polite as I understand the value of creating a library on your own to toy around and learn the details of stuff, even if it's not the best solution for anything (I've been there).

Now this can be an excuse to build more features into the library. Even if the OP eventually let it die, the value of the building process is still great 😃

Collapse
 
karbashevskyi profile image
Ivan Karbashevskyi

Telegram channel:
t.me/thiis_pkg

NPM:
npmjs.com/thiis