DEV Community: Eric Jinks

Undo/redo state in React with event sourcing

Eric Jinks — Fri, 20 Jun 2025 00:00:00 +0000

In a recent technical interview, I was asked to implement undo/redo functionality for a canvas drawing app using Event Sourcing. I had never explored this concept before, so I am writing this post to learn about it and apply it in a React component.

So, what is Event Sourcing?

Event sourcing is a state design pattern in which state is not stored directly. Instead, all changes to state are captured as a sequence of immutable events, and current state is reconstructed by replaying these events.

The name "Event Sourcing" comes from the fact that events are the source of truth for the application's state. Rather than storing the current state directly, you "source" (derive) the state from a sequence of events.

In a basic sense, normal state management can be thought of as a single object:

const state = {
  x: 0,
  y: 0,
}

const setPosition = (x: number, y: number) => {
  state.x = x
  state.y = y
}

// State update A
setPosition(10, 20)

// State update B
setPosition(55, 75)

// Accessing the current state
state.x // 55
state.y // 75

Event sourcing will instead manage state as a sequence of events:

const events = []

const setPosition = (x: number, y: number) => {
  events.push({ type: 'setPosition', x, y })
}

// State update A
setPosition(10, 20)

// State update B
setPosition(55, 75)

// Events array includes the history of all state changes
// [
//   { type: 'setPosition', x: 10, y: 20 },
//   { type: 'setPosition', x: 55, y: 75 },
// ]

// We can directly access the latest state object
const state = events[events.length - 1]
state.x // 55
state.y // 75

// Or we can derive the current state by replaying the events
const state = events.reduce(
  (acc, event) => {
    if (event.type === 'setPosition') {
      acc.x = event.x
      acc.y = event.y
    }
    return acc
  },
  { x: 0, y: 0 }
)

What sort of things can we do with event sourcing?

Undo/Redo Functionality

Rather than storing full snapshots, you store user actions as events. Then we can undo or redo by moving the backward and forward in the event history.

Multi-user Collaboration

If multiple users edit shared state (e.g. Figma or Notion), recording user events provides a way to merge, reconcile, and audit edits.

Time-Travel Debugging

Tools like Redux DevTools implement a form of event sourcing. Actions (events) are stored and can be replayed to reproduce any application state.

Optimistic UI

You can immediately apply an event on the frontend (e.g. "CommentPosted") before the server confirms it, and reconcile later if needed.

Audit Trail & Replay

Some apps (e.g. finance, health) need traceable state histories. Event logs provide a complete, replayable, and auditable history of frontend interactions.

Implementing undo/redo in a React component with event sourcing

See a demo of this behaviour on the original post with undo/redo functionality. Or see the code on GitHub. Here are the key parts:

1. Event Types

Events represent actions that can happen, similar to Redux actions:

type CanvasAction = {
  id: string
  type: 'ADD_CIRCLE' | 'ADD_SQUARE'
  x: number
  y: number
  size: number
  color: string
}

2. Event Store

The store maintains both the event history and current position in that history:

type EventStore = {
  events: CanvasAction[]
  historyIndex: number // Tracks where we are in the timeline
}

3. Event Reducer

Handles adding new events and navigating through history. If we're not at the end of the history, we truncate the future events, starting a new set of events from this point.

const eventReducer = (
  store: EventStore,
  action: CanvasAction | UndoRedoAction
) => {
  switch (action.type) {
    case 'ADD_CIRCLE':
    case 'ADD_SQUARE':
      // Truncate future events if we're not at the end (branching)
      const truncatedEvents = store.events.slice(0, store.historyIndex)
      return {
        events: [...truncatedEvents, action],
        historyIndex: store.historyIndex + 1,
      }
    case 'UNDO':
      return { ...store, historyIndex: Math.max(0, store.historyIndex - 1) }
    case 'REDO':
      return {
        ...store,
        historyIndex: Math.min(store.events.length, store.historyIndex + 1),
      }
  }
}

4. State Reconstruction

Current state is derived by reducing over the event list up to the current history index.

In more complex systems, this process can be optimised using snapshots, which are periodic captures of state that reduce the number of events needing to be replayed.

const getStateFromEvents = (events: CanvasAction[], historyIndex: number) => {
  const currentEvents = events.slice(0, historyIndex)
  return currentEvents.map((event) => ({
    id: event.id,
    type: event.type === 'ADD_CIRCLE' ? 'circle' : 'square',
    x: event.x,
    y: event.y,
    size: event.size,
    color: event.color,
  }))
}

The key insight used to implement this is that undo/redo simply involves moving the history index backward and forward, while the current state is always reconstructed from the events up to that index.

