DEV Community: Jared Lewis

How To Set Up React Context

Jared Lewis — Fri, 03 Jul 2026 18:01:36 +0000

Prop drilling is usually the reason we reach for React Context: state that started in one component ends up threaded through five layers of props, and every layer in between has to know about data it doesn't use. Context fixes that. But "use Context" isn't a setup — there are a dozen ways to structure the files, and most of them share a papercut that has annoyed me in every codebase I've worked in.

This article walks through the setup I've landed on. It's three files, it makes "Go to Definition" actually useful, and it uses a lint rule to make the one risky part of the pattern impossible to get wrong. The running example is a tic-tac-toe game — the full working project is at react-context-boilerplate-example.

The papercut

Here's the workflow friction. In a typical Context setup, components access state through a hook:

const { winner, resetGame } = useGame();

You're reading a component, you want to know how resetGame actually works, so you Command + Click on useGame. And you land... in a file that contains a useContext call and nothing else. The actual state management — the useState calls, the update logic — lives inside the provider component in a different file. So you go searching for it.

Every. Single. Time.

The setup below fixes that: Go to Definition on the consumer hook lands in the same file as all the state-management logic.

The structure

Three pieces, two files:

src/context/
├── GameContext.ts     ← the context, the public hook, AND the state logic
└── GameProvider.tsx   ← a thin shell

The trick is that the state management isn't written inside the provider component. It's written as a hook, in the same file as the consumer hook.

Step 1: The context file

GameContext.ts contains three things: the context object, the public hook that components use, and a private hook holding all the state logic.

import { createContext, useContext, useState } from 'react';
import type { GameContextI, Winner, BoardContent, Player } from '../types';
import {
  INITIAL_BOARD_CONTENT,
  INITIAL_CURR_PLAYER,
  INITIAL_WINNER,
} from '../constants/gameConstants';

export const GameContext = createContext<GameContextI | null>(null);

// PUBLIC: components call this to access the game state.
export function useGame() {
  const context = useContext(GameContext);
  if (!context) {
    throw new Error('useGame must be used within a GameProvider');
  }
  return context;
}

// PRIVATE: only GameProvider should ever call this.
export function useGameStateManagement() {
  const [currPlayer, setCurrPlayer] = useState<Player>(INITIAL_CURR_PLAYER);
  const [winner, setWinner] = useState<Winner>(INITIAL_WINNER);
  const [boardContent, setBoardContent] = useState<BoardContent>(
    INITIAL_BOARD_CONTENT,
  );

  const updateSquareContent = (
    rowIndex: number,
    colIndex: number,
    value: Player,
  ) => {
    // ...update the board, check for a winner, advance the turn...
  };

  const resetGame = () => {
    setCurrPlayer(INITIAL_CURR_PLAYER);
    setWinner(INITIAL_WINNER);
    setBoardContent(INITIAL_BOARD_CONTENT);
  };

  return {
    winner,
    currPlayer,
    setCurrPlayer,
    boardContent,
    setBoardContent,
    updateSquareContent,
    resetGame,
  };
}

A few things to notice:

The context is typed as GameContextI | null and the public hook throws if the context is missing. That null check happens once, here — components never have to handle a possibly-null context, and a component rendered outside the provider fails loudly with a message that says exactly what's wrong.
useGameStateManagement is a real hook, so it can use useState (or useReducer, or anything else) exactly as if the logic were written inline in the provider.
Both hooks are in one file. Go to Definition on useGame from any component takes you here — where the state logic lives. Papercut solved.

Step 2: The thin provider

Because the logic lives in the hook, the provider has almost nothing to do:

import React from 'react';
import { GameContext, useGameStateManagement } from './GameContext';

interface GameProviderProps {
  children?: React.ReactNode;
}

export default function GameProvider({ children }: GameProviderProps) {
  const contextValue = useGameStateManagement();
  return (
    <GameContext.Provider value={contextValue}>{children}</GameContext.Provider>
  );
}

