Forem: math

Spent a week looking for a clean undo/redo pattern. This is the one that stuck.

math — Sat, 04 Apr 2026 12:03:03 +0000

math

Apr 3

Time Travel for Your State: Undo/Redo Done Right (Part 1)

#react #redux #undo

Comments 1

3 min read

Time Travel for Your State: Undo/Redo Done Right (Part 1)

math — Fri, 03 Apr 2026 23:42:35 +0000

It’s probably my third day writing here. I’m not trying to keep a daily streak, but I get excited when I come across good code, so I end up wanting to share it right away.

Some background

At first, I thought undo/redo would be simple. That assumption lasted about 15 minutes.

In a personal project I’ve been working on, I spent the past week trying to find a clean, generic way to implement undo/redo without ending up with a bunch of hardcoded states. I wanted something that could manage itself instead of turning into a mess over time.

I’m glad to say I found two solid approaches. You can probably guess that from the title since this is Part 1 😄

In this part, I’ll walk through one approach that I found really elegant—the one recommended by Redux.

The idea

The core idea is simple. Instead of just storing your current state, you store a bit of history along with it.

{
  past: Array<T>,
  present: T,
  future: Array<T>
}

past → everything that came before
present → your current state
future → everything you’ve undone

Undo and redo then become operations where you just move state between these three.

Example: Todo list

Let’s walk through a simple todo list to make this concrete.

Start with an empty list:

past: []
present: []
future: []

Now you add a todo: "Buy milk"

past: [[]]
present: ["Buy milk"]
future: []

Add another todo: "Walk dog"

past: [[], ["Buy milk"]]
present: ["Buy milk", "Walk dog"]
future: []

Add one more: "Read book"

past: [[], ["Buy milk"], ["Buy milk", "Walk dog"]]
present: ["Buy milk", "Walk dog", "Read book"]
future: []

Now hit undo:

past: [[], ["Buy milk"]]
present: ["Buy milk", "Walk dog"]
future: [["Buy milk", "Walk dog", "Read book"]]

Hit undo again:

past: [[]]
present: ["Buy milk"]
future: [["Buy milk", "Walk dog"], ["Buy milk", "Walk dog", "Read book"]]

And if you redo:

past: [[], ["Buy milk"]]
present: ["Buy milk", "Walk dog"]
future: [["Buy milk", "Walk dog", "Read book"]]

This works because you’re not doing anything fancy—you’re just moving snapshots around.

Making it reusable

The really nice part is that this logic doesn’t have to live inside your reducer.

You can extract it into a reusable wrapper, or as Redux calls it, a reducer enhancer.

function undoable(reducer) {
  const initialState = {
    past: [],
    present: reducer(undefined, {}),
    future: []
  }

  return function (state = initialState, action) {
    const { past, present, future } = state

    switch (action.type) {
      case 'UNDO': {
        const previous = past[past.length - 1]
        const newPast = past.slice(0, past.length - 1)

        return {
          past: newPast,
          present: previous,
          future: [present, ...future]
        }
      }

      case 'REDO': {
        const next = future[0]
        const newFuture = future.slice(1)

        return {
          past: [...past, present],
          present: next,
          future: newFuture
        }
      }

      default: {
        const newPresent = reducer(present, action)

        if (present === newPresent) {
          return state
        }

        return {
          past: [...past, present],
          present: newPresent,
          future: []
        }
      }
    }
  }
}

Using it

You write your reducer like normal:

function todos(state = [], action) {
  switch (action.type) {
    case 'ADD_TODO':
      return [...state, action.text]
    default:
      return state
  }
}

Then wrap it:

const undoableTodos = undoable(todos)

And now it supports undo and redo out of the box:

store.dispatch({ type: 'ADD_TODO', text: 'Use Redux' })
store.dispatch({ type: 'ADD_TODO', text: 'Implement Undo' })
store.dispatch({ type: 'UNDO' })

One small gotcha

Since your state is now wrapped, you’ll need to access state.present instead of state.

You can also use:

past.length to know if undo is possible
future.length to know if redo is possible

Why this is nice

What I like about this approach is how composable it is. You can choose which reducers need undo and layer this on top without changing your existing logic.