This approach naturally handles complex scenarios like branching, which occurs when you undo several steps and then perform a new action.

Schedule your Netlify build with GitHub Actions

Eric Jinks — Sat, 14 Sep 2019 03:49:54 +0000

If you host a site on Netlify, you may know about Build Hooks. By creating a build hook and sending a POST request to it, you trigger a new build & deploy for your site. If your build process is pulling in content from third-party services (e.g. Instagram, Youtube), scheduling a daily build & deploy can be an easy way to keep this content fresh.

The easiest way to setup a scheduled build hook trigger that I have come across is to use GitHub Actions. Setting this up is completely free if your repository if public. If your repository if private, you will most likely remain in their free tier, see pricing here.

Creating a scheduled Netlify build trigger GitHub Action

1 – Add a Build hook to your site using the Netlify Dashboard

(Settings > Build & Deploy > Continuous Deployment > Build hooks)

2 – In your GitHub repo, create a main.yml file in a .github/workflows directory:

   # .github/workflows/main.yml

   name: Trigger Netlify Build
   on:
     schedule:
       # Run at 0815 daily
       - cron: '15 8 * * *'
   jobs:
     build:
       name: Request Netlify Webhook
       runs-on: ubuntu-latest
       steps:
         - name: Curl request
           run: curl -X POST -d {} YOUR_BUILD_HOOK

Replace YOUR_BUILD_HOOK with the build hook url you just created.

You can use crontab.guru to easily generate your cron schedule.

3 – Open the Actions tab in you GitHub repo to watch the workflow trigger as per your cron schedule. 🎉

I hope this is useful to you! If you have any questions, I've created an example repository that uses GitHub Actions to build every 15mins:

Jinksi / netlify-build-github-actions

An example of triggering a Netlify build using Github Actions Scheduled Events

⏰ Trigger Netlify builds on a schedule using Github Actions

Add a Build hook to your site using the Netlify Dashboard

Settings > Build & Deploy > Continuous Deployment > Build hooks

Create a .github/workflows/main.yml file in your Github repo, replacing YOUR_BUILD_HOOK with the build hook you just created.

name: Trigger Netlify Build
on:
  schedule:
    - cron: '*/15 * * * *' # every 15 mins
jobs:
  build:
    name: Request Netlify Webhook
    runs-on: ubuntu-latest
    steps:
      - name: Curl request
        run: curl -X POST -d {} YOUR_BUILD_HOOK

Adjust the cron settings to determine how often the build will be triggered.
15 8 * * * would run every day at 0815
0 0,12 * * * would run at midday and midnight every day
crontab guru can help you generate the correct cron syntax.
See the Github Actions…

View on GitHub

Serverless R functions with Cloud Run

Eric Jinks — Mon, 02 Sep 2019 00:00:00 +0000

If you’re a JavaScript developer, using serverless functions can be a great way to create auto-scaling, cost-effective APIs. Any cloud provider who can host serverless functions will support JS and probably has solid workflows, allowing you to write the code and simply git push to deploy.

If you’re a developer or data scientist working with R, you are not so lucky! R is not natively supported on any of the major serverless cloud providers (yet). Thankfully, there is a solution that is beginning to gain traction with cloud platforms called Serverless Containers. I am using Google Cloud Run to host and manage serverless containers. Cloud Run provides a genorous ‘free tier’ so you can try it out without cost. It can be extended to utilise custom machine types, including GPU support, which can be critical if you are running Machine Learning tasks.

Serverless containers enable us to write code in any language and with any dependencies or libraries. We bundle up our functions into Docker containers, deploy them and pay only when they are running. If the function is getting hit with a spike in traffic, more containers will be spun up instantaneously to handle the workload and deallocated again once the task is complete.

Skip to the repo: Cloud Run with R – Hello World (GitHub)

R on the backend

In my case, I was using R to generate geospatial map data that would be rendered using a frontend React web app. I used the R library plumber to create a REST API, exposing https endpoints handled by functions defined in app.R.

To define endpoints with plumber, parameters are defined by decorating R functions with special comments.

The function below will accept POST requests with lat and lon data, returning geojson data:

# app.R

library(geojsonio)

#' Generates geojson containing 70 points surrounding central coordinate
#' @param lat latitude of central coordinate
#' @param lon longitude of central coordinate
#' @post /geojson
function(lat, lon){
  lat <- as.numeric(lat)
  lon <- as.numeric(lon)
  maxRange <- 0.1
  n <- 70

  # Generate data
  df <- data.frame(
    lat = runif(n, min = lat - maxRange, max = lat + maxRange),
    lon = runif(n, min = lon - maxRange, max = lon + maxRange),
    magnitude = runif(n, min = 0, max = 1)
  )

  # create geojson string from dataframe
  geojsonString <- geojson_json(df)

  # data to return
  geojsonString
}