Step 3: Wrap the tree and consume

Wrap the part of the tree that needs the state (here, the whole app):

createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <GameProvider>
      <App />
    </GameProvider>
  </StrictMode>,
);

And any component underneath just calls the public hook:

import { useGame } from './context/GameContext';

function App() {
  const { winner, resetGame } = useGame();
  // ...
}

No prop drilling, no null checks, and jumping to useGame's definition drops you next to the actual logic.

The catch

There's one problem with this pattern, and it's the price of the co-location: useGameStateManagement has to be exported so the provider can import it. Which means it looks importable to everyone.

If a teammate skims the file, sees an exported hook that returns the entire game state, and calls it from a component — the code will compile, render, and even sort of work. But that component gets its own, brand-new copy of the state, completely detached from the context value every other component shares. Clicking a square updates one board; the rest of the app is looking at a different one. It's the kind of bug that costs an afternoon.

A // do not call this outside GameProvider comment is a speed bump, not a wall. What I wanted was a lint error.

Enforcing it with a lint rule

I packaged this up as eslint-plugin-restrict-callers: an ESLint rule that restricts which named functions may call a given function.

npm install --save-dev eslint-plugin-restrict-callers

Then in eslint.config.js (flat config, ESLint 9+):

import restrictCallers from 'eslint-plugin-restrict-callers';

export default [
  {
    plugins: { 'restrict-callers': restrictCallers },
    rules: {
      'restrict-callers/restrict-callers': ['error', {
        restrictedFunctions: [
          {
            functionName: 'useGameStateManagement',
            allowedCallers: ['GameProvider'],
            alternative: 'useGame',
          },
        ],
      }],
    },
  },
];

Now calling the private hook anywhere other than GameProvider fails lint with a message that tells the reader what to do instead:

error  useGameStateManagement may only be called inside GameProvider. Use useGame instead

Each entry takes a functionName (the function to protect), allowedCallers (the functions permitted to call it), and optionally an alternative to suggest — or a fully custom message. It isn't hook-specific, either: you can use it any time a function has to be exported but is only meant for one caller. And because it's just config, every new context you add is one more entry in the array.

Recap

Put the context, the public consumer hook, and the private state-management hook in one file — Go to Definition on the consumer hook lands on the logic.
Keep the provider a thin shell that calls the private hook and passes the result to Context.Provider.
Throw from the public hook when the context is null, so misplaced components fail loudly.
Enforce the public/private boundary with eslint-plugin-restrict-callers instead of a comment.

The full working example — game and all — is at react-context-boilerplate-example, and the plugin lives at eslint-plugin-restrict-callers. If you've felt this papercut too, I'd love to hear how you've handled it.

One vector space for photos and words: Bedrock Titan multimodal on Aurora

Jared Lewis — Mon, 29 Jun 2026 04:33:39 +0000

In my last post I described OpinLog — a cross-user review graph where your "burger" and my "burger" resolve to the same canonical item via pgvector on Amazon Aurora PostgreSQL. This post is about the piece that makes the matching feel like magic: multimodal embeddings from Amazon Bedrock, feeding the matcher inside Aurora, all deployed on Vercel.

A photo of a burger should match the word "burger"

Users log items two ways: by typing a name, or by snapping a photo. If text and images lived in different vector spaces, I'd need two matchers and a fusion step. Instead I used Amazon Titan Multimodal Embeddings G1 (amazon.titan-embed-image-v1), which maps both text and images into the same 1024-dimensional space. One model, one index, one query.

The entire embedding contract is tiny:

export async function embed({ text, imageBase64 }: EmbedInput): Promise<number[]> {
  const body: Record<string, unknown> = {
    embeddingConfig: { outputEmbeddingLength: 1024 },
  }
  if (text) body.inputText = text.slice(0, 8000)
  if (imageBase64) body.inputImage = imageBase64

  const res = await getClient().send(new InvokeModelCommand({
    modelId: env.BEDROCK_EMBEDDING_MODEL_ID,
    contentType: "application/json",
    accept: "application/json",
    body: JSON.stringify(body),
  }))

  const parsed = JSON.parse(new TextDecoder().decode(res.body))
  return parsed.embedding
}

