DEV Community: Aaron Garvey

Size matters - Image Compression with Lambda and S3

Aaron Garvey — Fri, 12 Mar 2021 01:25:59 +0000

If you ever meet a developer who says size doesn't matter then you'd expect them to have one sizable cloud budget to work with! For everyone else though, size absolutely matters, especially when dealing with image storage on the cloud.

Almost every web application I have worked on over the few years has had some form of requirement for image hosting, be it a simple image gallery or user profile picture. So with the high availability of cloud storage options, and the low cost to stash away gigabytes of data, it's very easy for most of us to dismiss the any concerns about hosting data on the cloud. But we can all forget too easily when estimating our cloud storage budget that we're not just required to pay to store the total volume of our data in the cloud. But we also have to pay for each and every time our data needs to leave the cloud as well.

Lets imagine that we have an application that allows users to upload photos to use as their profile avatar. The user jumps onto their phone and grabs their latest insta/tinder-worthy pic and uploads this to our server. Lets assume that the image they upload is of decent quality and about 4mb in size. Now because our app is super awesome, we start going viral and land ourselves about 10,000 daily active users. Nice!

Now lets also imagine that each one of our 10,000 users uploaded the equivalent 4mb profile picture. Then we would be storing 40GB worth of profile pictures into our cloud storage. This isn't too bad when vendors like AWS are charging about $0.025AUD per GB of storage. We can handle that pretty well. But remember, we have 10,000 daily active users, and each time they access our app they will be loading 1 or many more other users profile pictures into their feed. This means our app will be dishing out at a minimum of 40GB of data per day -> 1200GB per month!

This is going to get expensive real fast!

Image Compression to the rescue!

Luckily for us, we live in a day and age where image compression and optimization is a walk in the park, and we can easily whittle our bloated users 4MB profile pic down to a nice couple of kilobytes, making a much nicer web friendly image. So over the next few steps I'll show you how you can quickly achieve a nice little image compression pipeline for your application built using a couple of S3 buckets, and a single Lambda function on AWS.

2 Bucket Image Compression Architecture

Our general processing pipeline will look something like this. At one end we have an application which allows users to upload profile images through to an S3 bucket. This bucket will only serve as a landing zone for the full resolution images provided by our user to be uploaded in to. We then setup our S3 bucket with a trigger to notify our Lambda function that a new image has arrived, and is ready to be compressed. Our Lambda function can then download the file from the source bucket, and using the Node.js Sharp package, we will shrink the image down to a more appropriate 200x200 avatar image size. The Lambda function will then save the transformed image into our second S3 bucket, which in turn will allow our app users to read in our compressed images, saving us a stack of data transfer fees.

Why two buckets?

You could absolutely get away with using just one bucket. But my personal preference is to use two buckets as a risk mitigation strategy against some dangerous, and extremely expensive recursive event loops. As you can see from the image below, with one S3 bucket our user would upload an image to our bucket. That bucket generates a notification out to our lambda function to compress an image. When the lambda function is finished, the image gets saved back into the bucket. Which in turn fires off another notification that a new image has been uploaded to the bucket, which fires off our lambda ... and so on and so on.

You get it. We could end up in a cycle where we are recursively compressing an image and that (speaking from experience) is one costly mistake (about $700 AUD per day for those interested!).

Single bucket trigger recursive event loop

Now if you really want to use a single bucket architecture, you could mitigate this risk by doing some smart things with object prefixes used for the S3 event trigger, or using metadata descriptors to help identify which objects should be processed. But by far the safest approach I know is to use two completely independent buckets where by one emits an event to compress an image, and the other simply receives compressed files. So this is the approach I will be demonstrating.

Building the Image Compression Pipeline

To make the setup and tear down of this application nice and quick, I have put everything together using an AWS SAM. Using SAM we can define and deploy our AWS resources using a nice yaml template, and the SAM CLI tools. If you're new to AWS SAM, I'd suggest taking some time to read up on it's functionality before pushing too much further ahead.

1. Create a new SAM project

First off we will create a new SAM project. Assuming you have the SAM CLI tools installed, the from the command line we can run