print('app.R running')

server.R sets up the server to listen on a specific port. This also enables a Swagger interface for exploring the REST API.

# server.R

library(plumber)
# 'app.R' is the location of the file containing your endpoint functions
r <- plumb("app.R")
# get port number from environment variable
port <- strtoi(Sys.getenv("PORT"))
r$run(port=port, host='0.0.0.0', swagger=TRUE)

Defining a Docker container

A Dockerfile is used to define the Docker container requirements, install R libraries and start our server script.

# Use the official R image
# https://hub.docker.com/_/r-base
FROM r-base

# Create and change to the app directory.
WORKDIR /usr/src/app

# Copy local code to the container image.
COPY . .

# Install any R packages
RUN Rscript -e "install.packages('plumber')"

EXPOSE 8080

# Run the web service on container startup.
CMD ["Rscript", "server.R"]

If you have Docker installed locally, you can build and run this container using the following commands:

Build: docker build . -t 'cloudrun-r-helloworld'
Run: docker run -p 8080:8080 -e PORT=8080 cloudrun-r-helloworld

Deploying to Cloud Run

Now that we have out Docker container ready to go, let’s deploy our container to Cloud Run. There are a couple of ways we can do this, the Cloud Run Docs explains the manual way to deploy. To summarise, we tell Cloud Build to build the docker image and push it to Container Registry, then use this image to deploy a new revision to Cloud Run.

If you want to get a clone of my hello world example deployed on Cloud Run quickly, click this Cloud Run Button:

Take a look at the Cloud Run Button repo to create your own.

Continuous deployment with `git push`

Rather than manually deploying, I prefer to commit my changes to a Git repository and let deployment happen automagically.

We can use Google’s Cloud Build to automate the deployment of our container each time we push to a git repo. You will need to have your code in a git repo hosted on Github or another cloud git repository.

If you are running this for the first time, you may have to enable GCP Billing and APIs. See the Cloud Run Docs

To use Cloud Build we create a cloudbuild.yaml file and commit it to the repository root folder.

# cloudbuild.yaml

# Replace $PROJECT_ID with your GCP project ID
# Replace [SERVICE-NAME] with the desired Cloud Run service name (e.g. hello-world)
# Replace [REGION] with the GCP region you are deploying to (e.g. asia-northeast1)

steps:
  # build the container image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/[SERVICE-NAME]', '.']
    # push the container image to Container Registry
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/$PROJECT_ID/[SERVICE-NAME]']
    # Deploy container image to Cloud Run
  - name: 'gcr.io/cloud-builders/gcloud'
    args:
      [
        'beta',
        'run',
        'deploy',
        '[SERVICE-NAME]',
        '--image',
        'gcr.io/$PROJECT_ID/[SERVICE-NAME]',
        '--region',
        '[REGION]',
        '--platform',
        'managed',
        '--quiet',
      ]
images:
  - gcr.io/$PROJECT_ID/[SERVICE-NAME]

Now to create a Cloud Build trigger:

Go to the Cloud Build triggers page
Click Create Trigger
Select your repository
Select cloudbuild.yaml in Build Configuration
Click Create
Push a change to your repository
Monitor build progress in the Cloud Build console

Once this is setup, anytime you push to this repository, Cloud Build will build the Docker container and deploy a new revision to Cloud Run 🎉

Hello Cloud Run

Now that we have deployed our container to Cloud Run, we can sit back and be confident that our R functions will just work without having to manage servers, load balancing, etc. 🏖

In the Cloud Run console, we can map our service to a custom domain, increase service memory allocation, view logs and usage stats, etc. Cloud Run also offers a generous Free Tier for each month.

Thanks for reading! I hope I’ve helped to show you how to get started running serverless R in Cloud Run. Let me know if you found this post useful or have any questions, and feel free to share it!

More info:

Jinksi / cloudrun-helloworld-r

An example of creating serverless functions using R, plumber and Docker

Cloud Run with R – Hello World

⭐️ Read the blog post: Serverless R functions with Google Cloud Run ⭐️

An example of creating serverless functions using R, plumber, Docker and Cloud Run.

Take a look at the Swagger API UI at https://cloudrun-hello-r-tjf3c3jq4q-an.a.run.app/__swagger__/

File descriptions:

app.R describes the endpoints of the server and respective request handler functions
server.R sets up the server environment with plumber
Dockerfile describes the setup of the docker container used to run the app
cloudbuild.yaml sets up continuous deployment to Cloud Run, when commits are pushed to master