DEV Community: Frank Pierce

Short-Circuit Evaluation & Conditional Rendering in React

Frank Pierce — Wed, 25 Jan 2023 04:53:11 +0000

Conditional rendering in React is great, here’s a tip to make sure you don’t get caught out by Javascript’s short-circuit evaluation.

It works!

Ever tried to use conditional rendering to hide a component in React when a variable or expression is falsy? I do it all the time, but sometimes Javascript’s short-circuit evaluation catches me out. Let’s have a look:

{ randomVariableOrExpression &&
  <h1>Hello</h1>
}

The way we, or at least I, expect the above (and conditional rendering in general) to work is that if the variable/expression we evaluate is truthy, the component is rendered. And if it’s falsy, the component isn’t rendered.

Simple right?

We expect the behaviour I outlined above because it’s what happens 99% of the time. But there’s a catch.

Conditional rendering as outlined above functions because if the first value (randomVariableOrExpression) is falsy, the expression will short-circuit and simply return the falsy value.

React doesn’t render false, null, undefined, or true so nothing is rendered as expected, usually.

It Doesn’t Work?

However, if you were to write the below code where zeroVariable evaluates to the number 0 , React will render 0 in your application.

{ zeroVariable &&
  <h1>Hello</h1>
}

What? That’s not what you told it to do. You said, “If the value is falsy, render nothing”. This is where you either decide that React is broken and you’re the first one to notice (unlikely) or you’ve missed something.

What you’ve missed is that a logical expression which short-circuits is evaluated to the falsy value, not to false.

So in most cases, where the logical expression evaluates to false, null or undefined you’ll see what you expect as React doesn’t render these values.

But there are values which are falsy that React does render, namely 0 , -0 and NaN

I first encountered this issue when I attempted to conditionally render some elements depending on whether an array was empty. My code was:

{ array.length &&
    <div>
      array.map((item, i) => (
        <span>{ item }</span>
      ))
    </div>
}

That looked right to me. If the array has any items in it then array.length will be truthy and React will render my elements. If it’s empty then array.length is 0 which is falsy and React won’t render anything.

As I’m testing my application, I see 0’s rendered everywhere.

“What the heck”, I thought.

I eventually figured out what I just explained to you. This doesn't only apply to array lengths. A variable could have a value of 0 or NaN and unexpectedly render in your app.

Ohhh, It Works!!

As you may know, ! evaluates a value to true or false and inverts it.

!true == false
!false == true
!1 == false
!0 == true

Add a second ! and it’ll revert it to its original boolean value.

!!true == true
!!false == false
!!1 == true
!!0 == false

