Forem: Anthony Humphreys

[Boost]

Anthony Humphreys — Sat, 03 Jan 2026 16:36:20 +0000

I Built an AI Tool to Practise GMing — Because “Prep” Isn’t the Same as “Practice”

Anthony Humphreys ・ Jan 3

I Built an AI Tool to Practise GMing — Because “Prep” Isn’t the Same as “Practice”

Anthony Humphreys — Sat, 03 Jan 2026 15:43:05 +0000

I love TTRPGs. The storytelling, the improvisation, the moment when a table really clicks. However, I've only recently started GMing, and I love it.

But I also noticed something odd:

GMing is a performance role, and we’re expected to perform… without ever really being able to rehearse.

Actors rehearse. Musicians rehearse. Developers practise in sandboxes.
Game Masters? We just… show up and hope for the best.

That gap is why I built GMprentice.

Prep ≠ Practice

There are plenty of tools for GMs:

Worldbuilders
Encounter generators
NPC name generators
AI tools that spit out lore or dialogue

They’re all about prep.

But prep doesn’t teach you how to:

Handle players going off-script
Make rulings under pressure
Manage spotlight and pacing
Recover when an encounter falls flat
Improvise when the party surprises you (which they always do)

Those are performance skills, And performance skills need practice.

The Real Problem: There’s No Safe Place to Fail

Most GMs I know don’t struggle with rules knowledge.

They struggle with confidence.

You can’t really practise:

Emotional scenes
Awkward rulings
High-stakes moments

…without real people at the table, and failing in front of friends can feel awful.

So most of us just learn by doing — publicly, imperfectly, sometimes painfully.

I wanted a private, judgement-free space where GMs could practise first.

Why AI (and not just “ChatGPT for D&D”)

GMprentice isn’t a single chatbot.

The core idea is:

Simulate a party, not an assistant.

That means:

Multiple AI “players”
Distinct personalities and playstyles
Disagreements, misunderstandings, bad ideas
The kind of chaos that makes GMing… GMing

The goal isn’t to generate content for you.

It’s to push back, derail plans, and force you to react.

In other words it is a sandbox for training, not shortcuts to running a campaign.

What GMprentice Is (and Isn’t)

It is:

A rehearsal space
A sandbox to test encounters, rulings, and roleplay
A way to build confidence before game night

It isn’t:

A replacement for real players
A replacement for the real creativity and art which is created in a real session
A rules engine
A content mill

If anything, it’s closer to a flight simulator than a writing tool.

Building It as an Indie Maker

From a technical perspective, the interesting challenge wasn’t “AI output quality”.

It was:

Maintaining consistent personalities across multiple agents
Balancing unpredictability without turning things into nonsense
Making failure feel useful, not frustrating
Keeping the GM firmly in control

I’ve been deliberate about avoiding the trap of “AI does everything”.

GMprentice works best when it resists you a little.

I built this app using Cursor, with extensive use of GPT 5.2 in 'Plan Mode' in Cursor, and Opus 4.5 for implementation and iteration of features.

I made extensive use of the Cursor Browser feature to work on finer details of styling and layout, with implementation assistance from Opus 4.5 working as a pair programmer.

This is the first time I've truly been shocked by coding LLMs. GPT 5.2 was planning for edge cases and scenarios that I had not initially considered and that would've only emerged in end-to-end testing. Opus 4.5 implemented features and styling changes almost flawlessly. The only major missteps were around Auth0 configuration and creating a middleware.ts instead of the newer proxy.ts expected in a NextJS 16 app.

This was a genuinely awe inspiring build, and I urge anyone cynical about AI coding agents, or who doesn't believe in their abilities to give them a try. You won't be disappointed.

I have also found the cognitive load of building an app like this is like nothing else I have experienced. I'm no longer laser focused on styling and feature execution, but I'm thinking about the core user experience more, I'm thinking about user journeys, conversion opportunities, and product vision more than nuanced detail which is really just noise. Using LLM coding agents this way frees you and empowers you to ship faster than ever, and deliver real production code that without LLM involvement - I probably wouldn't have had time to build something like this.