sam init

Stepping through the init options I've used the following for my project configuration.



Which template source would you like to use?
1 - AWS Quick Start Template

What package type would you like to use?
1 - Zip (artifact is a zip uploaded to S3)

Which runtime would you like to use?
1 - nodejs14.x

Project name [sam-app]: sizematters

2. Define the SAM template.yaml

Once SAM has initialized our project, we can step into our project directory and setup customize our template.yaml. This template holds all of our logic we will pass to AWS CloudFormation to setup and provision our S3 buckets, and Lambda function, and to configure the event notifications from S3.

Our finished template will look something like this



# <rootDir>/template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Size Matters image compression pipeline

Parameters:
  UncompressedBucketName:
    Type: String
    Description: "Bucket for storing full resolution images"

  CompressedBucketName:
    Type: String
    Description: "Bucket for storing compressed images"

Resources:
  UncompressedBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Ref UncompressedBucketName

  CompressedBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Ref CompressedBucketName

  ImageCompressorLambda:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/index.handler
      Runtime: nodejs14.x
      MemorySize: 1536
      Timeout: 60
      Environment:
        Variables:
          UNCOMPRESSED_BUCKET: !Ref UncompressedBucketName
          COMPRESSED_BUCKET: !Ref CompressedBucketName
      Policies:
        - S3ReadPolicy:
           BucketName: !Ref UncompressedBucketName
        - S3WritePolicy:
            BucketName: !Ref CompressedBucketName
      Events:
        CompressImageEvent:
          Type: S3
          Properties:
            Bucket: !Ref UncompressedBucket
            Events: s3:ObjectCreated:*

Walking through our template.yaml, from the top we have our Parameters block. These parameters will allow us to pass in some names for our S3 buckets when deploying our SAM template.

Next we have our Resources block. The first two resources referenced are the S3 buckets we will be created, named UncompressedBucket and CompressedBucket. One bucket will serve as the landing zone for our image uploads, and the other for the compressed image outputs. Both buckets then have their respective bucket names set from the parameters we previously defined.

Next within our Resources block we have our Lambda function ImageCompressorLambda. Within our function we will be using a Node.js runtime, and I have pointed the Lambda handler towards the src/index.hanlder location. We are passing in a couple of environment variables in the Environment section referencing both of our S3 buckets previously defined, to make life easier when building out our Lambda function logic. I have also attached a couple of the SAM helper policies under the Policies block, giving the lambda function the appropriate permissions to read data from the Uncompressed image bucket, and write data to the Compressed image bucket.

Lastly, we can configure our event trigger for our lambda function. The event structure used in this template is set to be fired any time an object is created within our Uncompressed S3 bucket. If you like, you can add additional rules and logic here to only fire events for certain file types, or object key prefix/suffixes. But again, in the name of simplicity for a demo, I've left this to handle all files, at any path.

3. Add Sharp as a dependency to Lambda

To do the heaving lifting of image compression and manipulation, we will be using the Node.js Sharp package. This is one mighty powerful library, and we will only be using a tiny element of it to shrink our image sizes. But I encourage you to explore their documentation and see all the possibilities on offer.

To setup our lambda function, we first need to add sharp as a dependency. Looking at the documentation provided by the Sharp team, we can see that in order to run Sharp on AWS Lambda, we need to make sure the binaries present within our node_modules are targeted for a Linux x64 platform, and depending on which OS we are installing the package from may result in some incompatible binaries being loaded. So to install sharp for our lambda, we can run the following from our project directory.



# windows users
rmdir /s /q node_modules/sharp
npm install --arch=x64 --platform=linux sharp

# mac users
rm -rf node_modules/sharp
SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm install --arch=x64 --platform=linux sharp

In short - this will hard remove Sharp from our node_modules if it exists, and provide an install dedicated to Linux x64 systems, best suited for AWS Lambda.

4. Setup the Lambda logic

With sharp now installed, we can configure our Lambda logic. Back in the template.yaml we defined earlier, we specified the lambda handler to exist at src/index.handler. So within our projects src folder, lets created an index.js file. Then we can use the following code snippet to build out our function logic.