Your original reducer stays untouched, and undo/redo becomes something you add, not something you bake in.

Also, if you don’t want to implement this yourself, redux-undo already does exactly this.

This article is heavily inspired by the official Redux documentation, so I’d definitely recommend checking that out as well.

In the next part, I’ll go into the approach I actually ended up using, and why it worked better for my setup. I haven’t written it yet, but I’ll link it here when I do.

Thanks for reading
Until next time, 👋

After a 6-month struggle, I think I found a browser to settle on after Arc.

math — Fri, 03 Apr 2026 21:02:05 +0000

math

Apr 3

I think I found a browser to replace Arc

#webdev #browser

Comments

4 min read

I think I found a browser to replace Arc

math — Fri, 03 Apr 2026 20:59:49 +0000

May 27, 2025 was probably one of the top 10 saddest days of the year for me. It was the day Arc announced they were stopping development. The blog post said "Please know this: we're not trying to shut Arc down" and like a kid whose parents say "we're separating but don't worry, everything will stay the same," I believed it.
But did it? Absolutely not.

To me Arc was about being able to customize fonts, themes, have spaces, live folders, route configurations where certain domains opened in specific spaces. It had live folders, pinned links for quick access- and made the browsing experience more organised. It had tab renaming, tab tidying through auto-grouping. Most of it technically still exists today, its just.. different? Is this a love letter to Arc? Maybe.

I tried sticking with it for 6 months. But Arc got bloated, memory management got bad, and the bugs got unbearable. There was this one bug where I'd hover over a tab, get the "double-click to rename" prompt, close the sidebar and it would just stay there. That was the thing that finally pushed me out.

So I went looking. I couldn't expect everything so I kept my requirements short - customisation, profiles, vertical tabs.

The Ones That Didn't Work Out

First stop was Dia, Arc's own successor. Obviously. It has profiles and vertical tabs but the customisation felt really limited, just a handful of color presets. And when I hit Cmd+Q to close a space it closed all of them. That was enough to not satisfy the requirements I started with, so I moved on.
I tried Orion, Opera GX, Zen. Either too buggy, too niche, or just not quite there. I tried going back to Chrome and I just couldn't do it after Arc. Eventually I gave up and landed on Safari for a bit. Stable, fast, fine.
Okay Drumroll 🥁
The browser I landed on is one I'd actually tried years ago and written off. I genuinely don't think you'll guess it.
Firefox
I know! But hear me out because Firefox today is really not the Firefox you remember.

Why It Actually Works

It's been around forever, quietly improving while everyone was distracted by Chrome. Here's what actually won me over.

When I opened it I instantly felt like something was different. The UI felt so much better than what it was years before. Everything felt more fun. Just look at the profile opening screen - it's genuinely delightful. This already felt more promising than anything else I'd tried.

Profiles work the way you'd want them to - separate themes, separate extensions, separate sessions, all properly isolated. Firefox even introduced the option to use vertical tabs.

Then there's Firefox Color, which is where the customisation really opens up. It's a Mozilla extension that lets you theme basically every part of the browser - toolbar, tabs, background, text, popups.

Firefox also allows you to override fonts in the websites which is another layer to customization, similar to what Arc provided, although Arc provided limited fonts in "Boosts" and this is more granular control.
Its only been 4 days since I began using it, and it seems good so far. It even handles the command Q to quit a profile that Dia wasnt handling.

What's Still Missing

Its not a perfect replacement for sure.
Some features from Arc don't have clear equivalents in Firefox yet: automatic tab tidying (grouping and archiving), tab renaming, screen sharing as a pinned tab, routing links to spaces and live folders.
It's only been a few days, but so far it's been good. And since Firefox is open source, I'm already thinking about building an extension for at least some of these. I'll follow up if I do - so follow me if you want to hear how that goes. If I missed anything, and you know any alternate browser, or an extension that might help, let me know in the comments.
Leaving you with a bunch of screenshots of my customised my profiles:

Until next time 👋

Building a sidebar with React dnd-kit

math — Thu, 02 Apr 2026 22:16:36 +0000

I've been working on a note-taking application, and part of that involved building a sidebar with drag-and-drop support.
The requirements were fairly straightforward:

Notes should be nestable (drag one into another)
A pinned section at the top
Drag interactions shouldn't interfere with normal clicks for file selection

After looking around, I went with dnd-kit since it's actively maintained and widely recommended.
While the official documentation is good, there were a few gaps I had to figure out while integrating it into a real project, especially around TypeScript and some of the interaction patterns. This post covers the parts that weren't immediately obvious.
Here's a reference to the sidebar so the rest of the article has some context:

Choosing the right package

First things first, the version. I'm using @dnd-kit/react@0.3.2, which is the newer React-specific package and not @dnd-kit/core. Most tutorials, Stack Overflow answers, and examples online are still based on the older package. The APIs are similar enough to feel interchangeable, which can be misleading. You'll often think you're following the right approach, only to spend a lot of time debugging why things aren't working as expected.

Working with IDs

Everything in dnd-kit revolves around IDs. They're the link between what you render in the UI and what you receive in drag events.
In this sidebar, IDs are used to distinguish between dropping on a section versus dropping on another note. That distinction is what drives the actual behaviour, pinning, moving to root, or nesting.
Static IDs are for the fixed drop zones that always exist in the UI:

export const DROPPABLE_NOTES_SECTION_ID = 'notes-section';
export const DROPPABLE_PINNED_SECTION_ID = 'pinned-section';

Dynamic IDs are per note, using the note's own ID from your data model. This is what lets notes act as both draggable items and drop targets at the same time:

useDraggable({ id: note.id });
useDroppable({ id: note.id });

Draggable and droppable elements

Since each note needs to support both dragging and receiving drops, you end up attaching both hooks to the same element. Both hooks return a ref, so you rename them to avoid the collision and combine them into a single callback ref:

const { ref: draggableRef } = useDraggable({ id: note.id });
const { ref: droppableRef } = useDroppable({ id: note.id });

const combinedRef = (el: HTMLElement | null) => {
  draggableRef(el);
  droppableRef(el);
};

<div ref={combinedRef}>
  {node.name}
</div>

This pattern ensures a note can be dragged while still acting as a valid drop target for other notes.
Setting up the provider
All drag and drop interactions live inside DragDropProvider. It's also where you wire up your event handlers:

<DragDropProvider
  onDragStart={onDragStart}
  onDragEnd={onDragEnd}
  onDragOver={onDragOver}
>
  {/* content */}
</DragDropProvider>

The main behaviour is defined in onDragEnd. This is where you decide what happens after the drag event completes.

const onDragEnd: OnDragEnd = (event) => {
  const sourceId = event.operation?.source?.id;
  const targetId = event.operation?.target?.id;

  if (!sourceId || !targetId) return;
  if (sourceId === targetId) return;

  if (targetId === DROPPABLE_PINNED_SECTION_ID) {
    setPin.mutate({ nodeIds: [sourceId], isPinned: true });
    return;
  }

  if (targetId === DROPPABLE_NOTES_SECTION_ID) {
    moveNodes.mutate({ nodeIds: [sourceId], newParentId: null });
    return;
  }

  moveNodes.mutate({ nodeIds: [sourceId], newParentId: targetId });
};

At its core, we just compare the source and target IDs and mapping that to the appropriate action.

Gotchas

Typing event handlers in TypeScript

While dnd-kit exposes event types like DragEndEvent, using them directly didn't work in my case. Inferring them from the component props turned out to be more reliable:

import { type ComponentProps } from 'react';

type OnDragEnd =
  NonNullable<ComponentProps<typeof DragDropProvider>['onDragEnd']>;

Same pattern works for onDragStart and onDragOver

Preventing drag from interfering with clicks

By default dnd-kit starts a drag on pointer down, which makes simple clicks feel unreliable in a sidebar. The fix is activation constraints on the PointerSensor, so a drag only starts after the pointer actually moves:

import { PointerActivationConstraints } from '@dnd-kit/dom';
import { PointerSensor, KeyboardSensor } from '@dnd-kit/react';

const sensors = [
  PointerSensor.configure({
    activationConstraints: [
      new PointerActivationConstraints.Distance({ value: 6 }),
    ],
  }),
  KeyboardSensor,
];