Pass text, imageBase64, or both. Because a photo of an In-N-Out burger lands near the text "In-N-Out Double-Double," a user who uploads a picture matches a user who typed the name — with zero special-casing. That single design choice is what makes the "add by photo → it already knows what this is" demo moment work.

A couple of production notes:

The Bedrock client uses the default AWS credential chain when explicit keys are absent, so the same code runs locally (SSO) and on Vercel (IAM user keys in env).
I store the returned array straight into a pgvector column via a literal helper — `[${vec.join(",")}]` — cast to ::vector inside a raw sql template.

From embedding to match

On every add, I embed the new item and run an HNSW cosine ANN search over the canonical catalog:

SELECT id, name, photo_url, rating_avg, rating_count,
       1 - (embedding <=> :q) AS similarity
FROM canonical_items
WHERE embedding IS NOT NULL
ORDER BY embedding <=> :q
LIMIT 10;

<=> is pgvector's cosine distance. A high-confidence hit auto-suggests as the default ("we think this is it"); otherwise the user sees the top candidates plus a "None of these — create new" escape hatch. The match is non-blocking: the item saves instantly with canonical_item_id = NULL, and the link is filled in after.

Tuning the floor: where "search" beats "vibes"

Raw vector search will happily return your entire catalog, ranked by ever-fainter similarity. I measured where Titan text embeddings actually sit:

~0.3 cosine for unrelated text
~0.5–0.6 for genuinely on-topic text

…and gated results at 1 - distance > 0.45. Below the floor, results are dropped. It's a single constant, but it's the line between "found what you meant" and "here's everything, sorted by a coin flip." For the matcher's auto-suggest threshold I set the bar much higher, so we only pre-select a match when we're confident, and otherwise let the human choose.

The catalog sharpens itself

Each canonical item's embedding is the running centroid of its linked members. When your burger log links to mine, the canonical vector becomes the average of both. The more people log the same thing, the more representative that vector gets — and the more reliably the next person's log (text or photo) snaps to it. The embedding model does the understanding; Aurora does the remembering and the averaging, in the same transaction that updates the denormalized rating aggregates.

Why this lives on Aurora

The qualifying AWS databases were DynamoDB, Aurora DSQL, and Aurora PostgreSQL. Only Aurora PostgreSQL ships pgvector, so the embedding produced by Bedrock can be indexed (HNSW) and queried (<=>) right next to the relational data — the ratings, the contributors, the lists. Embedding meaning (Bedrock) and storing/serving it transactionally (Aurora pgvector) is the whole engine of the app, and keeping them one JOIN apart made it a weekend project instead of a distributed-systems one.

Stack: Next.js 16 on Vercel → Amazon Aurora PostgreSQL Serverless v2 (pgvector) → Amazon Bedrock (Titan multimodal). Photos live in S3; the matcher is one line of SQL.

Built for the H0 Hackathon ("Hack the Zero Stack with Vercel and AWS Databases"). I created this content for the purposes of entering this hackathon. #H0Hackathon

Building a cross-user review graph with pgvector on Amazon Aurora

Jared Lewis — Mon, 29 Jun 2026 04:19:03 +0000

Every review app is a silo. Yelp reviews places, Amazon reviews its own catalog, Letterboxd reviews film. I wanted to build the opposite: one place where you can log and rate anything — a ball-point pen, a burger, a cruise — and have your review pool together with everyone else's.

The hard part isn't the form. It's this: when I log "In-N-Out Double-Double" and you log "in n out double double burger," those need to become the same thing so our ratings aggregate. No shared product ID, no barcode, no agreement on spelling. Just two humans describing the same item differently.