// src/index.js
const AWS = require('aws-sdk');
const S3 = new AWS.S3();
const sharp = require('sharp');

exports.handler = async (event) => {

    // Collect the object key from the S3 event record
    const { key } = event.Records[0].s3.object;

    console.log({ triggerObject: key });

    // Collect the full resolution image from s3 using the object key
    const uncompressedImage = await S3.getObject({
        Bucket: process.env.UNCOMPRESSED_BUCKET,
        Key: key,
    }).promise();

    // Compress the image to a 200x200 avatar square as a buffer, without stretching
    const compressedImageBuffer = await sharp(uncompressedImage.Body)
    .resize({ 
        width: 200, 
        height: 200, 
        fit: 'cover'
    })
    .toBuffer();

    // Upload the compressed image buffer to the Compressed Images bucket
    await S3.putObject({
        Bucket: process.env.COMPRESSED_BUCKET,
        Key: key,
        Body: compressedImageBuffer,
        ContentType: "image"
    }).promise();

    console.log(`Compressing ${key} complete!`)

}

Stepping through the pieces, we first require in our AWS-SDK, S3, and sharp packages. We also define our general lambda handler function, passing in the event to operate with.



// <rootDir>/src/index.js
const AWS = require('aws-sdk');
const S3 = new AWS.S3();
const sharp = require('sharp');

exports.handler = async (event) => { 

   ...

}

Next, we can extract the image object key of the from the event that triggered the lambdas execution.



// <rootDir>/src/index.js

const { key } = event.Records[0].s3.object;

Using the AWS S3 SDK, we can then download the image to our lambda using the key previously collected. Note, that because we defined our environment variables back in our template.yaml for our lambda function, we can use process.env.UNCOMPRESSED_BUCKET to reference our Uncompressed bucket name.



// <rootDir>/src/index.js

const uncompressedImage = await S3.getObject({
        Bucket: process.env.UNCOMPRESSED_BUCKET,
        Key: key,
    }).promise();

Now, with the result of our downloaded image, we can pass the buffer data into sharp. Again, we are only making a very simple change here with sharp. We are shrinking the source image down to a 200x200 square, without stretching any of the image aspects to make a nice web friendly avatar image. You could do a lot more here like changing the compression level, or file type. But for this example, again we're keeping it nice and simple.



// <rootDir>/src/index.js

const compressedImageBuffer = await sharp(uncompressedImage.Body)
    .resize({ 
        width: 200, 
        height: 200, 
        fit: 'cover'
    })
    .toBuffer();

Then with the transformed image from sharp, we can take the response buffer and save that into our Compressed bucket. Because we are uploading this into our second bucket, I'm simply using the exact same key to save the file in the same relative location. So no need to worry about overwriting the original here.



// <rootDir>/src/index.js

await S3.putObject({
    Bucket: process.env.COMPRESSED_BUCKET,
    Key: key,
    Body: compressedImageBuffer,
    ContentType: "image"
}).promise();

With all the pieces put together, it's time to build and deploy our pipeline!

5. Build and Deploy

To build the project from the command line run



sam build --use-container

This will check your template.yaml is valid, and prepare the lambda function assets ready for uploading.

Once that is complete we can then run the following to push our build up to AWS.



sam deploy --guided

Stepping through the guided deployment options, we are given some options to specify our application stack name, region, and our parameters we defined within our template.yaml.



Setting default arguments for 'sam deploy'
        =========================================
        Stack Name [<your-stack-name>]:
        AWS Region [<your-aws-region>]: 
        Parameter UncompressedBucketName []: 
        Parameter CompressedBucketName []:

If all has gone to plan, you should be able to log into your console and see the two new buckets have been created, and your lambda function is ready to start crushing those image sizes!

6. Test it out

The easiest way to test out or new image compressing pipeline is to simply log into your AWS Console, and upload an image file into your Uncompressed bucket. This will fire off the notification event to our Lambda function to compress the image, and if all has gone to plan, you should be able to check your Compressed bucket and see your compressed file has been created.