All you have to do is prepend your expression or variable with !! (that's two exclamation points to be clear).

{ !!zeroVariable &&
  <h1>Hello</h1>
}

This guarantees your falsy values (including 0 , -0 and NaN ) will resolve to false (and be ignored by React) while keeping any truthy values as true

If you'd like to get in touch, can find me at frankpierce.me or email me at frank.pierceee@gmail.com

Vanilla Service Workers in React

Frank Pierce — Wed, 18 Jan 2023 12:07:07 +0000

The following article explains how to make your React web application offline compatible and PWA compliant through Service Workers without using the countless libraries that are often prescribed, specifically how to cache files with dynamic names. If you’re in a rush, the secret is in Step 7.

I will presume that you have an understanding of what a Progressive Web Application (PWA) is and how Service Workers are used in PWAs. If you’re not familiar with these concepts (or need a refresher), I highly recommend the following resources:

Jake Archibald’s riveting talk on Progressive Web Apps and Service Workers

Web.dev’s Progressive Web App Tutorial

Mozilla’s Service Worker Documentation

If, like me, you marvelled at the features that Progressive Web Applications bestow then you likely immediately tried to integrate them into your projects.

The project that I decided to refactor into a PWA was a lightweight React web application which converts concert setlists into Spotify playlists. My main goal was to forge my application into a PWA which would display while the user is offline due to the service worker serving cached files.

Three attributes are required to qualify as a Progressive Web Application:

HTTPS — All PWAs must run on HTTPS as many core PWA technologies, such as service workers, require HTTPS.
manifest.json — Manifest.json files are required as they provide vital information to the browser regarding how it should behave when installed on the user’s desktop or mobile device. They contain data such as icon names, background colours, display preferences…
Service Worker — Service Workers are necessary for many of the prominent PWA features such as Offline First, Background Sync and Notifications.

Hosting your web application on HTTPS and writing a manifest.json file are both easy and well-documented processes.

And, while more technical, creating a Service Worker which caches files and serves them from the cache while the user is offline (and even online if the files are available) is reasonably straight forward too. Or, so I thought until I ran into cache-busting hashes.

Our Service Worker will have 3 purposes:

Cache the app’s static assets (HTML, CSS, JS, Fonts…) in the browser’s cache.
Delete old caches when a new version becomes available.
Intercept fetch requests and serve assets from the cache when available. Otherwise, fetch as normal from the network.

Step 1: Take the Red Pill

If you Google ‘How to make React App into offline-first PWA’, you’ll be bombarded with countless helpful articles and tutorials. Most, if not all, of these will tell you to install any number of libraries and external packages all of which require you to refactor much of your project to complete the task.

Now, I love libraries. They’re open-source, optimised, reliable code written by experts and provided to you for free.

However, the primary drive behind my development at the time was to learn. Sure I could import 5 npm packages, write a few lines of code and have a fully functioning PWA. But where’s the fun (or learning) in that?

Instead, let’s write our own Service Worker for React.

Step 2: Registering and Creating our Service Worker

React CRA provides your project with a file which creates and registers a service worker. If your project doesn't have it you can find it here.

You can write this yourself, as I have previously, but React’s template is excellent and allows us to focus on the fun stuff.

In your public folder, create a file called service-worker.js. This will be where all our service worker code goes.

Step 3: Caching Assets

For our application to function offline, we must cache all crucial static files. To do this we’ll create a cache name, an array of files to cache and an Event Listener which caches the files. My service-worker.js begins as below:

const CACHE_NAME = "spotlist-cache-v1";

const STATIC_ASSETS = [
  "/index.html",
  "/manifest.json",
  "/static/js/main.js",
  "/static/css/main.css",
  "/static/media/GTUltra-Regular.woff"
]

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => {
        cache.addAll(STATIC_ASSETS);
      }
    )
  );
});

We define a cache name with the CACHE_NAME variable. It’s preferable to include a version number here for reasons explained later.

We then create a STATIC_ASSETS array with the path to each of the files we want to add to our cache. Note that the above variable names are up to you.

Finally, we add an event listener to self which in this context is the service worker itself. We listen for the install event which is called when the service worker is finished installing. When the listener is triggered we do the following:

Find or create a cache with the name in CACHE_NAME
Add all of the files in STATIC_ASSETS to said cache.
Simple right? Now, whenever a user opens our application we’ll cache all of the files necessary for it to run offline.

Step 4: Removing Old Caches

I mentioned earlier that your cache name should include a version number (such as v1). If we a user visited our application, they’d cache our files and be stuck using them whether we changed the site’s content or not. That’s not ideal.

The solution is to purge old caches and create new ones whenever the files’ content changes. To do this we’ll change the CACHE_NAME version number each time we update the app’s content and create some logic which will delete caches that don't match the current version name.

self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cache => {
          if (cache !== CACHE_NAME) {
            caches.delete(cache);
          }
        })
      )
    })
  )
})

Akin to our previous logic, we add an event listener to our service worker and listen for the activate event. It is fired on the active service worker each time the page reloads. This is a perfect time to check if a new cache is available.

We call .keys() on cache to access an array of each cache name stored in the browser. We then map over each name and check if it matches the current CACHE_NAME. If it doesn't, we delete that cache.

Again, simple. But necessary.

Step 5: Serving from the Cache

Successfully storing our applications files in our users' cache is an achievement. Although a futile one if we cannot access them.

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => response || fetch(event.request))
  );
});

We intercept all network requests by listening for the fetch event. We then prevent the default fetch behaviour with event.respondWith() inside which we:

Check if the requested URL is in the cache — if it is, respond with it
If it isn’t we fetch from the network as usual

If you run a Lighthouse report on your application in Chrome Developer Tools you should find that it is now a verified Progressive Web App making it installable on phones, desktops and other devices directly from the browser:

Step 6: The Catch — Dynamic Filenames

That seemed far too easy. Why would anyone need external libraries? Remember when I said writing Service Workers seemed easy until I ran into cache-busting hashes? Well, that’s one of the main reasons developers will install a handful of libraries.

React, alongside almost all other asset pipelines, implements cache busting allowing users to receive the most recently updated files without having to perform a hard refresh or clear their browser cache.

React does this by adding hashes to the filenames it outputs. The files:

main.js
main.css
GTUltra-Regular.woff

Are renamed as below during the React build process:

main.7000985f.js
main.bb03239a.css
GTUltra-Regular.41205ca9d5907eb1575a.woff

While this is essential for cache busting, it throws a randomly generated wrench into our plans. We hardcoded the names of our files to be cached into service-worker.js

How can we account for randomly generated filenames?

I could abandon my mission to write my own React-compatible Service Worker and flee to the comfort of expertly crafted libraries such as Google’s Workbox.

Or I could find my own solution.

Step 7: The Solution

I turned to Google for help. I figured many others before must have run into the same issue. Predictably, I found a multitude of Stackoverflow questions, Reddit posts and GitHub issues on the subject. But none had anything resembling a concrete answer (other than to disable the cache busting hashes — something I hoped to avoid).

If you’re overwhelmed by the size of a problem, break it down into smaller pieces.

And so I did. Here are the smaller pieces I came up with:

React’s build process adds an unknowable hash to certain filenames.
Our Service Worker needs the name, hashes included, of each filename.
The Service Worker is written before the build process occurs.

Likewise, here are some facts I knew or found through research which may help us:

React’s build process creates asset-manifest.json. A file containing the paths of all generated assets, hashes included.
We can run scripts directly following React’s build process by appending them to the build command in package.json

So here’s the theory: we can write a script, which runs directly after the build process, that parses asset-manifest.json for the hashed filenames and modifies service-worker.js to include them in our filenames array.

Create a folder called scripts in your project root directory and inside it a file with the name of your choice; I called mine update-service-worker.js. Its content is the following:

const fs = require('fs');
const assetManifest = require('../build/asset-manifest.json');

const urls = Object.values(assetManifest.files).filter(name => !name.includes('.map'))

fs.readFile('build/service-worker.js', (error, content) => {

  const newContent = data.replace("%HASHURLS%", JSON.stringify(urls));

  fs.writeFile('build/service-worker.js', newContent, (error) => {
    error ? console.log(`Error: ${error}`) : console.log(`Success`)
  });
});

We import fs, Node’s filesystem module. We also import asset-manifest.js.

We use the Object.values() method on the asset manifests file object (where the generated file names are found) to retrieve an array of hashed filenames. We then filter through them to remove the source map files. You could leave these in and cache them if you wanted, but there’s little reason to.

Perfect, we’ve got an array of the hashed filenames. You can console.log(urls) here to verify this if you’d like.

Now, we simply need to add the hashed filenames to service-worker.js.

We read the contents of service-worker.js, then search the contents for %HASHURLS%, replace it with our hashed filenames and finally write this updated content back to service-worker.js.

Sounds like magic, right?

Well, that's simply because I haven’t told you about the changes we must make to service-worker.js to enable the above. Add the following just below where you have defined your STATIC_ASSETS array.

let CACHE_ASSETS = STATIC_ASSETS.concat(JSON.parse('%HASHURLS%'));

CACHE_ASSETS = new Set(CACHE_ASSETS);

CACHE_ASSETS = Array.from(CACHE_ASSETS);

This code is almost too simple to explain:

We concatenate our STATIC_ASSETS array with %HASHURLS% which represents, and will be replaced by, our array of hashed filenames.
We transform the resulting array into a set to remove duplicates.
And back into an array.

You’ll also need to change the STATIC_ASSETS variable name in the install listener to our new array: CACHE_ASSETS.

The final service-worker.js file should resemble the following:

const CACHE_NAME = "spotlist-cache-v1";

const STATIC_ASSETS = [
  "/index.html",
  "/manifest.json"
]

let CACHE_ASSETS = STATIC_ASSETS.concat(JSON.parse('%HASHURLS%'));

CACHE_ASSETS = new Set(CACHE_ASSETS);

CACHE_ASSETS = Array.from(CACHE_ASSETS);

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => {
        cache.addAll(CACHE_ASSETS);
      }
    )
  );
});

self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cache => {
          if (cache !== CACHE_NAME) {
            caches.delete(cache);
          }
        })
      )
    })
  )
})

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => response || fetch(event.request))
  );
});

The final step is to run the update-service-worker.js script.

Change the build command of your package.json file from:

"build": "react-scripts build"

"build": "react-scripts build && npm run update-service-worker"

and add an update-service-worker command:

"update-service-worker": "node scripts/update-service-worker.js"

Congratulations, you now have an offline compatible PWA without using a single external library.

Conclusion:

You don’t need external libraries to take advantage of the exceptional modern features of Service Workers, even when dealing with cache busting hashes in your dynamically generated filenames.

This is my novel approach to a problem I encountered without any obvious or documented solutions. If you have any suggestions on improvements or alternatives, I’d love to hear them.

You can find me at frankpierce.me or email me at frank.pierceee@gmail.com

Understanding Screen

Frank Pierce — Tue, 17 Jan 2023 04:00:41 +0000

The following article explains why you may need a tool like Screen and many of the common commands used with the popular terminal multiplexer. If you’re solely looking for the commands please feel free to skip to them.

Recently I was attempting to host the Node.js Backend of my Spotlist web application (which you can find it here). Having previously worked with AWS, I decided to host it on an AWS EC2 instance. I created, configured and spun up a Linux-based instance and with little hassle I was able to access my backend API from my client.

“That was easy”, I thought.

A couple of hours later I shut down my MacBook and closed all of the programs I had running, including all of the terminals that were open. One of those terminals was connected to my AWS EC2 instance as I had used it to install and run my Spotlist backend.

When I next tried to continue testing Spotlist, the backend was no longer responding to my API calls. By closing my terminal connected to the EC2 instance I had also terminated everything running on it, specifically my backend. Initially I thought I’d have to leave my terminal open and connected to the instance forever but almost instantly realised that wasn't practically possible. Instead I went in search of tools that would allow an EC2 instance to persist despite the SSH session being disconnected.

That’s when I found Screen.

Screen (or GNU Screen) is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.

In my own, hopefully more understandable, words: screen lets you create and run unlimited console applications, or consoles, in a single terminal. The reason it works for our particular issue is because programs on a screen session will continue to run even when the window is not visible and also when the whole screen session is detached from the users terminal.

This will allow me to create a screen on my EC2 instance, run my backend and close my terminal connected to the instance while knowing that my backend (or any other programs I chose to run) will continue.

Installation

Screen is installed on all major Linux distributions by default. You can verify this by running the following command.

screen -version

For full disclosure, my AWS instance is running version 4.01.

If screen is not installed on your device, you can run execute the following command to install it.

sudo apt install screen

Creating a screen

Starting a new screen session is as simple as typing the following command:

screen

We can now begin using this virtual terminal or screen and in my case, I simply ran my backend here.

Finding screens

We can theoretically create endless screens and therefore to view a list of all open screen sessions, we can use the following command:

screen -ls

I created several screens and ran the above command, here is the output:

The output tells us that there are 6 screen sessions. It gives us the name of each screen session and indicates whether it is attached or detached.

As the name indicates, attached means some process (for example your terminal) is using that screen session. On the other hand, detached means someone left the screen session running (and therefore didn’t terminate or kill it) but disconnected from it. A screen session being detached does not mean it is terminated or that any programs running on it are terminated, the programs will still run and the screen can be reattached to.

Attaching and detaching

If you open a terminal window, let's say in an AWS instance, and type screen to create a new screen as mentioned above you will be automatically attached to this screen. You can then run your desired program in the screen and when you want to disconnect from the screen (to close the terminal or open another screen session) you execute the following:

screen -d

Again, this does not kill the screen session or any programs running on it.

To re-attach to a screen session, you have a few options.

If you only have a single screen session running (but detached) you can attach to it with:

screen -r

You may have multiple screen sessions running as below:

To attach to a particular one you will need to execute the following command (where ‘9929.pts-0.ip-172–31–88–159’ is the screen name):

screen -r 9929.pts-0.ip-172–31–88–159

In fact, you don’t need to be this precise and can simply use the first character of the screen name as long as no other screen shares the same first character (in which case you can use the first two…). Therefore the below command would have the same effect:

screen -r 9

But what if you want to use a screen session as quickly as possible? The following command will connect to the first screen session available or create a new one if none exist:

screen -x -R

Naming a screen

Now you may like a name like ‘9929.pts-0.ip-172–31–88–159’, but I prefer a more colloquial name. Luckily Screen GNU allows us to name our screens. The below creates a screen with a custom name, in this case, ‘MyNickName’:

screen -S MyNickName

Terminating screens

If you ever need to terminate (or kill) all screen sessions, use:

killall screen

Want more?

This article only covers the basics of Screen and it’s most commonly used screen commands. For more commands please visit https://www.gnu.org/software/screen/

If you'd like to get in touch, can find me at frankpierce.me or email me at frank.pierceee@gmail.com