<DragDropProvider sensors={sensors} ...>

value: 6 means the pointer has to move 6 pixels before dnd-kit treats it as a drag. Anything less and it fires as a normal click. I tried a few values between 4 and 10 and 6 felt the most natural.

The drag overlay (optional but a good add)

By default, dnd-kit moves the original element during a drag. In a tightly structured layout like a sidebar, this can lead to unwanted visual shifts. DragOverlay lets you render a separate preview that follows the cursor instead, and you have full control over what it looks like:

<DragOverlay>
  {activeDragNodeId ? (
    <div className="rounded-xl border bg-white px-2 py-1 text-xs shadow-md">
      {nodes.find(n => n.id === activeDragNodeId)?.name ?? 'moving note'}
    </div>
  ) : null}
</DragOverlay>

This keeps the layout stable and makes the whole drag feel intentional rather than like you're wrestling with the UI.

Wrapping up

I'm not sure if this is the "right" way to do it, but it worked well for my use case. If you have a better approach, I'd love to hear it. Let me know if you'd like the GitHub link, this was part of a personal project, but I can put together a simplified version to share.
I'm just starting to write, so I'd love any feedback on what I can do to make it better!
Until next time 👋

[Solved] AWS Resource limit exceeded

math — Fri, 10 Jan 2025 17:53:43 +0000

TL;DR:

While deploying an OpenSearch domain with logging via CDK, I hit a “Resource limit exceeded” error due to more than 10 resource access policies for CloudWatch log groups. To fix this, I created CloudWatch log groups in CDK and passed their ARNs to a Lambda function. In the Lambda, I used the AWS SDK’s putResourcePolicy to update the existing policy with OpenSearch as the principal and attached the log group ARNs. I also set suppressLogsResourcePolicy: true in OpenSearch to stop CDK from creating resource policies automatically. This bypassed the limit and gave me full control over the policies.

Introduction

While deploying my CDK stack for OpenSearch with logging enabled, I encountered this error:

Received response status [FAILED] from custom resource. Message returned: Resource limit exceeded.

This error occurs when attempting to create more than 10 resource access policies for CloudWatch. Finding a solution wasn't straightforward, especially since there weren't many resources addressing this specific issue. Let me share how I resolved it.

P.S. This works for updating existing resource policies for any service and is NOT specific to OpenSearch — just skip the last step.

The Solution

Step 1: Create Log Groups required

First, I created the necessary CloudWatch log groups with appropriate naming and retention policies:

this.opensearchAppLogGroup = new logs.LogGroup(this, `${props.id}-opensearch-app-loggroup`, {
    logGroupName: `/aws/opensearch/app`,
    removalPolicy: props.domainRemovalPolicy,
});

this.opensearchSlowIndexLogGroup = new logs.LogGroup(this, `${props.id}-opensearch-slowIndex-loggroup`, {
    logGroupName: `/aws/opensearch/slow-index`,
    removalPolicy: props.domainRemovalPolicy,
});

this.opensearchSlowSearchLogGroup = new logs.LogGroup(this, `${props.id}-opensearch-slowSearch-loggroup`, {
    logGroupName: `/aws/opensearch/slow-search`,
    removalPolicy: props.domainRemovalPolicy,
});

Step 2: Set Up Lambda to Update the Existing Resource Policy

Implementing the SDK inside CDK was a gamechanger for me. I wrote a Lambda function that checks for existing CloudWatch resource policies, adds missing log group ARNs, and updates or creates a statement allowing OpenSearch (es.amazonaws.com) to access the log groups. It then applies the updated policy using put_resource_policy to ensure OpenSearch has the correct permissions.

import json
import boto3
import os

cloudwatch_logs = boto3.client('logs')