From a quick test I ran, we can see that after uploading a 3MB full size image, we were able to shrink this down to just under 10KB. Awesome!

Original uncompressed image

Resulting compressed image

Recap

So going back to our application example. If we were so lucky to have 10,000 daily active users hitting our awesome application, which is now supported with a nice image compression and optimization pipeline, then we would still be having a solid 40GB of pictures being uploaded by the user base over a year. But by shrinking and compressing the images down to a more reasonable 10KB or smaller size, we are now able to stem our data out charges dramatically, changing our data out rate from a potential 40GB per day to around 100MB per day! That's a massive 400% decrease in data out! So I think it's fair to say, of course size matters!

^{^{Cover Photo by Galen Crout on Unsplash}}

Multi-env Next.js app with AWS Amplify & Serverless

Aaron Garvey — Tue, 16 Feb 2021 04:47:57 +0000

As an indie developer working on many different React applications there are a few things that I find really important, like

How fast can I setup my backend resources like databases, and authentication
How can I maintain multiple development and production environments for my applications, and
How fast can I ship updates out to clients

So when I reach for my development toolkit, for a long period of time AWS Amplify has been a hands down winner for me, allowing rapid multi-environment development of REST and GraphQL API's, database and object storage, authentication management. You name it, chances are Amplify can do it.

But lately there's been another aspect of the applications that I work on that is growing in importance every day.

That is the SEO friendliness, and overall performance of my app. We've all heard about bundling together bloated JS libraries, and the issues that search bots have crawling and indexing our apps. We also know that Next.js has come to the rescue with it's bag full of dynamic server side rendering goodness, automatic image optimization etc etc etc!

So lets solve all my main concerns and build an app with Next.js and AWS Amplify! Best of both worlds right?

Not so fast!

You see, AWS Amplify - although it can build and deploy a Next.js application, it can only do so if we are happy to use only statically generated pages. AWS Amplify just doesn't yet have the capabilities needed to deploy all the components required to work with Next.js' dynamic components. What this means is that out of the box we would have to either accept that when we build our Next.js application with AWS Amplify, we'd either build a static page that doesn't change with all data loaded in at build time, or build a static shell of a page, and continue to do all our data fetching on the client side for dynamic content.

That means no Next.js <Image /> component for automatic image optimization. No getInitialProps() for initial data fetching. No incremental static regeneration of pages, and so on, and so on...

If you ask me, that sounds a lot like going on a holiday but only to stay in the motel room... where's the fun in that!

In order to get the most out of Next.js with all the trimmings we need an alternative. One of which is the Serverless Framework. Serverless Framework offers many great yaml based templates that we can use to provision serverless applications to a cloud provider of your choice, including the Next.js Serverless plugin; a template that allows us to use all the cool stuff from Next.js in our very own AWS account.

That all sounds pretty nice!

But there's a catch!

So the serverless framework is really simple to get up and running. We can simply install the Serverless CLI, add a serverless.yml template to the root of our directory, run npx serverless - and then all the magic happens. The serverless framework builds and deploys our Next.js application out to Cloundfront backed by Lambda@Edge for a nice and simple AWS deployment.

But the Serverless Framework deployments are dependent upon the CLI being able to create a .serverless folder within your project, and having the contents of this folder persisted between builds. This isn't a roadblock for AWS Amplify - but a hurdle, as we don't necessarily want the AWS Amplify build server committing files into our repo after each build.

It also seems really annoying to have to manually deploy the application each time I make an update. It would be nice if instead AWS Amplify could deploy the Serverless components on each commit made to certain branches in my repo, and manage the Serverless components outputs between builds. To add to that as well, it would be even nicer to have multiple Serverless Next.js environments, and have each of them linked to in individual AWS Amplify backend environment.

So for my latest project I thought I'd see how hard it would be to get the best of both worlds and use the Next.js Serverless plugin to manage all the nice things of Next.js, and AWS Amplify to provision my backend resources and control the entire build process for the entire application.

Preface