Why I Think This Matters

Tabletop RPGs are growing faster than ever.

More people want to GM — but GMing is still intimidating.

If we want more confident, inclusive, creative tables, we need better tools for learning the craft, not just preparing notes.

Practising privately shouldn’t be a luxury.

It should be normal.

What’s Next

GMprentice just launched, and it’s very much a work in progress.

I’m especially interested in:

Feedback from experienced GMs
How different playstyles feel in simulation
Where AI helps — and where it absolutely shouldn’t

If you’re curious, you can check it out here:

👉 https://gmprentice.app

And if you’re a GM:

What’s the one thing you wish you could practise before a session?

Advent of Code 2025: Human vs AI

Anthony Humphreys — Wed, 03 Dec 2025 08:51:37 +0000

❄️ What I’m Doing

Every day I’ll solve the Advent of Code puzzle in:

JavaScript
Rust
Python

Then I’ll ask a lineup of current AI coding models to produce their own solutions in the same three languages:

GPT-5.1 Codex
Gemini 3 Pro
Composer-1
Opus-4.5
Sonnet-4.5

So for each puzzle, there will be:

My human solutions (in three languages)
Five AI solutions (also in three languages each)

It’s essentially a coding “showdown,” but not a competition. The real aim is to explore how different kinds of reasoning appear in code, how approaches vary from model to model, and how my own thinking compares.

Methodology

Not a lab-grade study, just a consistent, lightweight workflow so the comparison stays fair.

For each challenge, after solving the problem manually, I will drop the challenge text into a txt file in the prompts folder, prepended with a brief prompt:

You are a developer taking on the Advent of Code Challenge 2025.
Create a solution for this problem.
This puzzle has two parts, solve both in the same solution. The program output should just be the two answers on separate lines.

I will aim to keep this prompt consistent across the days, only varying on the output format as needed. I then drop the input file into the inputs folder. In cursor, I select the model under test and then @ the file, the prompt, and the target directory, then hit run. No MCPs, no MAX mode, or anything else to avoid any confounding variables, and to minimise context bloat.

I then run the run_solutions.py python script to verify the output and review the "thinking" of the model. I'll improve this and the reporting as I progress - but this works as a starting point.

Once I've verified the output, I add the model directory to the .cursorignore

Note: The model solves for all three languages and is able to reference its own prior solutions, e.g. it can start in Python and then translate that to JS and Rust. I appreciate it would be interesting to see how it stacks up when the model can only work in one language at a time, and I may run that as a second iteration of this experiment. However - the prompt does not instruct the model to execute in a particular language first, and I too can reference my own solution in other languages - so I thought this would be interesting in itself.

🎁 Why This Experiment?

To understand how AI actually solves problems

Advent of Code puzzles are a perfect testbed: small enough to be self-contained (and not burn too many tokens/£!), but clever enough to require genuine reasoning and creativity. Watching how different models break them down is already proving fascinating, and analysing the end results may yield some interesting insights.

To improve my own fluency

Solving each puzzle three times in three different languages forces me to think more deeply about patterns, algorithms, and idioms. It’s a great way to keep my skills sharp, and explore some different languages to what I use day to day.

To observe differences in style and structure

Where a model chooses brute force, I choose planning and analysis.
Where I focus on solving the problem and don't worry about failure modes (as the code is only run with known inputs in a known environment, AI may be much more defensive and write more flexible code.
Where AI might use packages to solve a problem, I may avoid it and stick to language features and standard lib. These contrasts say a lot about how “AI thinking” manifests in code.

To build a dataset of human + AI approaches

By the end of AoC, even with only 12 challenges this year, that still gives me dozens of solutions across languages and models — plenty to analyse! I’ll have dozens of solutions that all answer the same questions from different angles. That’s an interesting resource in itself.