That's a similarity problem, and I solved it with pgvector running inside Amazon Aurora PostgreSQL (Serverless v2) — the whole app, deployed on Vercel at opinlog.com.

The data model is the product

Two tables carry the entire idea:

user_items — "I logged this, paid $X, rated it 4★." One row per logging event. Personal.
canonical_items — "the one shared thing everyone's rows point to." Deduplicated; aggregates everyone's ratings.

The matcher's only job is connecting a user_item to the right canonical_item. That edge is the product.

Every item carries a 1024-dim embedding. The canonical row's embedding is a vector(1024), indexed with HNSW for cosine ANN search:

// db/schema.ts (Drizzle)
embedding: vector("embedding", { dimensions: 1024 }).notNull(),
// ...
index("idx_canon_embedding").using("hnsw", t.embedding.op("vector_cosine_ops")),

I made the canonical embedding NOT NULL on purpose: a canonical entry must always be matchable, so every creation path supplies a vector and the recompute logic preserves it rather than ever averaging to NULL.

"Is this one of these?" — the matcher

On every add, I embed the new item and run an approximate-nearest-neighbour search over the canonical catalog. Drizzle doesn't model vector operators, so the query is a raw sql template:

SELECT id, name, photo_url, rating_avg, rating_count,
       1 - (embedding <=> :q) AS similarity
FROM canonical_items
WHERE embedding IS NOT NULL
ORDER BY embedding <=> :q
LIMIT 10;

<=> is pgvector's cosine distance; 1 - distance is similarity. A high-confidence hit auto-suggests as the default ("we think this is it"); otherwise the user sees the top candidates plus a "None of these — create new" escape hatch. Matching is optional and non-blocking: the user_item is saved instantly with canonical_item_id = NULL, and the match just fills it in — at upload time or from a queue later. The base loop (track my own stuff) never has friction.

The self-sharpening catalog

Here's the part I'm proud of. A canonical item's embedding is the running centroid of its linked members' embeddings. When you link your burger log to mine, the canonical vector moves to the average of both. The more people log the same thing, the sharper and more representative that vector becomes — the catalog improves itself with use.

And because "sort by rating" needs to stay fast at scale, the rating aggregates are denormalized onto the canonical row, with rating_avg as a stored generated column:

rating_avg real GENERATED ALWAYS AS
  (CASE WHEN rating_count > 0 THEN rating_sum::real / rating_count END) STORED

So the canonical page — the payoff screen — reads one row to show "4.6★ from 11 reviews across strangers," no aggregation query at render time.

Why Aurora PostgreSQL specifically

I evaluated the three qualifying AWS databases:

DynamoDB — great scale story, but no native vector search; I'd have to bolt on OpenSearch.
Aurora DSQL — distributed Postgres, but it lacks the pgvector and PostGIS extensions, so it can't do the core matching feature.
Aurora PostgreSQL — does vectors (pgvector), geo (PostGIS), and relations in one engine. One connection, one query planner, transactional joins between "the vector match" and "the rating rollup."

That last point is the whole reason this was buildable by one person on a deadline. The matcher result and the relational aggregation live in the same database, so linking an item and recomputing its canonical's centroid + ratings is a single transaction — not a dance between a vector store and an RDBMS.

The stack

Next.js 16 (App Router, Server Actions) on Vercel → Aurora PostgreSQL Serverless v2 via pg/Drizzle, with pgvector + PostGIS + pg_trgm. Embeddings come from Amazon Bedrock (more on that in the next post). Swapping local Docker Postgres for Aurora was a one-line DATABASE_URL change — same driver, same SQL.

The result is a universal, cross-user review graph for literally anything, and the magic is one line of SQL: ORDER BY embedding <=> :q.

Built for the H0 Hackathon ("Hack the Zero Stack with Vercel and AWS Databases"). I created this content for the purposes of entering this hackathon. #H0Hackathon