To keep this brief, I'm going to assume you are familiar with provisioning an AWS Amplify application, or getting started with Next.js. There's plenty of great write up's on how to get started, and I'll provide links to some handy resources at the end if needed.

Lets get building!

Setting up the Serverless Next.js Plugin

Using the Serverless Next.js plugin is nice and simple. We can simply place a serverless.yml file like the one below into our project root, and assuming we have the Serverless CLI toolkit installed, we could run npx serverless to deploy our resources.

# serverless.yml

nextslsamplifyApp:
  component: "@sls-next/serverless-component@{version_here}"

If we were planning on just deploying single environment then using a single serverless.yml file would be just fine. For multiple environments however, it's easiest to create a separate serverless.yml template per environment we plan on provisioning, and making or environment specific changes within each template.

For this project in particular I plan on having a master branch which is linked to my prod backend resources, and a develop branch linked to all by dev backend resources. To setup the Serverless Next.js plugin to suit these environments, I've created a basic folder structure in the root of my application. At the top level I have an environments folders. Next level down, I have a folder for both the master, and develop branches of my project. Now inside each of these branch folders will contain its own serverless.yml templates.

<root>
- amplify
- environments
   |--master
      |--serverless.yml
   |--develop
      |--serverless.yml
- pages
- public
etc...

The changes between the master and develop templates I'm using are quite minimal, as I am only changing the subdomain used by each environment. So my develop branch will be deployed out to a dev subdomain, and the master branch will be deployed out to a www subdomain. The templates below show the extent of both of the configurations being used.

# master/serverless.yml
nextslsamplifyApp:
 component: "@sls-next/serverless-component@{version_here}"
 inputs:
  domain: ["www", "<your-domain-name>"]
  nextConfigDir: "../../"

# develop/serverless.yml
nextslsamplifyApp:
 component: "@sls-next/serverless-component@{version_here}"
 inputs:
  domain: ["dev", "<your-domain-name>"]
  nextConfigDir: "../../"

One important thing to highlight here is the use of the nextConfigDir in both of the Serverless template files. By default, the Serverless framework expects that our serverless.yml template is located at the root of the project. In the event that we store our serverless.yml template somewhere else, like in our environments/${branch} sub-folder, then we can use the nextConfigDir parameter to inform the Serverless Framework where our project root is in relation to the current template.

Persisting Serverless Build Files

Each time we use the Serverless CLI to build our Serverless components, the framework will produce a .serverless folder next to our serverless.yml template with a group of files referencing the specific deployment details of the build. These files are then later referenced by the Serverless Framework upon subsequent builds to update and add to existing resources. So we need a way to capture these files and persist them somewhere accessible to our AWS Amplify build server.

To address this, we can set up an S3 bucket that will store these resources after each build has been completed. For this project, I've created an S3 bucket and placed inside a couple of folders just like our serverless environments folders, named after each branch within the project.

s3://<your-bucket-name>/master/.serverless/
s3://<your-bucket-name>/develop/.serverless/

Inside each of my branch folders, I've also gone ahead and created an empty .serverless folder, which is where our output files from the Serverless component will be stored, and retrieved from for each build performed.

Prepare AWS Amplify build settings

The last step in our process is to finally configure the build settings used by AWS Amplify for our deployment. To achieve this AWS Amplify allows us to create an amplify.yml build spec file within the root of our project. When we commit the file through to our branches, AWS Amplify will use this to override the default build instructions.

The amplify.yml template allows us to break our build processes down into backend and frontend resources, each with their own respective preBuild, build, and postBuild steps. You can get as advanced as you'd like with the build configuration here, but for my project I aimed to keep it as simple as possible with the final amplify.yml taking on a structure like this.

# amplify.yml
version: 1
backend:
  phases:
    build:
      commands:
        # Provision the relevant AWS Amplify resources like Auth etc.
        # dependent on which branch we are currently building
        - amplifyPush --simple