🤖 What I’ll Be Sharing

As the month goes on, I’ll post insights on things like:

patterns the AIs gravitate toward
performance of the output code (hey, perf stats can be fun)
common mistakes or blind spots
whether models one-shot solutions or needed some handholding
places where models outperform my first instincts or develop more novel solutions
language-specific quirks (Rust borrow checker vs AI… pray for it)
what it feels like to “pair” with multiple coding models
other random thoughts and musings on AI, Cursor and model nuances

The goal isn’t to crown a winner. It’s to understand the landscape of coding in 2025, where AIs shine, where they show their limitations, and how the two complement each other. Will the models one-shot all the solutions or will it pivot into re-prompting or "pair-programming"?

🌟 Follow Along

If you enjoy Advent of Code, programming language experiments, or the evolving relationship between developers and AI tooling, stick around. I’ll be posting reflections and curiosities throughout the month, followed by a round-up at the end of the challenges.

Here’s to a December full of puzzles, head-scratching, learning, and some very weird debugging moments.

Happy coding, and an even happier Advent. 🎅🔥

Introducing Edon

Anthony Humphreys — Sun, 17 May 2020 01:29:49 +0000

What is Edon?

Edon is the name I'm giving to a little corner of the internet, over on GitHub for the JavaScript community to engage in Deno development. I'll be keeping this repo up to date with the upstream repository, and will be regularly opening Pull Requests from this repo into Deno. Edon is founded on the idea that everyone should feel safe, supported and encouraged to contribute to open source. There is no space for any discrimination of any kind, or any behaviour which deters anyone from contributing. I believe in Learning in Public, mentoring and lifting others up, not bringing them down.

Why does this exist?

Mainting a separate repo and all that merging sounds like a nightmare, right? Well, I'll archive the repository once Deno has a solid Code of Conduct and the core contributors are seen to be taking their role in supporting a community more seriously.

The Deno team has, so far, seemed reluctant to take the issue of not having a Code of Conduct seriously.

Very early in the project someone opened an issue regarding the lack of a CoC
CLOSED