def handler(event, context):
    policy_name = os.environ.get('POLICY_NAME')
    new_resources = os.environ.get('LOG_GROUP_ARN', None)

    if isinstance(new_resources, str):
        new_resources = new_resources.split(',')
    else:
        new_resources = []


    try:
        response = cloudwatch_logs.describe_resource_policies()
        # Check if the specified policy exists
        existing_policy = next(
            (policy for policy in response.get('resourcePolicies', [])
             if policy.get('policyName') == policy_name), 
            None
        )

        if existing_policy:
            policy_document = json.loads(existing_policy['policyDocument'])
        else:
            print('Policy not found. Creating a new policy.')
            policy_document = {
                "Version": "2012-10-17",
                "Statement": []
            }

        new_resources_str = [str(resource) for resource in new_resources]

        existing_policy_document_str = json.dumps(policy_document)

        resources_to_add = []

        for new_resource in new_resources_str:
            if new_resource not in existing_policy_document_str:
                print(f"New resource {new_resource} not found, adding it.")
                resources_to_add.append(new_resource)

        if resources_to_add:
            es_statement = next(
                (stmt for stmt in policy_document['Statement']
                 if stmt['Principal'].get('Service') == 'es.amazonaws.com'), 
                None
            )

            if es_statement:
                if 'Resource' not in es_statement:
                    es_statement['Resource'] = []
                es_statement['Resource'].extend(resources_to_add)
            else:
                es_statement = {
                    "Effect": "Allow",
                    "Principal": {
                        "Service": "es.amazonaws.com"
                    },
                    "Action": [
                        "logs:CreateLogStream",
                        "logs:PutLogEvents"
                    ],
                    "Resource": resources_to_add
                }
                policy_document['Statement'].append(es_statement)

        else:
            print('No new resources to add.')
        update_params = {
            'policyName': policy_name,
            'policyDocument': json.dumps(policy_document),
        }

        update_response = cloudwatch_logs.put_resource_policy(**update_params)

        return {'status': 'SUCCESS'}

    except Exception as e:
        print('Error occurred while updating policy:', str(e))
        return {'status': 'FAILURE', 'error': str(e)}

Step 3: Create a Custom Resource

After creating my Lambda function, I needed to trigger it at the right time during stack deployment.

Step 4: Update OpenSearch Domain Configuration

Finally, I configured OpenSearch to use the log groups and disabled automatic resource policy creation:

logging: {
    appLogEnabled: true,
    appLogGroup: opensearchAppLogGroup,
    slowIndexLogEnabled: true,
    slowIndexLogGroup: opensearchSlowIndexLogGroup,
    slowSearchLogEnabled: true,
    slowSearchLogGroup: opensearchSlowSearchLogGroup,
},
suppressLogsResourcePolicy: true,

Gotchas and Lessons Learned

What Didn't Work

I tried using logs.fromLogGroupName() with its addToResourcePolicy method, but that gave me the same resource limit error. Apparently, you can't modify resources outside your stack this way (thanks, GitHub issue #6548!).

Mistakes along the way

Initially, I created both the log groups and the Lambda function within the same construct, while OpenSearch was placed in a different construct that received the log groups as props. This setup caused issues because the log groups were being referenced by the correct log group name in the same construct and a different one outside of the construct in the opensearch construct, which led to the Lambda failing to update the policy correctly. The solution came when I realized the importance of ensuring that the log groups were referenced by their concrete names. This insight came from reviewing the CDK implementation, which can be found in this file and the docs of it say:

"Returns an environment-sensitive token that should be used for the resource's 'name' attribute (e.g., bucket.bucketName). Normally, this token will resolve to nameAttr, but if the resource is referenced across environments, it will be resolved to this.physicalName, which will be a concrete name."

Final Thoughts

While this solution worked for me, I’m still relatively new to CDK, so there might be better approaches out there. I just wanted to document my findings in one place, hoping that it might help someone, even in the smallest way. The GitHub issues I referenced were incredibly helpful in providing context and guiding me toward a solution. I honestly wouldn’t have been able to find a resolution without those discussions. If you have a more elegant solution or if I’ve made any mistakes in my understanding, I’d truly appreciate hearing your thoughts!

References

https://github.com/aws/aws-cdk/pull/28707

https://github.com/aws/aws-cdk/issues/23637

https://github.com/aws/aws-cdk/issues/6548

https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_logs.LogGroup.html#static-fromwbrlogwbrgroupwbrarnscope-id-loggrouparn

https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-logs/lib/log-group.ts

https://github.com/aws/aws-cdk/issues/20567