frontend:
  phases:
    preBuild:
      commands: 
        - npm ci
        # Install the Serverless Framework CLI
        - npm i -g serverless
        # Copy any existing files from a previous Serverless deployment into our working directory
        - aws s3 cp s3://<your-bucket-name>/${AWS_BRANCH}/.serverless ./environments/${AWS_BRANCH}/.serverless/ --recursive
    build:
      commands: 
        # Move into the target Serverless env folder, and deploy the Serverless component 
        - cd ./environments/${AWS_BRANCH} && serverless
    postBuild:
      commands:
        # Copy the updated .serverless folder files and contents out to s3 for referencing in future builds
         - aws s3 cp .serverless/ s3://<your-bucket-name>/${AWS_BRANCH}/.serverless --recursive
  artifacts:
    # IMPORTANT - Please verify your build output directory
    baseDirectory: ./
    files:
      - '**/*'
  cache:
    - node_modules/**/*

Lets walk through these instructions step by step.

First we issue Amplify our backend build instructions. Here I am using the built-in AWS Amplify helper script amplifyPush --simple to automatically provision the correct AWS Amplify backend environment with the associated branch. So assuming I have linked my prod AWS Amplify resources to my master branch, this will ensure I never accidently push out my dev backend resources to my production app frontend.

# amplify.yml
version: 1
backend:
  phases:
    build:
      commands:
        # Provision the relevant AWS Amplify resources like Auth etc.
        # dependent on which branch we are currently building
        - amplifyPush --simple

With the backend taken care of by AWS Amplify, we can then setup a clean environment for building our front end with npm ci, and also install the Serverless CLI tools with npm i -g serverless. Then up we can use the AWS CLI commands to interact with our S3 bucket we created earlier to copy down any existing files from our .serverless folder that may have been generated from previous builds.

# amplify.yml
    preBuild:
      commands: 
        - npm ci
        # Install the Serverless Framework CLI
        - npm i -g serverless
        # Copy any existing files from a previous Serverless deployment into our working directory
        - aws s3 cp s3://<your-bucket-name>/${AWS_BRANCH}/.serverless ./environments/${AWS_BRANCH}/.serverless/ --recursive

You'll see here I'm using one of the default environment variables from AWS Amplify ${AWS_BRANCH}. So depending on which environment AWS Amplify is building, our build file will be updated with the exact name of the branch we are currently working with.

With our files all in sync, we can then kick off the build process. Building out the Serverless component is as simple as a quick cd into our target environment folder, and then calling serverless. Again, we can use the ${AWS_BRANCH} environment variable to make sure we switch into the correct branch for each build.

# amplify.yml
    build:
      commands: 
        # Move into the target Serverless env folder, and deploy the Serverless component 
        - cd ./environments/${AWS_BRANCH} && serverless

Once our build has completed, we then need to collect any output files generated to the local .serverless folder and store them back into S3 for future use.

# amplify.yml
    postBuild:
      commands:
        # Copy the updated .serverless folder files and contents out to s3 for referencing in future builds
         - aws s3 cp .serverless/ s3://<your-s3-bucket>/${AWS_BRANCH}/.serverless --recursive

And finally, handle any specific artifacts to output, or cache any additional files.

  artifacts:
    # IMPORTANT - Please verify your build output directory
    baseDirectory: ./
    files:
      - '**/*'
  cache:
    - node_modules/**/*

With all these pieces now put together and assuming auto-builds have been enabled with AWS Amplify, now any subsequent push to either the develop or master branches should kick off a new build process in AWS Amplify, provisioning out the AWS Amplify backend resources, along with the Serverless Next.js plugin components! Our .serverless resources are being successfully persisted within S3, and ready to be referenced for any future builds.

So despite AWS Amplify not supporting many of Next.js features out of the box yet, with a couple of tweaks to the build process, and a little help from the Serverless Framework, there's no reason we can't have the best of both worlds from Next.js and AWS Amplify!

Additional Resources:

Clean Code with React Context

Aaron Garvey — Mon, 01 Feb 2021 03:31:50 +0000

Over the holidays I had some time up my sleeve and decided to give Uncle Bob's Clean Code a thorough read through to see what, if any principles of clean code architecture can be applied to some of the React projects I've been working on.