Soon after, [once again(https://github.com/denoland/deno/issues/670), someone suggested adding a CoC. This time it was dismissed, preferring to focus on functionality, and code style.
CLOSED

A little over a year later, an incident occurs in discussing an issue, and a CoC is once again suggested.
CLOSED

Next another user suggested a CoC, this was dismissed with a link to another issue, with a comment

I certainly agree that we should all be professional. But I don't like having all these non-necessary files in the root directory. If you want to add a section in the manual linking to a code of conduct that would be ok. Feel free to email me if there has been some problem (?) ry@tinyclouds.org Closing without merge.
This is a little bit of progress, recognising something is needed, but dismissing a CoC for cluttering the repo seems...misguided.
CLOSED

As 1.0 launch approached, someone proposed a CoC once again.
LOCKED OFF TOPIC

Yet another attempt was made to add a CoC
CLOSED

Finally a link is added to a CoC... but wait it isn't Deno's CoC, but Rust's! Close enough right? Not really. Took a further commit to add an email address for concerns. Although this is sufficient to express expectations, it still feels like the least amount of effort being put into this issue.

Unsurprisingly, issues, keep coming

Why does it matter?

I feel like I really shouldn't need to answer that question, but I expect I'll probably draw some flak for this post. This is an important issue, not only close to my heart, but a common issue in Open Source today.

Please see the Contributors' Covenant FAQs for more information.

Please also check out these studies looking at the efficacy of Codes of Conduct in OSS.

Code of Conduct in Open Source Projects

Why modern open source projects fail

Open Source Software Community Inclusion Initiatives to Support Women Participation

Diversity and decorum in open source communities

Patterns for regulating behavior in innovation communities

Emotional Labor of Software Engineers

Discovering community patterns in open-source: a systematic approach and its evaluation

Why Modern Open Source Projects Fail

Adopting a Code of Conduct is not a magic bullet solution and should not be seen as such. It is instead a social contract, signalling to a community that a certain set of standards are expected, and signalling to potential contributors that they are engaging in a safe and supportive community. Building a community takes hard work, commitment, and above all, empathy.

So what next?

Deno is a promising project. But it doesn't bode well if issues like this are flaring up and being dealt with in this manner at such an early stage.

Deploying a Gatsby site to Google Cloud Run

Anthony Humphreys — Fri, 15 May 2020 21:47:29 +0000

Building the Gatsby site

You don't need to do anything particularly special to build a Gatsby site for deployment to Cloud Run, but there are some steps between building the project and seeing it live.

For this tutorial (and for my blogs) I'll use gatsby-starter-hero-blog starter.

Getting up and running is simple (make sure you have the gatsby cli installed correctly first)

gatsby new anthonyhumphreysdev https://github.com/greglobinski/gatsby-starter-blog,

then you can run your site locally with

gatsby develop.

After customising the template to your liking (have a poke around, check out the gatsby & starter docs for more guidance!), setting up some content and an initial post, it's time to deploy a test build.

I decided to use GitHub Actions and Cloud Run to do this. GitHub actions is the new kid on the block for CI/CD, but it's such a nice experience, especially being so closely coupled to your actual source repo. I use Cloud Run for Lexio and love its ease of use and general developer experience.

You'll need to set up some environment variables for the gatsby starter and for the GitHub action workflow. These should be clear from the starter's docs, and from the source below. You can set secrets in the GitHub repo

You can checkout the full action YAML here:

I simply use the Node action to install dependencies and build the site.

- name: Setup NodeJS
  uses: actions/setup-node@v1
  with:
    node-version: "10.x"
- name: Install dependencies
  run: |-
    yarn global add gatsby-cli
    yarn
- name: Gatsby Build
  run: yarn build

That's all there really is to it as far as building the site goes - no different to building on your own machine...but we still need a few bits and pieces yet.

Cloud Run

Before continuing, you'll need to provision a new service in Cloud Run (assuming you have a Google Cloud account and Project set up!). Make a note of the Service Account Email Address, Project ID, Service Name, as you will need these later.

Building and Deploying the Docker Image

I had a few issues with the Gatsby Docker image so rolled my own...probably should've stuck with it and resolved my issues, but it worked so that's just a // TODO: Use gatsby image instead!

Dockerfile

FROM nginx:latest

COPY public /usr/share/nginx/html
COPY nginxconf/nginx.conf /etc/nginx/nginx.conf

EXPOSE 8080

If you're not familiar with Docker - all that's happening here is I use the latest version of the nginx image from dockerhub. I copy the files built in the previous step, which are in the public directory, to the /usr/share/nginx/html directory in the container, and then copy the nginx.conf file from the project to the container too. The last thing I do is EXPOSE 8080 which opens up port 8080 for the container.

Nginx Config

I won't go into Nginx as a reverse proxy, there are plenty of blog posts about that around already. You can however find the config I used below:

events {}
http {
    server {
        listen 8080;
        server_tokens off;
        location / {
            include /etc/nginx/mime.types;
            autoindex on;
            root   /usr/share/nginx/html;
            index  index.html index.htm;
            try_files $uri $uri/ /index.html;
        }
    }
}

Before I can push the image I need to setup GCloud in order to talk to Google's Cloud Registry:

- name: Setup GCloud
  uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
  with:
    version: "286.0.0"
    service_account_email: ${{ secrets.RUN_SA_EMAIL }}
    service_account_key: ${{ secrets.GCLOUD_AUTH }}
    project_id: ${{ secrets.RUN_PROJECT }}

Then I build the image

- name: Build Docker Image
  run: docker build . -t "eu.gcr.io/$PROJECT_ID/$SERVICE_NAME:$GITHUB_SHA"

Now, I authenticate and publish the image

- name: Authenticate for gcr
  run: gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin https://eu.gcr.io/$PROJECT_ID
- name: Push Docker Image to gcr
  run: docker push eu.gcr.io/$PROJECT_ID/$SERVICE_NAME:$GITHUB_SHA

The final step is to deploy a new revision of the service to Cloud Run

- name: Deploy
  run: |-
    gcloud run deploy $SERVICE_NAME \
      --quiet \
      --region $RUN_REGION \
      --image eu.gcr.io/$PROJECT_ID/$SERVICE_NAME:$GITHUB_SHA \
      --platform managed \
      --allow-unauthenticated

Adding a post

Simply add a new post under content/posts following the naming convention, commit your changes and push - when your changes hit the master branch, the Action will run and update your site. Magic, right?

Hopefully you can now browse to the url for the service and see your brand new site! If I have skimmed over any steps or if anything isn't clear, hit me up on Twitter and I'll clear things up!

useSyncedState

Anthony Humphreys — Fri, 15 May 2020 21:45:58 +0000

Synced State Experiment

After working on useLocalStorage, I wondered how hard it would be to sync state to persistent, distributed storage. For my 5th Day of 100 Days of code I decided to make a first attempt at this idea.

I followed the same pattern as for building the useLocalStorage hook, extending the useState API, and triggering a useEffect on the state update to handle the state synchronization...asynchronously8.

Without further ado, here's the code...I'll be working more on this. At the moment, this might be useful for a use case such as building a user profile. A common poor experience is filling out some information and boom you've hit refresh, or swiped back on the trackpad...this scenario is already resolved by the localStorage hook, but I thought it would be cool to explore binding state to an API. The current implementation is geared around a REST API, so next steps will be to look at passing a query/mutation to the hook.

I'm also thinking about how to hook this up to a useReducer, passing in the reducer function to determine how to manage state.

import { useState, useCallback, useReducer, useEffect } from "react";

type State = {
  success: boolean;
  loading: boolean;
  error: boolean;
};

type Action = {
  type: "loading" | "success" | "error";
  syncedState?: object;
};

const initialState: State = {
  success: false,
  loading: false,
  error: false,
};

const reducer = (state: State, action: Action): State => {
  switch (action.type) {
    case "success":
      return { success: true, loading: false, error: false };
    case "loading":
      return { success: false, loading: true, error: false };
    case "error":
      return { success: false, loading: false, error: true };
    default:
      return state;
  }
};

const SYNC_URL = "https://localhost:3000";

export const useSyncedState = (
  key: string,
  initialValue: string,
  delay: number = 1000,
  syncUrl: string
): [State, any, Function] => {
  const [state, dispatch] = useReducer(reducer, initialState);

  const syncToServer = useCallback(async (valueToStore: object) => {
    dispatch({ type: "loading" });
    const response = await fetch(SYNC_URL, {
      method: "POST",
      headers: new Headers({ "Content-Type": "application/json" }),
      body: JSON.stringify(valueToStore),
    });
    response.ok ? dispatch({ type: "success" }) : dispatch({ type: "error" });
  }, []);

  const syncToClient = useCallback(async () => {
    dispatch({ type: "loading" });
    const response = await fetch(SYNC_URL, {
      method: "GET",
      headers: new Headers({ "Content-Type": "application/json" }),
    });
    response.ok
      ? dispatch({ type: "success", syncedState: await response.json() })
      : dispatch({ type: "error" });
    return response.json();
  }, []);

  const [syncedValue, setSyncedValue] = useState<object>(async () => {
    try {
      const syncedState = await syncToClient();
      return syncedState ?? initialValue;
    } catch (error) {
      console.error(error);
      return initialValue;
    }
  });

  const setValue = (value: any) => {
    try {
      const valueToStore =
        value instanceof Function ? value(syncedValue) : value;
      setSyncedValue(valueToStore);
    } catch (error) {
      console.error(error);
    }
  };

  useEffect(() => {
    const timeout = setTimeout(() => {
      syncToServer(syncedValue);
    }, delay);
    return () => clearTimeout(timeout);
  }, [syncedValue, delay, syncToServer]);

  return [state, syncedValue, setValue];
};

Would be curious to hear anyone's thoughts on this, I can imagine lots of questions about the motivation and to be perfectly honest...it just seemed like a cool thing to put together 🤷‍♂️

useProgressiveLoading

Anthony Humphreys — Fri, 15 May 2020 21:45:09 +0000

If you've ever worked with a slow moving API that you just can't work around, you've probably written something along these lines already. I thought it would be handy to have this as a hook, to drop into loading components and not have to rewrite the same piece of logic umpteen times.

There are definitely better UX patterns than this, and I am in no way advocating this as a good practice for loading behaviour, but sometimes you can't avoid unsavoury bits of UI like this.

const text = useProgressiveLoading([3, 10, 15], ['Loading your profile is taking a litle longer than normal, please wait',
    'Still loading, please wait a while longer...',
    'Still loading your profile, thank you for your patience...']);

return (
  ...
  <LoadingText>{text}</LoadingText>
  ...
)

The hook takes two parameters, the first is an array of times in seconds, the second is an array of strings. The principle is really simple, the hook creates a timeout for each timing passed, and will update the text value each time the timeout fires. The two arrays must be 'balanced' in terms of length, or the hook will throw an error.

import { useEffect, useState } from 'react';

export const useProgressiveLoading: Function = (
  timings: number[] = [5, 15, 30],
  strings: string[] = [
    'Still loading, please wait...',
    'Still loading, please wait a while longer...',
    'Still loading, thank you for your patience...',
  ]
): string => {
  if (timings.length !== strings.length) {
    throw new Error(
      `You passed ${timings.length} times and ${strings.length} - there should be the same number of each.`
    );
  }
  const [text, setText] = useState<string>('');
  const [timers, setTimers] = useState<number[]>([]);

  useEffect(() => {
    timings.forEach((delay: number, index: number) => {
      const timer: number = window.setTimeout(
        () => setText(strings[index]),
        delay * 1000
      );
      setTimers(oldTimers => [...oldTimers, timer]);
    });
    return () => {
      timers.forEach(timer => window.clearTimeout(timer));
      setText('');
    };
  }, [timings, strings]);

  return text;
};

That's all there is to this one, its pretty simple!

You can install this from npm or check out the repo on GitHub

As always, suggestions, improvements etc all welcome!

This post was for day 4 of my #100DaysOfCode challenge. Follow me on Twitter for more.

useBrowserStorage

Anthony Humphreys — Fri, 15 May 2020 21:43:51 +0000

For day 3 of my #100DaysOfCode challenge I thought I would expand and polish a hook I previously wrote (adapted from several examples online such as this one) which wraps the useState hook and persists state in localStorage or sessionStorage depending on use case.

The hook conforms to a mix of the localStorage and useState API.

const [state, setState] = useBrowserStorage("key", "value", StorageType.LOCAL_STORAGE)

This is so simple to use, virtually a drop in replacement for useState and gives you state persistance and restoration. You can use state as an ordinary state variable, and call setState with either a string or a function, just like the setter for useState.

That's it! Full hook code below, and published over at npm with the code available on GitHub

import { useState } from 'react';

enum StorageType {
  LOCAL_STORAGE = 'LOCAL_STORAGE',
  SESSION_STORAGE = 'SESSION_STORAGE',
}

export const useBrowserStorage = (
  key: string,
  initialValue: string,
  type: StorageType
) => {
  const storageProvider =
    type === StorageType.LOCAL_STORAGE
      ? window.localStorage
      : window.sessionStorage;

  const [storedValue, setStoredValue] = useState<string>(() => {
    try {
      const storedItem = storageProvider.getItem(key);
      return storedItem ? JSON.parse(storedItem) : initialValue;
    } catch (error) {
      console.error(error);
      return initialValue;
    }
  });

  const setValue = (value: string | Function) => {
    try {
      const valueToStore =
        value instanceof Function ? value(storedValue) : value;
      setStoredValue(valueToStore);
      storageProvider.setItem(key, JSON.stringify(valueToStore));
    } catch (error) {
      console.error(error);
    }
  };

  return [storedValue, setValue];
};

UPDATE

This was originally published as 'useLocalStorage' - but then I realised using session storage in a hook called that wouldn't make much sense. Naming things is hard!

useFakeAsync

Anthony Humphreys — Fri, 15 May 2020 21:42:02 +0000

You can see the hook takes a few simple parameters, including the familiar pairing of a callback function and a delay in milliseconds. This follows the shape of JavaScript's setTimeout and setInterval methods.

import { useEffect, useState } from 'react';

enum FakeAsyncState {
  PENDING = 'PENDING',
  COMPLETE = 'COMPLETE',
  ERROR = 'ERROR',
}

export const useFakeAsync: Function = (
  callback: Function,
  delay: number = 3000,
  shouldError: boolean = false,
  chaos: boolean = false
) => {
  const [state, setState] = useState<FakeAsyncState>(FakeAsyncState.PENDING);

  useEffect(() => {
    let timer: NodeJS.Timeout;
    const fail = chaos ? Math.random() <= 0.5 : shouldError;
    if (fail) {
      timer = setTimeout(() => {
        setState(FakeAsyncState.COMPLETE);
        callback();
      }, delay);
    } else {
      setState(FakeAsyncState.ERROR);
    }
    return () => clearTimeout(timer);
  }, [delay, callback, chaos, shouldError]);

  return [state];
};

The hook also takes a 'shouldError' parameter so that an error condition can be forced.

The fourth parameter is a little more interesting, 'chaos'. I added this to randomise a success or error condition.

The state returned by the hook mimics a promise, it can either be pending, complete or in an error condition.

Hopefully this will help testing behaviour across components, and avoiding those inevitable bugs that creep in when integrating a UI with an API, like stutters between loading and success states, for example.

That's all! Go checkout the code on GitHub or install my handy hooks library from npm

This post was for day 1 of my #100DaysOfCode challenge. Follow me on Twitter for more.

useTSDX

Anthony Humphreys — Fri, 15 May 2020 21:41:13 +0000

Publishing hooks

One of the main outcomes I wanted from building this blog was to maintain a companion library of useful hooks. I'm writing most things in TypeScript these days (yeah I jumped on that hype train pretty hard, and haven't looked back...)

Publishing a custom hook is as easy as publishing a component for react. That being said, I'd never published a library built with TypeScript so wasn't entirely sure what was needed. That's when I remembered Jared Palmer's amazing TSDX CLI, I think I first heard about it on the SyntaxFM podcast.

I simply ran npx tsdx create hooks, dropped my code in the src directory, modified the github action included and hey presto, I've got a library live.

I'll certainly be making more use of this tool, for libraries and React Components.

useGeolocation

Anthony Humphreys — Fri, 15 May 2020 21:39:53 +0000

One of the first custom hooks I wrote was to grab the user's location using the Geolocation API. I wrote it for a project with two requirements - to get a user's location on a button press, and to 'watch' a user's location to keep a map preview up to date.

Let's cut straight to the code:

Usage (Single Location):

  const [position, error] = useGeolocation(GeolocationMode.SINGLE);

Usage (Watch Location):

  const [position, error, locationHistory] = useGeolocation(GeolocationMode.WATCH);

The hook is super simple to use. The first call returns a position object or an error, the second call will update 'position' every time the underlying hook receives an updated position from the Geolocation API, and will maintain an array of all positions observed in 'locationHistory'.

You can check out the code over at GitHub or install it from npm

The design of the underlying hook allows you to seamlessly switch between 'modes' too - so you could seamlessly transition between displaying a user's initial location and showing a user's journey as they follow directions, for example.

Its that simple. This is one of the most attractive value propositions offered by hooks - abstracting away logic in an easily reusable and easy to consume manner.

The full hook code

This is still a work in progress, types are incomplete etc.

  import { useCallback, useEffect, useState } from 'react';

  export enum GeolocationMode {
    SINGLE = 'single',
    WATCH = 'watch',
  }

  type GeolocationCoordinates = {
    accuracy: number | null;
    altitude: number | null;
    altitudeAccuracy: number | null;
    heading: number | null;
    latitude: number | null;
    longitude: number | null;
    speed: number | null;
  };

  type GeolocationResponse = {
    coords: GeolocationCoordinates;
    timestamp: number;
  };

  type GeolocationError = {};

  type GeolocationConfig = {};

  interface IPositionState {
    position: GeolocationResponse | null;
    positionError: GeolocationError | null;
    positionLoading: Boolean;
    previousPositions: Array<GeolocationResponse | null> | null;
  }

  const defaultGeolocationConfig: GeolocationConfig = {
    timeout: 12000,
    maximumAge: 60000,
    enableHighAccuracy: true,
  };

  export function useGeolocation(
    mode: GeolocationMode = GeolocationMode.SINGLE,
    stop: Boolean = false,
    config: GeolocationConfig = defaultGeolocationConfig
  ) {
    const [positionState, setPositionState] = useState<IPositionState>({
      position: null,
      positionError: null,
      positionLoading: true,
      previousPositions: [],
    });

    const onGeolocationSuccess = useCallback(
      position => {
        if (!stop) {
          setPositionState(oldState => ({
            ...oldState,
            position,
            previousPositions:
              mode === GeolocationMode.SINGLE
                ? [oldState.position]
                : [
                    ...(oldState.previousPositions
                      ? oldState.previousPositions
                      : []),
                    oldState.position,
                  ],
          }));
        }
      },
      [setPositionState]
    );

    const onGeolocationError = useCallback(
      error => setPositionState(oldState => ({ ...oldState, error })),
      [setPositionState]
    );

    useEffect(() => {
      if (mode === GeolocationMode.SINGLE) {
        navigator.geolocation.getCurrentPosition(
          onGeolocationSuccess,
          onGeolocationError,
          config
        );
      } else if (mode === GeolocationMode.WATCH) {
        navigator.geolocation.watchPosition(
          onGeolocationSuccess,
          onGeolocationError,
          config
        );
      }
    }, [mode, stop]);

    return positionState;
  }

useTheme

Anthony Humphreys — Fri, 15 May 2020 21:37:18 +0000

Recently I was working on a React Native project and I was asked to come up with an a dark theme for the app and make that the default, with an option for the user to switch to light theme at any time without having to restart the app (looking at you Microsoft Teams...). In order to do this, and to tidy up the styling of the app in general, I decided to create a theme context for the app. We are using vanilla React Native styling for this project, so I decided to roll my own theme context provider solution.

Context Provider

For my use case I came up with the following provider:

interface IThemeContext {
  theme: Theme;
  activeTheme: Mode;
  setTheme: Function;
}

export default createContext<IThemeContext>({
  theme: lightTheme,
  activeTheme: null,
  setTheme: (mode: Mode) => null
});

theme being the object representing the currently active theme.

activeTheme is an enum, Mode which is either DARK or LIGHT.

setTheme calls a setter for a useState hook which drives the value of theme based on the current Mode.

The code for the actual hook is actually quite simple, and arguably unnecessary, though it avoids me having to repeatedly import and use a context provider, and allows for some future functionality.

export default function useTheme() {
  const { theme } = useContext(themeContext);
  return theme;
}