Not too far into the book, Uncle Bob starts talking about the total number of parameters that a function could take as inputs before it no longer appears 'clean'. The aim here is to make sure that the functions we write as developers are easy to read, and logical to use. So the argument is that having to input 3 or more parameters for a given function increases the complexity of the function, slowing down the speed in which a developer can read and understand its purpose, as well as increasing the risk of incorrect usage (especially for the vanilla JS / non-typescript projects out there).

This sparked me into thinking about how I regularly handle user alerts within my React applications, and how perhaps a little help from Uncle Bob I could clean my code up a little.

The Original Approach

So here's what we are working on. A simple React application with an AlertContext component that wraps the entire application. This AlertContext component would control the state of alerts generated, and render out a snackbar/toast style alert object at the bottom of the screen.

Because this component uses Reacts Context each of the child components within the AlertContext provider would have the ability to use the alert context and generate success, warning, or error alerts for the user as needed. To keep things simple, I'm just using three buttons in their own component. Each of which generates a different type of alert.

Here's a snapshot of the original AlertContext component.

// AlertContext.tsx
import React from "react";
import Snackbar from "@material-ui/core/Snackbar";
import MuiAlert from "@material-ui/lab/Alert";

...

const AlertContext = React.createContext<IAlertContext>({
  setAlertState: () => {}
});

const AlertProvider: React.FC = ({ children }) => {
  const [alertState, setAlertState] = React.useState<IAlertState>({
    open: false,
    severity: "success",
    message: "Hello, world!"
  });

  const handleClose = (e: React.SyntheticEvent) => {
    setAlertState((prev) => ({ ...prev, open: false }));
  };

  return (
    <AlertContext.Provider value={{ setAlertState }}>
      {children}
      <Snackbar open={alertState.open}>
        <MuiAlert onClose={handleClose} severity={alertState.severity}>
          {alertState.message}
        </MuiAlert>
      </Snackbar>
    </AlertContext.Provider>
  );
};

export { AlertContext, AlertProvider };

Here you can see I have a simple Alert being rendered using the Material-UI Snackbar, and MuiAlert components.

// AlertContext.ts
return (
    <AlertContext.Provider value={{ alertSuccess, alertError, alertWarning }}>
      {children}
      <Snackbar open={alertState.open}>
        <MuiAlert onClose={handleClose} severity={alertState.severity}>
          {alertState.message}
        </MuiAlert>
      </Snackbar>
    </AlertContext.Provider>
  );

This is then controlled by the alertState object which determines whether the alert is visible, the severity of the alert, and the message that should be displayed.

// AlertContext.ts
const [alertState, setAlertState] = React.useState<IAlertState>({
    open: false,
    severity: "success",
    message: "Hello, world!"
  });

The AlertContext component then provides access to the setAlertState method, allowing any child component that uses the AlertContext to show success, warning, and error type alert messages. For example, here we have a component with three buttons. Each of which when clicked will generate a different type of alert with a different message.

// AlertButtons.ts
import React from "react";
import { Button } from "@material-ui/core";
import { AlertContext } from "./AlertContext";

const AlertButtons = () => {
  const { setAlertState } = React.useContext(AlertContext);

  const handleSuccessClick = () => {
    setAlertState({
      open: true,
      severity: "success",
      message: "Successfull alert!"
    });
  };

  const handleWarningClick = () => {
    setAlertState({
      open: true,
      severity: "warning",
      message: "Warning alert!"
    });
  };

  const handleErrorClick = () => {
    setAlertState({
      open: true,
      severity: "error",
      message: "Error alert!"
    });
  };

  return (
    <div>
      <Button variant="contained" onClick={handleSuccessClick}>
        Success Button
      </Button>
      <Button variant="contained" onClick={handleWarningClick}>
        Warning Button
      </Button>
      <Button variant="contained" onClick={handleErrorClick}>
        Error Button
      </Button>
    </div>
  );
};

export default AlertButtons;

To show an alert we must first access the setAlertState method from our context provider.

// AlertButtons.tsx
const { setAlertState } = React.useContext(AlertContext);

We can now use this method inside of our onClick functions for each button, or inside any other function, we create. Here, any time a user clicks on the Success Button we will simply generate a success style alert with the message "Successful alert!"

// AlertButtons.tsx
const handleSuccessClick = () => {
    setAlertState({
      open: true,
      severity: "success",
      message: "Successfull alert!"
    });
  };

The cleaner approach

Honestly, there probably isn't much of a problem with the initial approach. Technically, the setAlertState method only requires one parameter... it just happens to be an object with three distinct properties. And if you look closely, you'd see that one of the properties, 'open', isn't actually changing each time we invoke it to show a new alert state. Still, this approach might be just fine if it's just me working on the project, and I understand how to call this method each time. But what if I collaborate with another developer? How clean does the method setAlertState(params: {...}) appear to a new set of eyes?

So my attempt at a cleaner approach then is to change the way we'd set a new alert from the AlertContext component. Instead of giving each of the child components direct access to the setAlertState function of the context, I will give instead provide access to 3 separate methods for each alert type being generated.

// AlertContext.tsx
type IAlertContext = {
  alertSuccess: (message: string) => void,
  alertError: (message: string) => void,
  alertWarning: (message: string) => void,
};

These methods will only take one single parameter, the message, and completely abstracts away the need to remember to set the alert state to open, and to utilize the correct severity type for the alert. Below you can see that we have created the 3 respective methods to alertSuccess(), alertWarning(), and alertError(). Each of which takes a simple message as its input, and internally each function will call setAlertState with the appropriate open state and severity type.

// AlertContext.tsx
import React from "react";
import Snackbar from "@material-ui/core/Snackbar";
import MuiAlert from "@material-ui/lab/Alert";

type IAlertState = {
  open: boolean,
  severity: "success" | "warning" | "error",
  message: string,
};

type IAlertContext = {
  alertSuccess: (message: string) => void,
  alertError: (message: string) => void,
  alertWarning: (message: string) => void,
};

const AlertContext = React.createContext<IAlertContext>({
  alertSuccess: () => {},
  alertError: () => {},
  alertWarning: () => {}
});

const AlertProvider: React.FC = ({ children }) => {
  const [alertState, setAlertState] = React.useState<IAlertState>({
    open: false,
    severity: "success",
    message: "Hello, world!"
  });

  const handleClose = (e: React.SyntheticEvent) => {
    setAlertState((prev) => ({ ...prev, open: false }));
  };

  const alertSuccess = (message: string) => {
    setAlertState({
      open: true,
      severity: "success",
      message: message
    });
  };

  const alertError = (message: string) => {
    setAlertState({
      open: true,
      severity: "error",
      message: message
    });
  };

  const alertWarning = (message: string) => {
    setAlertState({
      open: true,
      severity: "warning",
      message: message
    });
  };

  return (
    <AlertContext.Provider value={{ alertSuccess, alertError, alertWarning }}>
      {children}
      <Snackbar open={alertState.open}>
        <MuiAlert onClose={handleClose} severity={alertState.severity}>
          {alertState.message}
        </MuiAlert>
      </Snackbar>
    </AlertContext.Provider>
  );
};

export { AlertContext, AlertProvider };

Now back inside our button component, we no longer access the original setAlertState method. Instead, we can access our new alertSuccess(), alertWarning(), and alertError() functions.

const { alertSuccess, alertError, alertWarning } = React.useContext(
    AlertContext
  );

And then updating each of the respective onClick handlers to call the newly imported functions.

  const handleSuccessClick = () => {
    alertSuccess("Successfull alert!");
  };

  const handleWarningClick = () => {
    alertWarning("Warning alert!");
  };

  const handleErrorClick = () => {
    alertError("Error alert!");
  };

Was it worth it?

To me, the second approach does seem a lot cleaner and is something I'll more than likely stick with in the future. Using the second approach allows me to simply extend the AlertContext to include more severity types than I already have implemented without affecting my implementations throughout any child components. The second approach is surely much easier for any developer who stumbled across the codebase to understand the purpose and use of a method like alertSuccess(message: string) as opposed to a method called setAlertState(params: {...}).