DEV Community: Ibukun Demehin

The polish pass: smart add, pull-to-refresh, sticky headers, tighter archive

Ibukun Demehin — Wed, 22 Jul 2026 15:32:01 +0000

Nothing in this post is bigger than a few dozen lines. There's a 12-line parser, a 22-line hook, a one-prop fix, and a bug whose entire cure was deleting a component. None of them is a feature. Nobody will ever screenshot them for a launch tweet.

But the gap between "works in the demo" and "feels like an app" is made of exactly this — and I shipped it as one deliberate polish pass: three commits, ~850 lines, one afternoon that ran past midnight.

TL;DR — Batch your polish instead of fixing papercuts drive-by: you're already in the files, and small changes gain momentum together. Along the way: typed input gets a regex, not an LLM ("2 milk" → Milk ×2); re-adding an item merges instead of duplicating; "clear completed" is a bulk soft-delete; pull-to-refresh is a reusable React Query hook; stickySectionHeadersEnabled is quietly iOS-only by default; and a keyboard-dismiss wrapper was eating Android's first scroll touch.

(Part 12 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

Why a "pass" and not drive-by fixes

Every one of these annoyances had been on a list for days. I could have fixed each the moment I noticed it — mid-feature, context-switching every time. Instead they queued up until there was a batch worth doing, and then the batch went fast: the second fix in a file costs a fraction of the first, because you're already in there with the file's model in your head. Polish also compounds perceptually — one fixed papercut is invisible, six at once makes the app suddenly feel finished.

Here's the montage.

"2 milk" → Milk ×2 — a regex, not an LLM

The app's whole party trick is voice input parsed by Claude — rambling speech in, structured items out. So when I added quantity support to the typed capture bar, there was a lazy option sitting right there: send typed text through the same Lambda.

No. Typed input isn't rambling speech — it's a pattern you can write down. The entire parser:

const title = (s: string) => s.replace(/\b\w/g, (c) => c.toUpperCase());

/** "2 milk" → { name: "Milk", quantity: 2 }; anything else → quantity 1. Local, no Claude. */
export function parseManualItem(raw: string): { name: string; quantity: number } {
  const text = raw.trim().replace(/\s+/g, " ");
  const m = text.match(/^(\d{1,2})\s+(.+)$/);
  if (m) {
    const qty = Math.min(Math.max(parseInt(m[1], 10), 1), 99);
    return { name: title(m[2]), quantity: qty };
  }
  return { name: title(text), quantity: 1 };
}

Twelve lines, zero latency, zero cost, works offline. An LLM is for ambiguity; a regex is for a pattern. Reaching for the model here would have added a network round-trip to every keystroke-and-enter — to do a worse job than ^(\d{1,2})\s+(.+)$.

And the add itself got one more brain cell: if an unchecked item with the same name is already on the list, don't spawn a duplicate row — bump its quantity:

const existing = items.find(
  (i) => !i.checked && i.name.trim().toLowerCase() === parsed.name.toLowerCase(),
);
if (existing) {
  updateItem.mutate({
    id: existing.id,
    listId: activeList.id,
    quantity: (existing.quantity ?? 1) + parsed.quantity,
  });
} else {
  addItems.mutate({ listId: activeList.id, items: [parsed] });
}

Type "2 milk" when Milk ×1 is already there and you get Milk ×3, not two milk rows arguing with each other. Note the !i.checked — if you already bought milk this trip, a new "milk" is a new need, not an increment of the done one.

Clear completed — a bulk delete that isn't a delete

A finished shop leaves a graveyard of checked items. One "Clear completed" action now sweeps them — behind a destructive-confirm dialog, because it's a bulk operation on the user's data:

// Bulk "clear completed": soft-delete every checked item at once.
const clearChecked = useMutation({
  mutationFn: async ({ listId, ids }: { listId: string; ids: string[] }) => {
    const userId = await currentUserId();
    const now = new Date().toISOString();
    await Promise.all(
      ids.map((id) =>
        client.models.ShoppingItem.update({
          id, _deleted: true, _deletedAt: now, _deletedBy: userId,
        }),
      ),
    );
    return { listId };
  },
});

It's the house soft-delete convention — flip flags, never .delete() — doing quiet double duty: those "cleared" rows are precisely the purchase history that powers the frequently-bought chips from Part 10. Clearing your list feeds the feature that refills it.

Tap to edit, and an archive that behaves

Two structural touches, no code excerpts needed. Items became tappable: a row now opens an edit sheet with the full field set — name, quantity, unit, category, note — so a mis-parse or a changed mind doesn't mean delete-and-retype.

And archiving got tightened into an actual lifecycle: archived lists leave the switcher for a restorable Archived section (one tap to bring one back), and the active-list picker learned to never settle on an archived list — previously it could quietly select one after a sync, which is exactly the kind of state you only hit on a Tuesday in the store.

Pull-to-refresh, in brand colors

The app is offline-first with a persisted cache, so screens don't refetch on focus — which means users need a manual "give me the latest" gesture. Pull-to-refresh is the muscle-memory answer, and it's two tiny reusable pieces. A hook that refetches whichever React Query keys a screen cares about:

export function usePullRefresh(queryKeys: readonly (readonly unknown[])[]) {
  const qc = useQueryClient();
  const [refreshing, setRefreshing] = useState(false);
  const onRefresh = useCallback(async () => {
    setRefreshing(true);
    try {
      await Promise.all(
        queryKeys.map((key) => qc.refetchQueries({ queryKey: key as unknown[] })),
      );
    } finally {
      setRefreshing(false);
    }
  }, [qc, queryKeys]);
  return { refreshing, onRefresh };
}

…and a BrandRefreshControl that tints the spinner teal in light mode and the brighter dark-mode teal after sunset, so even the loading indicator is on the design system. Forty-five lines total, already used on two screens.

Two Android ghosts

Both of the actual bugs in this pass were Android-shaped.

Sticky section headers are an iOS-only default. My aisle headers ("🥦 PRODUCE") pinned while scrolling on iOS and just… scrolled away on Android. The reason is one of RN's quieter platform splits: SectionList sticks headers by default on iOS only. Opting in is one prop — but the moment a header actually pins, you discover the second half of the bug: a transparent header floats over the items scrolling behind it, text bleeding through text. The fix is giving the header an opaque page-colored band, and moving the section's top spacing from margin (outside the background) to padding (inside it):

 <SectionList
   sections={sections}
+  stickySectionHeadersEnabled
   ...
-  <Text className="mb-1 ml-1.5 mt-3 font-nunito-bold ...">
-    {section.emoji} {section.displayName}
-  </Text>
+  <View className="bg-page pb-1 pt-3 dark:bg-page-dark">
+    <Text className="ml-1.5 font-nunito-bold ...">
+      {section.emoji} {section.displayName}
+    </Text>
+  </View>

Seven lines added, and the list finally scrolls like the ones in apps you pay for:

The keyboard-dismiss wrapper was stealing first touches. When the capture bar first landed, the whole screen got wrapped in TouchableWithoutFeedback onPress={Keyboard.dismiss} — the standard trick, because React Native doesn't blur inputs when you tap outside them. On Android it had a side effect I'd been blaming on everything else: with the keyboard up, the first scroll gesture on the list did nothing — swallowed by the tap-catcher deciding whether that touch was a press. The fix was pure deletion: remove the wrapper, dismiss the keyboard at explicit moments (submitting, opening a sheet) instead of ambiently. The best kind of bug fix is negative lines. Every screen-wide convenience wrapper is a gesture-thief suspect until proven innocent.

What I took away

Batch polish into a pass. Papercuts queue cheaply and fix cheaply together; the second change in a file is nearly free, and six fixes at once move the "feels finished" needle in a way one never does.
Size the tool to the job. Voice gets Claude; "2 milk" gets a 12-line regex. If the input is a pattern, parse the pattern.
Merge beats duplicate — but only against unchecked items; done items are history, not state.
Never trust a cross-platform default until you've watched Android. Sticky headers, gesture handling, keyboard behavior — the splits are quiet and the docs whisper them.
Prefer fixes that delete code. The scroll bug's cure was removing a component, not adding a workaround.

The shopping tab is done — next arc: money

That closes the arc this series has been building since the voice pipeline in Part 5: capture (voice and typed), offline-first sync, aisle ordering, frequently-bought chips, templates, reordering that survived a library deletion, and now the polish. A shopping list I genuinely use in the shop every week.

The next arc is money: what things cost, per-list budgets, a spend breakdown — and pointing the phone's camera at a paper receipt and letting Claude read it. That's already under construction, and it comes with its own war stories.

What's in your polish backlog right now — and what's actually stopping you from burning it down in one pass? Tell me the papercut you've been ignoring longest.

A template is just a list with a flag: reusable shopping lists

Ibukun Demehin — Wed, 22 Jul 2026 12:04:50 +0000

Every week I build the same list. Milk, bread, eggs, the usual orbit of things a household actually runs on — retyped or re-dictated every single Sunday. The fix is obvious and every shopping app has it: "Weekly essentials," saved once, spun up fresh in one tap.

What's less obvious is what that feature costs. I went in braced for a Template model, template-item rows, copy logic, maybe a versioning question. The whole thing — save any list as a template, browse templates, instantiate one, delete one — shipped as one new schema field and zero new tables. The design work wasn't building a template system. It was realising there shouldn't be one.

TL;DR — A reusable template is the same ShoppingList model with isTemplate: a.boolean() on it. Kind is orthogonal to lifecycle, so it gets its own field instead of a new model or a new status value. One copy helper runs in both directions (list → template, template → list). The real engineering wasn't the flag — it was the three ripple effects: every piece of code that enumerates lists had to learn what the flag means, or quietly break.

(Part 11 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The fork: a new model, a new status, or a flag

The app already has a ShoppingList model with a lifecycle enum — ACTIVE, ARCHIVED, COMPLETED — and ShoppingItem rows hanging off it. Three ways to represent "template":

A Template model. A new table, new CRUD, new copy logic between two shapes that are 95% identical. Every future list feature (soft delete, per-user scoping, offline sync) gets implemented twice or templates fall behind. Rejected fast.

A "TEMPLATE" status. Tempting — the enum is right there. But status answers "where is this list in its life?", and template-ness answers "what kind of thing is this?" Jam them into one field and you get incoherent states by construction: a template can never be archived (the slot is occupied), and every status === "ACTIVE" check in the app silently needs a special case it doesn't know it needs.

A boolean. Kind is orthogonal to lifecycle, so it gets an orthogonal field:

ShoppingList: a.model({
  userId: a.string().required(),
  name: a.string().required(),
  status: a.enum(["ACTIVE", "ARCHIVED", "COMPLETED"]),
  isTemplate: a.boolean(), // true = reusable template, hidden from the switcher
  items: a.hasMany("ShoppingItem", "listId"),
  // … soft-delete trio
}),

That's the entire backend diff — one line. And because it's an additive field, DynamoDB just… accepts it. No table replacement, no migration. (This matters more than it sounds: in Part 4 I learned the hard way which schema changes CloudFormation treats as "replace the table." Additive columns are the safe kind. I check this before every schema change now.)

The commit for the whole feature: 8 files, +268/−28. One of those 268 lines is schema; the rest is client.

A template is storage, not machinery

Because a template is a ShoppingList, its items are ordinary ShoppingItem rows. Everything the app already does to lists happens to templates for free: per-user scoping, the soft-delete convention, the typed client queries. There is no "template subsystem" to maintain — there's one flag and a copy helper.

The copy helper is the only genuinely new logic, and it runs in both directions:

// Copy a list's live items into another list, reset to unchecked with fresh
// positions. Shared by save-as-template and instantiate-template.
async function copyItems(sourceListId: string, targetListId: string, userId: string) {
  const { data } = await client.models.ShoppingItem.list({
    filter: { and: [{ listId: { eq: sourceListId } }, NOT_DELETED_FILTER] },
  });
  const ordered = [...data].sort((a, b) => (a.position ?? 0) - (b.position ?? 0));
  for (let i = 0; i < ordered.length; i++) {
    const it = ordered[i];
    await client.models.ShoppingItem.create({
      listId: targetListId,
      userId,
      name: it.name,
      quantity: it.quantity ?? 1,
      unit: it.unit ?? undefined,
      category: it.category ?? undefined,
      note: it.note ?? undefined,
      checked: false,
      position: i,
      sourceText: it.sourceText ?? it.name,
    });
  }
}

Save-as-template snapshots the live list into a flagged list; "Use" copies a flagged list out into a fresh active one. Same loop, opposite directions (excerpt — error handling elided):

const saveAsTemplate = useMutation({
  mutationFn: async ({ sourceListId, name }) => {
    const { data: tpl } = await client.models.ShoppingList.create({
      userId, name, status: "ACTIVE", isTemplate: true,
    });
    await copyItems(sourceListId, tpl.id, userId);
    return tpl;
  },
});

const instantiateTemplate = useMutation({
  mutationFn: async ({ templateId, name }) => {
    const { data: list } = await client.models.ShoppingList.create({
      userId, name, status: "ACTIVE", isTemplate: false,
    });
    await copyItems(templateId, list.id, userId);
    return list;
  },
});

One honest divergence from my own plan: the plan said save-as-template should copy only the unchecked items ("what's still outstanding"). The shipped version copies everything, reset to unchecked — because halfway through building it I realised a template is a set, not a progress snapshot. If milk was already ticked off when you hit save, you still want milk in "Weekly essentials." The plan survives contact with the copy loop about as well as plans usually do.

One flag, three ripples

Here's the part that makes "just add a boolean" worth a blog post: every piece of code that enumerates lists now has an opinion about templates, whether it knows it or not. I found three.

1. The switcher must partition. Templates live in the same table as real lists, so the list-switcher sheet would happily show them. The split is client-side, exactly like the existing archived partition:

const { data: allLists, isLoading } = useShoppingLists();

// Templates live alongside real lists but never appear in the switcher.
const lists = useMemo(() => (allLists ?? []).filter((l) => !l.isTemplate), [allLists]);
const templates = useMemo(() => (allLists ?? []).filter((l) => !!l.isTemplate), [allLists]);

The sheet renders them as their own section — each with a Use button and a delete — below Archived:

2. The "first list" guard must mean real lists. On first run the app auto-creates a default list when the user has none. That guard used to ask "are there zero lists?" — which is now the wrong question. A user whose only surviving list is a template has rows in the table but has no list to shop with; the old check would skip auto-create and strand them staring at a template they can't open. The guard (and the loading state) now counts only non-template lists.

3. The frequency counter must exclude template items. Last post built "frequently bought" chips by counting the user's item history client-side. A template's items are a saved set, not a shopping occasion — and worse, instantiating a template copies its rows, so if template rows counted, every "Use" would double-count the entire weekly shop, forever, compounding weekly. The scan now drops any item whose list is flagged.

None of these three is hard. All three are the actual price of the feature — and exactly the kind of thing that doesn't appear in the "just add a boolean" estimate.

Names, dates, and deletes

Two small decisions I'd flagged as open questions in the plan, resolved by picking the lowest-friction option:

Instantiate naming is zero-prompt. Tapping Use doesn't ask you to name anything — it stamps the template name with today's date and switches you to the new list:

instantiateTemplate.mutate(
  { templateId: tpl.id, name: `${tpl.name} · ${shortDate()}` }, // "Weekly essentials · 22 Jul"
  { onSuccess: (list) => { if (list) onSelect(list.id); } },
);

A naming prompt is exactly the friction this feature exists to remove. You can rename later; you almost never will.

Template delete is a soft delete. Like every "delete" in this app, removing a template flips _deleted flags — never a real .delete(). Which, as the last post found out, occasionally pays unexpected dividends: history you didn't destroy is history you can mine later.

Honest limits, and the phase 2 I'm not building

copyItems is a sequential create loop, not a transaction. Kill the app mid-copy and you get a partial template (or a partial instantiation). At personal scale — a dozen items, sub-second copies, a foreground action you're watching — that's an acceptable MVP tradeoff. It's written down as one, next to the code, so future-me doesn't mistake it for a decision that was never made.

And the obvious next step is deliberately not built: scheduled recurrence. "Every Monday, create this week's list from the template and ping me" needs real machinery — a cadence field or a small Schedule model, an EventBridge-scheduled Lambda that instantiates due templates server-side, and a push notification when the list is ready. That's a separate project with a backend footprint, and it only makes sense once manual reuse proves people (well, I) actually reach for templates. Same discipline as last post's exit ramp: design it, write it down, don't build it yet.

What I took away

Model kind orthogonally to lifecycle. A boolean beside a status enum beats a new enum value that poisons every existing check — and beats a parallel model that duplicates your whole feature surface.
Additive schema fields are the cheap kind. Know which changes replace your DynamoDB table before you make them, not after.
A flag is never just a flag. Budget for every place that enumerates the model: the switcher, the bootstrap guard, the aggregation — each needed to learn what isTemplate means.
Ship manual before scheduled. Reuse-on-demand is one field and a copy loop; recurrence is a Lambda, a scheduler, and notifications. Prove the habit before you automate it.

Next up

This feature closes out the "big pieces" of the shopping tab — which means it's time for the polish montage: typing "2 milk" and getting Milk ×2, merge-instead-of-duplicate, clear-completed, brand pull-to-refresh, sticky section headers. A dozen small touches, none worth a post, all worth shipping. That's Part 12.

Where do you draw the line between "flag on an existing model" and "new model"? I keep choosing the flag and it keeps working — tell me about the time it didn't.

You can't GROUP BY in DynamoDB — so the client does the counting

Ibukun Demehin — Tue, 21 Jul 2026 22:38:09 +0000

The feature request was almost embarrassingly simple: groceries are mostly repeat purchases, so show one-tap chips of the user's usual items — "Add again: Milk · Bread · Eggs." In SQL, that's a beginner exercise:

SELECT name, COUNT(*) AS times
FROM shopping_items
WHERE user_id = :me
GROUP BY name
ORDER BY times DESC
LIMIT 8;

My database is DynamoDB, behind AppSync. There is no GROUP BY. No COUNT, no aggregates, no HAVING — the query model fetches items by key, full stop. So a one-line feature became an actual architecture decision, and the decision is more interesting than the feature.

TL;DR — NoSQL doesn't do read-time aggregation, so you either materialise at write-time (a counter table you upsert on every add) or aggregate at read-time on the client (fetch history, count in JS). For a personal-scale dataset, ship the client scan — but give it explicit budgets (page size, page cap, cache TTL), make the counts honest (soft-deleted rows in, template lists out), and write down the exit ramp to the materialised model before you need it.

(Part 10 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The fork: count on write, or count on read

Option B — the "proper" one: a materialised FrequentItem model. A row per (userId, normalised name) holding count and lastUsedAt, upserted on every add. Reading the top 8 is one cheap query. The costs: a new table (sandbox deploy), upsert discipline in every add path, and — to make the counts authoritative rather than best-effort — eventually a DynamoDB Streams Lambda doing the increments server-side. That's real machinery for what is, today, a strip of eight chips.

Option A — the honest MVP: derive it from history, client-side. Every item the user ever added is already sitting in the ShoppingItem table. Fetch the user's rows, count by name in JS, rank, done. Zero backend changes, ships the same afternoon. The cost is proportional to history: you re-read everything to re-rank, which is fine for hundreds of rows and indefensible for millions.

I have one user (me) and a few weeks of shopping history. A shipped. But "A, carelessly" and "A, with budgets" are different features — the rest of this post is the budgets.

The scan, with limits it can't blow through

The naive version of option A fetches unboundedly — history only grows. So the scan gets explicit caps: page size, a page ceiling, and a cache TTL so it doesn't run on every render:

const MIN_COUNT = 2;   // "frequent" = added on more than one occasion
const POOL = 40;       // ranked-pool cap; the screen slices to its display limit
const MAX_PAGES = 10;  // pagination guard (~2,000 rows at limit 200)

export function useFrequentItems() {
  return useQuery({
    queryKey: ["frequentItems"],
    staleTime: 5 * 60 * 1000, // re-rank at most every 5 minutes
    queryFn: async (): Promise<FrequentItem[]> => {
      const rows: Row[] = [];
      let nextToken: string | null | undefined;
      let pages = 0;
      do {
        const page = await client.models.ShoppingItem.list({
          filter: { userId: { eq: userId } },
          limit: 200,
          nextToken,
        });
        rows.push(...page.data);
        nextToken = page.nextToken;
      } while (nextToken && ++pages < MAX_PAGES);
      // … aggregate below
    },
  });
}

If history ever exceeds the ~2,000-row budget, the ranking quietly degrades to "your most frequent among recent history" instead of falling over — and that's also the tripwire that says it's time for option B.

The aggregation: a Map and two tie-breakers

Counting is a Map keyed on a normalised name — trimmed, lowercased, whitespace-collapsed — so "Oat milk" and "oat milk" are one item:

export function frequentKey(name: string): string {
  return name.trim().toLowerCase().replace(/\s+/g, " ");
}

Each occurrence bumps the count, and the freshest occurrence wins the display details — casing, unit, category, quantity — so a chip doesn't just add "Milk", it adds your usual milk:

cur.count += 1;
if (at >= cur.lastAt) {
  // Freshest occurrence wins the display casing + pre-fill defaults.
  cur.lastAt = at;
  cur.name = it.name.trim();
  cur.unit = it.unit;
  cur.category = it.category;
  cur.quantity = it.quantity;
}

Then rank by count with a recency tie-break, drop one-offs, and keep a pool the screen can slice:

return [...map.values()]
  .filter((a) => a.count >= MIN_COUNT)
  .sort((a, b) => b.count - a.count || b.lastAt - a.lastAt)
  .slice(0, POOL);

Making the counts honest

Two filtering decisions mattered more than the counting itself.

Soft-deleted and checked-off rows are included. This app never hard-deletes user data — a business "delete" flips _deleted flags (the convention every model in this backend carries). That rule was made for auditability, but here it pays a dividend nobody planned: a checked-off, cleared-away item is the strongest possible repeat-purchase signal. You bought it, it left the list — that's precisely the history worth mining. If deletes had been real deletes, this feature would have no data.

Template lists are excluded. The app also has reusable template lists ("Weekly essentials" — next post). A template's items are a saved set, not a shopping occasion; if they counted, instantiating a template would double-count everything in it forever:

// Template lists are saved sets, not shopping occasions — drop their items
// so they don't inflate the frequency counts.
const templateIds = new Set(userLists.filter((l) => l.isTemplate).map((l) => l.id));
for (const it of rows) {
  if (templateIds.has(it.listId)) continue;
  // … count it
}

Aggregation is easy; deciding what deserves to be aggregated is the actual design work.

The chips themselves

The screen subtracts anything already on the active list — a chip for something you've already added is noise — using the same normalised key:

const frequentChips = useMemo(() => {
  const onList = new Set(items.map((i) => frequentKey(i.name)));
  return frequentPool.filter((f) => !onList.has(f.key)).slice(0, MAX_CHIPS); // 8
}, [frequentPool, items]);

They render in two places: a horizontal strip riding just above the capture bar, and a wrapped cluster in the empty state — a brand-new list greeting you with your usual instead of a void. Tapping one goes through the same addItems mutation as everything else, which means chip-adds inherit the offline queue from Part 7 for free.

The exit ramp, written down in advance

Option A's failure mode is known and gradual: history outgrows the scan budget, or the re-ranking read cost stops being funny. The upgrade is already designed — the materialised model:

// NOT shipped — the documented option B
FrequentItem: a.model({
  userId: a.string().required(),
  nameKey: a.string().required(),  // frequentKey(name) — the dedup key
  name: a.string().required(),
  count: a.integer(),
  lastUsedAt: a.datetime(),
  unit: a.string(),
  category: a.string(),
}),

Upsert client-side in the add path first (a rare double-count race is harmless for chips), and when the counts need to be authoritative, move the increment into a DynamoDB Streams Lambda on ShoppingItem inserts. The important part isn't the design — it's that it's written down next to the shipped code, so future-me switches when the tripwire fires instead of re-deriving the whole debate.

What I took away

NoSQL moves aggregation to write-time or read-time — there is no free GROUP BY. Materialise when data is big or shared; scan client-side when it's personal-scale. Both are legitimate; drifting between them accidentally is not.
A client scan without budgets is a time bomb. Page caps, pool caps, and a cache TTL turn "unbounded read" into "bounded, degradable read."
Your soft-deletes are a dataset. Never hard-deleting user data was an auditability rule; it quietly made this feature possible.
Ship the MVP and the exit ramp. The cheap version is only cheap if the upgrade path is already designed.

Next up

That isTemplate flag doing quiet work in the exclusion filter is a whole feature: reusable template lists — "Weekly essentials," saved once, spun up fresh in one tap — built with zero new models. Why a template is just a list with a flag: Post 11.

Where do you do your aggregation on DynamoDB — Streams-materialised counters, client-side counting, or "we export to something with SQL and don't talk about it"? Genuinely curious where people draw the line.

Whose categories are these? Making an LLM's throwaway labels feel like real things

Ibukun Demehin — Tue, 21 Jul 2026 21:59:41 +0000

The request sounded trivial: let me reorder the aisles so the list matches how I walk my store — and let me rename "Produce" to "Fruit & Veg" while you're at it. Reorder and rename. Settings-screen stuff.

Small problem: the aisles don't exist. When Claude parses "milk and a dozen eggs" it stamps category: "Dairy" on an item and moves on. There's no Category table, no aisle entity, nothing to reorder — just strings, scattered across items, that happen to repeat. This post is about making things a user can own out of labels an LLM throws away.

TL;DR — Don't promote LLM-generated labels to a database model just to make them editable. Model each aisle client-side as { key, name, emoji }: the key is the immutable string that lives on items (Claude's vocabulary), while name and emoji are editable display. Store the user's ordered list in one a.json() field on their profile. Seed it with the standard aisles, and auto-add any category the LLM invents so nothing is ever un-orderable. Rename becomes a display edit — no item rewrites, no migration.

(Part 9 of Building CannyCart, a voice-first shopping app I'm building in public. Context from Part 5: Claude turns speech into structured items, each with a free-text category. Otherwise self-contained.)

The three options, honestly weighed

Option A — derive the aisles from the items. No storage at all: the aisle list is just the distinct categories currently on the list. It's zero-schema and always accurate, but it's unstable — check off your last Dairy item and the Dairy aisle vanishes, taking its position in your carefully arranged order with it. Add one tomorrow and it's back… at the bottom. You can't hang user preferences off something that flickers in and out of existence.

Option B — hard-code the fixed set. The parsing Lambda's prompt already names the standard grocery aisles (Produce, Bakery, Dairy, Meat, Frozen, Pantry, Drinks, Household), so just make that the editable list. Stable, simple — until Claude does what LLMs do. Say "a new laptop and some cat food" and your items land in Electronics and Pet — categories the fixed list has never heard of, now stuck unsortable at the bottom forever.

Option C — a first-class ShoppingCategory model. The "proper" answer: real rows, real ids, foreign keys from items. And for a per-user list of roughly twelve entries, it's a sandbox deploy, CRUD plumbing, joins on every list render, and a data migration for existing items — to store what is functionally a user preference.

What shipped: a seed, an auto-add, and one JSON field

The decision: B's stability plus A's openness, in a preference. Each aisle is:

export type Aisle = { key: string; name: string; emoji: string };

Three fields, one rule that makes everything downstream free:

key never changes. It's the category string exactly as it lives on items — Claude's canonical "Dairy". This is the aisle's identity.
name is the editable label. Rename edits this and only this.
emoji is the section glyph. Also editable, also display-only.

The user's ordered list lives in a single JSON column on their profile — the whole schema change is one line:

// UserProfile
aisleOrder: a.json(), // ordered [{key,name,emoji}] — per-user aisle display order

Seeded from the same vocabulary the Lambda's prompt uses, so Claude's output maps straight onto an aisle: 🥬 Produce · 🥖 Bakery · 🥛 Dairy · 🥩 Meat · 🧊 Frozen · 🥫 Pantry · 🥤 Drinks · 🧽 Household · 🛒 Other.

And here's why the key/name split earns its keep. When the user renames Produce to "Fruit & Veg", the items still say category: "Produce", Claude keeps emitting "Produce", and the section header renders the name. Nothing else moves — no item rewrite, no re-prompting the LLM, no migration. Identity and display were separated, so editing display costs nothing.

Why emoji, not icons

The glyph choice looks cosmetic but was forced by a build-time constraint. This app's icon library (react-native-iconify v1 — Part 3 explains the version pin) works via a Babel plugin that scans JSX for static literal icon names and inlines each SVG at build time. A per-aisle, user-chosen icon is by definition a variable — the one thing that pipeline can't resolve.

Emoji are just text. Fully dynamic, no registry, colourful by default, and they render identically in a section header and a settings row. An open-ended name→emoji lookup gives auto-added categories a sensible glyph, with a fallback:

const EMOJI_MAP: Record<string, string> = {
  produce: "🥬", bakery: "🥖", dairy: "🥛", meat: "🥩", frozen: "🧊",
  snacks: "🍿", coffee: "☕", pet: "🐾", electronics: "💻", // … ~40 entries
};

export function defaultEmojiFor(key: string): string {
  return EMOJI_MAP[key.trim().toLowerCase()] ?? "🛒";
}

Auto-add: nothing is ever un-orderable

The open-world half of the design. Whenever an item carries a category that isn't in the user's list yet, it gets appended — name defaulting to the key, emoji from the lookup:

export function withUnlistedAisles(saved: Aisle[], seenKeys: string[]): Aisle[] {
  const have = new Set(saved.map((a) => a.key.toLowerCase()));
  const extra = dedupe(seenKeys)
    .filter((k) => !have.has(k.toLowerCase()))
    .map((k) => ({ key: k, name: k, emoji: defaultEmojiFor(k) }));
  return extra.length ? [...saved, ...extra] : saved;
}

A small effect on the list screen watches for this and saves the merged list. One guard mattered in practice — a session-scoped ref of already-attempted keys, so a failed save doesn't re-trigger the effect in a loop:

// Auto-add any category Claude produced that isn't in the aisle list yet, so
// it becomes reorderable/renamable instead of stuck last. Converges (the saved
// list then includes it); a session ref stops a failed save from re-looping.
useEffect(() => {
  const fresh = seenCategories.filter(
    (k) => !known.has(k) && !attemptedAislesRef.current.has(k),
  );
  if (fresh.length) {
    fresh.forEach((k) => attemptedAislesRef.current.add(k));
    addUnlistedAisles(withUnlistedAisles(aisles, seenCategories));
  }
}, [items, aisles]);

So when Claude invents Electronics, it appears at the end of the aisle editor — 💻, reorderable, renamable — instead of being a second-class string forever.

How it's holding up

The editor reuses Part 8's tap-to-reorder menu — Move to top/up/down/bottom, no drag library. The boring pattern got reused within a week of shipping, which is the best endorsement a pattern gets.
Saves are optimistic (React Query onMutate/rollback), so reordering feels instant even though it round-trips a profile update.
AWSJSON strikes again: the stored JSON can come back single- or double-encoded depending on the layer, so the reader unwraps with the same while (typeof v === "string") v = JSON.parse(v) loop from Part 5 — plus a shape check per entry, because this field is user-adjacent data, not a trusted API response.

When you should promote to a real model

The JSON-preference approach assumes categories are per-user, small, and display-only. Promote to a first-class model when any of those breaks: categories shared across users or lists, per-category metadata that grows (budgets per aisle, store locations), or category-level soft-delete/audit needs. Those are entity problems and deserve entity treatment. A dozen display preferences aren't — and the single JSON field has the virtue that deleting the feature would be one column, not a migration.

Next up

Those categories are about to earn their keep: the next feature mines the user's shopping history for the items they buy most — which runs straight into DynamoDB's most famous missing feature. You can't GROUP BY. What you do instead is Post 10.

Where's your line for "this deserves a real table"? I keep finding that half my would-be models are actually preferences wearing a trench coat.

I deleted the drag-and-drop library and shipped four buttons instead

Ibukun Demehin — Tue, 21 Jul 2026 20:49:36 +0000

My shopping app shipped item reordering last week, and it contains zero drag gestures. You tap a ⇅ button on a row and pick from four menu options: Move to top · Move up · Move down · Move to bottom. That's it. This is the story of the much fancier version I built the same afternoon — and deleted before dinner.

The library never even made it into a commit. That's the tell.

TL;DR — Drag-to-reorder on a grouped SectionList (inside a gesture-handler root, with bottom sheets, pull-to-refresh, and swipe actions already competing for touches) triggered a cascade of Android issues: a crash, a frozen refresh, overlapping headers, janky scroll. Each fix surfaced the next — the signature of an integration fight, not a bug. The requirement said reorder, not drag — so I deleted the library and shipped a plain SectionList + a bottom-sheet menu that renumbers position optimistically. Boring won.

(Part 8 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The setup: a list that was already gesture-crowded

The Shopping tab is a grouped checklist — items under aisle headers (Produce, Dairy, …) in a React Native SectionList. By the time reordering came up, that screen was already juggling touch handlers from every direction:

the app-wide GestureHandlerRootView (load-bearing, outermost in the provider stack),
gorhom bottom sheets with pan-to-dismiss,
pull-to-refresh on the list,
checkbox taps, row taps (edit sheet), row swipe-to-delete.

"Users should reorder items" was on the list, and drag-and-drop is the obviously right interaction for that — every design instinct says so. So I reached for a drag library, react-native-reorderable-list, and wired it in place of the plain list.

The cascade

What followed, in order (from my build notes of that session — this all happened inside one afternoon):

A crash. The reorderable list didn't want to live inside the existing gesture/layout arrangement.
Restructure, retry — the crash cleared, and pull-to-refresh froze. The refresh spinner and the drag recognizer were now fighting over the same vertical pan.
Work around that — section headers started overlapping rows after a drag; the library's layout animation and the sticky-header math disagreed about where things were.
And underneath it all, scroll got janky — the one thing a list must never be.

Each fix surfaced the next problem, one layer down. That pattern is worth naming, because it's the diagnostic: when fixes reveal rather than resolve, you're not debugging a bug — you're fighting an integration. The library was fine. My screen was fine. They just couldn't share a gesture system on Android without me re-architecting one of them.

Every one of these, on its own, felt fixable. I know how these bugs go — another hour, another workaround. That's precisely the trap.

The decision point

Somewhere around the header overlap, I stopped and re-read the actual requirement. It wasn't "users can drag items." It was "users can reorder items."

Drag is one implementation of reorder — the prettiest one, and on this particular screen, the most expensive one. A menu is another implementation: tap ⇅ on the row, pick Move up / Move to top / etc. It has zero gesture surface — a tap can't fight a pan recognizer, can't freeze a refresh spinner, can't confuse a sticky header. And a menu is honestly more usable in context: a grocery list is operated one-handed, walking, pushing a trolley. Long-press-and-drag with your thumb while the phone wobbles is a worse interaction than two taps, and it's kinder to anyone without fine motor control.

So: npm uninstall. The library left no trace — not in a commit, not in the lockfile. The whole arc, from install to delete, fits inside one working session. The best review the drag version ever got is that it never survived to a commit.

What shipped: four buttons and some renumbering

The row's ⇅ button opens a bottom sheet. The options self-limit — an item at the top of its aisle doesn't offer "Move up":

// reorder-sheet.tsx (excerpt)
export type MoveAction = "top" | "up" | "down" | "bottom";

{canUp ? <MoveRow icon={…} label="Move to top" onPress={() => onMove("top")} /> : null}
{canUp ? <MoveRow icon={…} label="Move up" onPress={() => onMove("up")} /> : null}
{canDown ? <MoveRow icon={…} label="Move down" onPress={() => onMove("down")} /> : null}
{canDown ? <MoveRow icon={…} label="Move to bottom" onPress={() => onMove("bottom")} /> : null}

The move itself is array surgery plus a renumber. Items live under aisle sections but position is global across the list, so after moving within the category I re-derive positions for everything and only write the rows whose number actually changed:

// shopping/index.tsx (excerpt)
function applyReorder(catKey: string, from: number, to: number) {
  const catItems = [...section.data];
  const [moved] = catItems.splice(from, 1);
  catItems.splice(dest, 0, moved);

  // Rebuild the global order, then diff: only changed positions get written.
  const updates: { id: string; position: number }[] = [];
  ordered.forEach((it, i) => {
    if (it.position !== i) updates.push({ id: it.id, position: i });
  });

  // Optimistic: patch + resort the cache, then persist.
  qc.setQueryData(["shoppingItems", activeList.id], /* patch + sort by position */);
  reorderItems.mutate({ listId: activeList.id, updates });
}

The cache patch means the row hops instantly; the mutation persists in the background (and, since Part 7, even offline). Total surface area: one sheet component, one function, no new dependencies.

The villain found in the wreckage

The debugging detour did pay one real dividend. While untangling gesture handlers I found this, wrapped around the entire screen:

- <TouchableWithoutFeedback onPress={Keyboard.dismiss} accessible={false}>
    <View className="flex-1">
      {/* …the whole shopping screen… */}
    </View>
- </TouchableWithoutFeedback>

It was there for a reasonable purpose — tap anywhere to dismiss the keyboard. But on Android it was eating the first touch of every scroll: touch the list while the wrapper is watching, and your gesture goes to the touchable first, so the scroll doesn't start until the second attempt. That subtle "the list feels slightly dead" wrongness had been there the whole time — the drag investigation is what finally surfaced it. It's gone now (keyboard dismissal moved to the specific interactions that need it), and scroll response was noticeably better even before any reorder feature existed.

Wrong theories sometimes pay rent.

What I took away

Re-read the requirement before debugging the solution. "Reorder" ≠ "drag." I was an hour into fixing an implementation nobody had actually asked for.
When fixes reveal instead of resolve, stop. A bug yields to a fix. An integration fight yields a new bug per fix. Different problem, different move — change the approach, not the patch.
On Android, every gesture library negotiates with every other one. Root view, sheets, refresh, swipes, drag — each is reasonable alone; the combination is the risk. Budget for the interactions, not the features.
A deleted dependency is the cheapest dependency. Zero commits, zero lockfile entries, zero future upgrades that break. The boring version has needed no attention since.

Next up

The aisle headers those items sort under have their own story: the categories are free-text labels an LLM stamps on each item — so how do you let a user reorder, rename, and emoji things that aren't really entities? That's Post 9.

What's the library you deleted and immediately felt relief? I'm collecting evidence that "rip it out" is an underrated debugging technique.

Working offline in the cereal aisle: TanStack Query offline on Amplify

Ibukun Demehin — Tue, 21 Jul 2026 20:09:55 +0000

The one place a shopping app absolutely has to work is the one place phones give up: the middle of a supermarket, three aisles deep, no signal. So this had to be true — check off milk, add oat milk, fix a quantity, all offline, and have every change land silently once you're back on WiFi at the checkout. No spinner of death, no lost taps.

The surprise: I didn't need a sync engine to do it. React Query already pauses, persists, and replays mutations. Two small tricks make it survive a real trip to the store.

TL;DR — For offline-first on Amplify, don't reach for DataStore — stay in TanStack Query. Persist the query cache to AsyncStorage; wire onlineManager to NetInfo so React Query pauses mutations offline; make those mutations optimistic and register them as keyed mutation defaults so a paused mutation can replay via resumePausedMutations even after the app is killed; and give every create a client-generated UUID so an offline row keeps its identity on sync. No schema change.

(Part 7 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained — no earlier context needed.)

The fork: DataStore, or stay in React Query

Amplify ships DataStore — a genuine offline sync engine with a local store and conflict resolution. It's the "official" answer, and for a collaborative, multi-user, heavily-relational app it's the right one.

But adopting it here meant ripping out the data layer the whole app already stands on: the typed Amplify client, observeQuery, and TanStack Query for server state. That's a big architectural U-turn to serve one feature — and it trades a stack I understand for a sync engine I'd have to learn the failure modes of.

The other option: TanStack Query already has first-class offline support. The app is single-user (your own grocery list), so last-write-wins is a perfectly fine conflict policy, and I get to keep everything I've already built. I stayed. The rest of this post is what "staying" actually takes.

The shape

persist the cache   → AsyncStorage, so last-known lists/items read with no network
onlineManager ← NetInfo → React Query knows it's offline, pauses mutations
optimistic mutations as defaults → UI reacts instantly; paused ones replay after an app kill
client-generated IDs → an offline create keeps its id once it syncs
sync banner → the one visible bit: "offline" / "syncing N changes"

No schema change. The models already have createdAt/updatedAt; conflict policy is last-write-wins.

Piece 1 — persist the cache

Offline reads come from the query cache, so the cache has to outlive the process. PersistQueryClientProvider + an AsyncStorage persister does that:

// lib/query-persist.ts
const BUSTER = "cannycart-1"; // bump to discard old cache when the shape changes

const asyncPersister = createAsyncStoragePersister({
  storage: AsyncStorage,
  key: "cannycart:rq-cache",
  throttleTime: 1000,
});

export const persistOptions = {
  persister: asyncPersister,
  buster: BUSTER,
  maxAge: 1000 * 60 * 60 * 24 * 7, // 7 days
  dehydrateOptions: {
    // Only persist paused offline mutations we can actually resume — the ones
    // we registered defaults for (mutationKey ["shopping", …]). Anything else
    // paused offline is dropped rather than restored un-resumable.
    shouldDehydrateMutation: (m) =>
      m.state.isPaused &&
      Array.isArray(m.options.mutationKey) &&
      m.options.mutationKey[0] === "shopping",
  },
};

That shouldDehydrateMutation filter matters more than it looks — persisting a paused mutation you can't rebuild on the next launch is worse than dropping it, because it resurrects as a zombie with no function to run. Only persist what you can resume. (Which is Piece 3.)

Piece 2 — know when you're offline

React Query doesn't detect connectivity itself — you tell it, by pointing onlineManager at NetInfo. One side-effect module:

// lib/react-query-native.ts — wires onlineManager to NetInfo
import NetInfo from "@react-native-community/netinfo";
import { onlineManager } from "@tanstack/react-query";

onlineManager.setEventListener((setOnline) =>
  NetInfo.addEventListener((state) => setOnline(!!state.isConnected)),
);

Now, when a mutation fires offline, React Query pauses it instead of failing it — and that pause is the hook everything else hangs off.

Piece 3 — the trick that survives an app kill

Here's the part that took the most thought. A paused mutation is easy to resume within a session. But a shopper puts the phone in their pocket; iOS kills the app; they reopen it in the car. The paused mutation was persisted to disk — but a function can't be serialized. So on relaunch, how does React Query know what to run?

The answer is mutation defaults keyed by mutationKey. You register each mutation's function at module load, under a stable key. On relaunch, React Query rehydrates the paused mutation, looks up the default by its key, and rebuilds the function to replay:

// lib/shopping-mutations.ts
export const MK = {
  addItems: ["shopping", "addItems"] as const,
  toggleItem: ["shopping", "toggleItem"] as const,
  // …updateItem, softDeleteItem, clearChecked
};

queryClient.setMutationDefaults(MK.toggleItem, {
  mutationFn: async ({ id, checked }: ToggleItemVars) => {
    const { data } = await client.models.ShoppingItem.update({ id, checked });
    return data;
  },
  onMutate: ({ id, listId, checked }: ToggleItemVars) =>
    optimistic(listId, (rows) => rows.map((r) => (r.id === id ? { ...r, checked } : r))),
  onError: (_e, _v, ctx) => rollback(ctx as Ctx),
  onSettled: (_d, _e, vars: ToggleItemVars) => reconcile(vars.listId),
});

The onMutate/onError/onSettled trio is the optimistic loop: snapshot the cache and apply the change immediately, roll back if it errors, and reconcile with the server once it settles. The snapshot helper is small:

async function optimistic(listId, apply) {
  await queryClient.cancelQueries({ queryKey: itemsKey(listId) });
  const prev = queryClient.getQueryData(itemsKey(listId));
  queryClient.setQueryData(itemsKey(listId), (old) =>
    Array.isArray(old) ? apply([...old]) : old);
  return { prev, listId }; // for rollback
}

Because the function lives in a keyed default (not inline at the call site), it exists again the instant the module loads on the next launch — ready for the persisted mutation to find.

Piece 4 — client-generated IDs

Optimistic-add has a classic bug: you show a row offline with some temporary id, the server later assigns the real id, and now your offline edits/toggles point at a ghost. Amplify lets you supply the id on create, so I stamp a UUID in onMutate — into the variables themselves, so the same id flows through the optimistic row, the eventual server row, and the persisted paused mutation:

onMutate: async (vars: AddItemsVars) => {
  vars.items.forEach((it) => { if (!it.id) it.id = uuidv4(); }); // stamp stable ids
  // …build optimistic rows using it.id…
},
mutationFn: async ({ listId, items }: AddItemsVars) => {
  for (const it of items) {
    await client.models.ShoppingItem.create({ id: it.id, listId, /* … */ });
  }
},

One identity from creation to sync. An item added in aisle 5 and checked off in aisle 7 is the same row when it all lands — no duplicate, no orphaned edit.

Piece 5 — a calm sync banner

The only visible surface is a thin status bar, and it's deliberately teal, not red — being offline isn't an error, it's a normal state of a grocery trip. It reads connectivity and how many ["shopping"] mutations are still in flight:

export function useSyncStatus() {
  const [online, setOnline] = useState(() => onlineManager.isOnline());
  useEffect(() => onlineManager.subscribe(() => setOnline(onlineManager.isOnline())), []);
  const pending = useIsMutating({ mutationKey: ["shopping"] });
  return { online, pending };
}

Offline → "changes save here and sync when you're back." Online with a queue → "Syncing N changes…". Online and empty → the banner returns null and vanishes.

The wiring order that bites

There's one ordering trap. resumePausedMutations can only rebuild a persisted mutation if its default is already registered. So the module that registers the defaults must be imported before the provider tries to resume:

// app/_layout.tsx
import "@/lib/shopping-mutations"; // ← registers defaults FIRST (side-effect import)

<PersistQueryClientProvider
  client={queryClient}
  persistOptions={persistOptions}
  onSuccess={() => {
    // Cache restored — now replay anything queued while offline.
    queryClient.resumePausedMutations();
  }}
>

Resume before the defaults exist and the paused mutations rehydrate with no function to run — they just sit there. The fix is literally import order.

How it's holding up (and the caveats)

Last-write-wins. Fine for a single-user list. The day list sharing lands, that's a different post — two people editing one list needs real conflict resolution, and that's the case where DataStore earns its weight.
Voice stays online-only. parseShoppingList needs the network and Claude, so the mic politely no-ops offline. Offline covers manual add / check / edit / delete — which is the whole in-store loop.
Replay ordering. A create has to land before the edits made against it. Client-generated ids plus in-order queueing handle this: the same id is valid the moment the row is optimistically created, so a follow-up toggle is never "ahead" of its target.

When you should choose DataStore instead

Stay in React Query when you're single-user, last-write-wins is acceptable, and you already own your data layer. Reach for DataStore (or a purpose-built sync engine) when you have multi-user shared documents, need real conflict resolution, or have deeply relational data that has to stay consistent offline. Offline-first is a spectrum; this is the light, boring end of it — which is exactly what a personal shopping list wants.

What's the offline story in your app — full sync engine, or the React-Query-pause-and-replay approach? And if you've shipped shared/collaborative offline, I'd love to read how you handled the conflicts I get to ignore.

Light, dark, and system themes in Expo + NativeWind — the whole app, from one setting

Ibukun Demehin — Mon, 20 Jul 2026 17:50:53 +0000

Most "dark mode in React Native" tutorials stop at dark: classes and call it done. But a real setting needs three states — Light, Dark, and System — it has to survive an app restart, and the native chrome (tab bar, navigation header) has to follow along, not just your own views. Here's the full thing, and the nice surprise is how little wiring the last part takes.

TL;DR — Define your colors once as a palette with light + dark stops in tailwind.config, so every class is a pair (bg-page dark:bg-page-dark). Then a single call — NativeWind's colorScheme.set(pref) — applies the user's choice. It drives both the dark: variants and React Native's Appearance, so expo-router's theme and the native tab bar switch for free. Hold the choice in Redux, persist it to AsyncStorage, and restore it on launch.

(Part 6 of Building CannyCart, a voice-first shopping app I'm building in public. This one's a self-contained Expo how-to — no earlier context needed.)

Who this is for

You're on Expo + NativeWind and you already sprinkle dark: classes around. You want to turn that into an actual Appearance setting a user can pick — including a "System" option that follows the phone — and you want it to be remembered and to theme the whole app, tab bar included.

Prerequisites

Expo SDK 57, expo-router
NativeWind v3 (Tailwind v3 under the hood)
Redux Toolkit for the in-app choice
@react-native-async-storage/async-storage for persistence

The shape, before any steps

palette (one object)  → tailwind.config dark stops → bg-page dark:bg-page-dark
user picks a mode     → Redux prefsSlice.theme      (in-app source of truth)
                      → colorScheme.set(pref)        (drives NativeWind + RN Appearance)
                      → AsyncStorage                 (persist across launches)
on launch             → load pref → dispatch + apply (restore, no flash)

Five moving parts, and exactly one of them (colorScheme.set) is doing the heavy lifting.

Step 1 — one palette, dark stops in Tailwind

Define colors once and give each a dark counterpart in tailwind.config, so a token becomes a pair. This keeps "what colour is a card" in a single place instead of scattered across components.

// tailwind.config.ts
import { palette } from "./src/constants/design-tokens";

export default {
  content: ["./src/**/*.{js,jsx,ts,tsx}"],
  presets: [require("nativewind/preset")],
  theme: {
    extend: {
      colors: {
        page:    { DEFAULT: palette.neutral.background, dark: palette.dark.background },
        surface: { DEFAULT: palette.neutral.surface,    dark: palette.dark.surface },
        ink:     { DEFAULT: palette.neutral.textPrimary, inverse: palette.dark.textPrimary },
        brand:   { DEFAULT: palette.brand.primary, bright: palette.dark.primary /* teal on dark */ },
        // …line, coral, semantic trio, each with its dark stop
      },
    },
  },
} satisfies Config;

Now every surface is a class pair. You write the light token and its dark stop together, and the dark: variant does the switch:

<View className="flex-1 bg-page p-5 dark:bg-page-dark">
  <Text className="text-ink dark:text-ink-inverse">Weekly shop</Text>
</View>

One RN gotcha worth stealing: React Native can't synthesize font weights, so each weight is a separate loaded font file and its own family (font-nunito, font-nunito-bold, …) — not font-bold. Unrelated to theming, but it lives in the same config and bites everyone once.

Step 2 — the one call that themes everything

Here's the whole engine. NativeWind exposes an imperative colorScheme handle; setting it to "light", "dark", or "system" is the entire apply step:

// lib/theme-mode.ts
import { colorScheme } from "nativewind";

export function applyThemePref(pref: ThemePref): void {
  colorScheme.set(pref); // "light" | "dark" | "system"
}

The reason this is the whole engine — and not just half of it — is what colorScheme.set touches. It drives NativeWind's dark: variants and React Native's Appearance API. So anything reading useColorScheme() updates too: expo-router's ThemeProvider, and with it your navigation header and the native tab bar. You theme your own views with dark: classes; the framework chrome comes along for free because it's reading the same signal.

// app/_layout.tsx — nav + tab bar follow useColorScheme(), which colorScheme.set() feeds
const colorScheme = useColorScheme();
// …
<ThemeProvider value={colorScheme === "dark" ? DarkTheme : DefaultTheme}>
  <AuthGate><AppTabs /></AuthGate>
</ThemeProvider>

That's the payoff of the whole post: you don't theme each surface separately. One call, and the utility classes, the nav theme, and the tab bar all move together. Here's a second, entirely different screen — the More tab — proving it: same setting, and the list rows, header, and tab bar all follow.

Step 3 — a source of truth in Redux

colorScheme.set() applies a mode, but your UI still needs to know the current choice — to check the selected row in the picker, for instance. That's client state, so it goes in Redux (server data belongs to React Query — never mix the two):

// store/slices/prefsSlice.ts
export type ThemePref = "system" | "light" | "dark";

const initialState = { theme: "system" as ThemePref };

export const prefsSlice = createSlice({
  name: "prefs",
  initialState,
  reducers: {
    setThemePref: (state, action: PayloadAction<ThemePref>) => {
      state.theme = action.payload;
    },
  },
});

Step 4 — persist it to AsyncStorage

A setting that forgets itself on relaunch isn't a setting. Load and save the pref under one key, and keep both operations non-fatal — a storage hiccup should never crash the app or block the theme from applying for the current session:

// lib/theme-mode.ts
const THEME_KEY = "cannycart:themePref";

export async function loadThemePref(): Promise<ThemePref> {
  try {
    const stored = await AsyncStorage.getItem(THEME_KEY);
    if (stored === "light" || stored === "dark" || stored === "system") return stored;
  } catch {
    // fall through to default
  }
  return "system"; // sensible default: follow the phone
}

export async function saveThemePref(pref: ThemePref): Promise<void> {
  try {
    await AsyncStorage.setItem(THEME_KEY, pref);
  } catch {
    // non-fatal: the pref still applies for this session
  }
}

Step 5 — the Appearance picker

Now the UI. Three rows; selecting one does three things in order — record it in Redux, apply it, and persist it (fire-and-forget, because the apply shouldn't wait on disk):

// app/more/appearance.tsx
function select(pref: ThemePref) {
  dispatch(setThemePref(pref)); // 1. source of truth
  applyThemePref(pref);         // 2. colorScheme.set — themes the whole app
  saveThemePref(pref);          // 3. persist, fire-and-forget
}

The rows themselves are just class pairs, with the selected one tinted and checked:

<Pressable
  onPress={() => select(option.value)}
  className={`flex-row items-center gap-3 px-4 py-4
    ${selected ? "bg-brand-mint dark:bg-brand-mint-dark" : ""}`}
>
  <Text className="text-ink dark:text-ink-inverse">{option.label}</Text>
  {selected ? <Iconify icon="mdi:check-circle" size={22} color={brand} /> : null}
</Pressable>

Step 6 — restore on launch, without a flash

Persistence is only half of "remembered." On the next launch you have to read the pref back and apply it before the app paints, or the user sees a flash of the wrong theme. A tiny component does it — it renders nothing, sits inside the Redux provider, and applies the stored pref on mount:

// app/_layout.tsx
function ThemeModeInit() {
  const dispatch = useAppDispatch();
  useEffect(() => {
    loadThemePref().then((pref) => {
      dispatch(setThemePref(pref)); // sync Redux
      applyThemePref(pref);         // and the actual theme
    });
  }, [dispatch]);
  return null;
}

// …mounted first thing inside <ReduxProvider>, above the rest of the tree:
<ReduxProvider store={store}>
  <ThemeModeInit />
  {/* QueryClient → SafeArea → ThemeProvider → tabs … */}
</ReduxProvider>

The native splash is already held while fonts load (SplashScreen.preventAutoHideAsync()), which gives the async read a beat to resolve before the first real frame — so System-in-dark comes up dark, not a white flash then dark.

Verify it works

Four checks, in order:

System follows the phone. Pick System, then flip your device to Dark in Control Center / Quick Settings — the app should switch live.
Light/Dark override. Pick Dark on a light phone (and vice versa) — it should hold regardless of the device.
It persists. Fully kill and relaunch — your last choice should come back with no flash.
The chrome follows. In dark mode, confirm the tab bar and the navigation header are dark too — that's the colorScheme.set → Appearance link doing its job. If your own views go dark but the tab bar stays light, you themed with dark: but never called colorScheme.set.

Where to go next

Two threads from here. First, per-user hygiene: this key is global, so on a shared device one account's theme would greet the next. Clearing user-specific AsyncStorage keys on sign-in/out (the user-prefs-cache-setup pattern) closes that. Second, the web app is still on light-only — the same palette already feeds its Tailwind config, so the port is mostly mode plumbing, not redesign.

Which surface in your app was the last to get the theming memo? For me it's always a hard-coded #fff on a shadow or a border, smug and glowing in dark mode. Tell me yours.

"Milk, and a dozen eggs": a voice-to-Claude shopping list that never trusts the AI

Ibukun Demehin — Mon, 20 Jul 2026 16:39:13 +0000

I hold the mic and say: "milk, a couple of bananas, a dozen eggs, and some ripe avocados." Two seconds later a tidy list appears — Milk ×1, Banana ×2, Egg ×12, Avocado (ripe) — each already filed under Dairy or Produce. But it doesn't save. It waits for me to say yes.

The interesting part of this feature isn't the AI. It's the deliberate gap I put between the AI and my database.

TL;DR — On-device speech-to-text turns speech into a transcript; a Claude Haiku Lambda turns the transcript into structured JSON items; and — the key decision — that mutation returns the items without saving them. The client shows a review sheet, and rows are only written when the user taps Add. An LLM in your pipeline should never write straight to your data store. Put a human tap between the model and persistence.

(Part 5 of Building CannyCart, a voice-first shopping app I'm building in public. The last three posts were the backend and the build traps; this is the feature all of it existed for.)

The goal, and the one constraint that shaped everything

The goal is boring to state and hard to earn: say what you want to buy, get a clean editable list. Quantities resolved ("a dozen" → 12), items title-cased and singular ("bananas" → Banana), each dropped into an aisle so the list sorts itself.

The constraint is the whole story. An LLM is very good at this and occasionally wrong — it will mishear "eggs" as "legs," miscount, or confidently invent a category. That's fine for a suggestion and unacceptable for a data store. So the rule I built around: Claude never writes to the database. It proposes; the user disposes. Everything below serves that line.

The pipeline in one breath

mic
 └─ expo-speech-recognition (on-device)      → transcript string
     └─ parseShoppingList mutation (AppSync)  → parse-shopping-list Lambda
         └─ Claude Haiku                       → JSON [{name,quantity,unit,category,note}]
             └─ review sheet (client)          → user edits / removes / confirms
                 └─ addItems()                  → ShoppingItem rows created

Five hops, and the LLM sits in the middle with no write access to anything.

Step 1: on-device speech, accumulating a transcript

Speech-to-text is expo-speech-recognition (iOS SFSpeechRecognizer / Android SpeechRecognizer), wrapped in a hook. The one subtlety: the recognizer streams two kinds of result — interim guesses that change as you speak, and final segments that don't. The UI needs both: finalized text stays put while the live guess trails after it, greyed out.

useSpeechRecognitionEvent("result", (event) => {
  const text = event.results[0]?.transcript ?? "";
  if (event.isFinal) {
    setTranscript((prev) => (prev ? `${prev} ${text}` : text).trim());
    setInterim("");
  } else {
    setInterim(text); // live guess for the current utterance
  }
});

Running with continuous: true means it keeps listening across pauses, so you can think mid-sentence. On stop, transcript + interim is the full text to parse.

Step 2: the prompt is the parser

Here's the part people expect to be complicated and isn't. The Lambda barely does anything — the parsing logic lives entirely in a system prompt. This is the extraction contract, trimmed:

You extract items a shopper wants to buy from their spoken words.
Return ONLY a JSON array — no prose, no code fences. Each element:
{ "name": string, "quantity": number, "unit": string|null,
  "category": string|null, "note": string|null }

Rules:
- quantity defaults to 1; convert words to numbers ("a dozen" → 12, "a couple" → 2).
- category: for groceries use aisle names (Produce, Dairy, Bakery, Meat,
  Frozen, Pantry, Drinks, Household); else a short department (Electronics…).
- name is the item only, singular and title-cased ("bananas" → "Banana").
- note captures qualifiers ("ripe", "low-fat", "new") or null.
- Return [] only when the text mentions nothing to buy.

The model is Haiku — cheap and fast, which is exactly right for short structured extraction:

const MODEL = "claude-haiku-4-5";

const message = await anthropic.messages.create({
  model: MODEL,
  max_tokens: 1024,
  system: SYSTEM_PROMPT,
  messages: [{ role: "user", content: text }],
});

And because a model told to emit raw JSON will occasionally wrap it in a code fence anyway, the Lambda is defensive before it trusts the output:

const cleaned = raw.replace(/^```
{% endraw %}
(?:json)?\s*/i, "").replace(/\s*
{% raw %}
```$/i, "").trim();
let parsed: ParsedItem[];
try {
  parsed = JSON.parse(cleaned);
} catch {
  throw new Error(`Model returned invalid JSON: ${raw.slice(0, 200)}`);
}
if (!Array.isArray(parsed)) throw new Error("Model did not return a JSON array");

return JSON.stringify(parsed); // a.json() custom mutations return AWSJSON

Strip fences, parse, assert it's an array, and only then hand it back. If the model returns garbage, the mutation throws and the client shows an error — it does not pass mystery data downstream.

Step 3: the review gate — the whole point

The mutation is declared to return items, not create them:

parseShoppingList: a
  .mutation()
  .arguments({ text: a.string().required() })
  .returns(a.json())            // ← returns parsed items…
  .handler(a.handler.function(parseShoppingList))
  // …and there is no .create() anywhere in the handler. It never persists.

On the client, capture runs through a tiny state machine — the phases are the UX:

type Phase = "listening" | "parsing" | "review" | "empty" | "error";

listening shows the pulsing mic and transcript; parsing shows a spinner while Haiku works; review renders the editable list; empty/error are the honest failure states (heard nothing, or the parse threw). Only review can lead to a write.

The review sheet is where the human tap lives. Every parsed item is an editable row: rename it, step the quantity up or down, see its category chip, delete it, add a blank row by hand, or record more and append. Nothing has touched the database yet. Then:

onAdd={() => {
  const clean = items.filter((i) => i.name.trim());
  addItems.mutate({ listId, items: clean }, {
    onSuccess: () => toast.show(`Added ${clean.length} items`, { type: "success" }),
  });
}}

addItems is the only path that creates ShoppingItem rows — a plain typed create per item, owned by the user's Cognito sub. That single tap is the entire safety model: the AI's output is a draft until a human signs it.

The gotcha: the API key that wouldn't reach the Lambda

One dead end worth saving you. I first wired ANTHROPIC_API_KEY through Amplify's secret() — the "correct" way to handle secrets. In the sandbox, the function kept booting with an undefined key: its deploy-time secret resolution simply wasn't delivering the value to the function. I switched to injecting it as a plain Lambda environment variable, baked at deploy from the deployer's own environment (locally via a sandbox script; on branch builds via Amplify Console env vars):

export const parseShoppingList = defineFunction({
  name: "parse-shopping-list",
  entry: "./handler.ts",
  timeoutSeconds: 30,
});
// backend.ts injects process.env.ANTHROPIC_API_KEY as a normal env var.

Not glamorous, but it deployed and the key was there at runtime. (If you're keeping score with Post 2: this app and environment variables have history.)

Details worth stealing

AWSJSON can arrive double-encoded. Depending on the layer, a.json() comes back as a string, or a string of a string. The client unwraps until it's an object: while (typeof value === "string") value = JSON.parse(value);
ShoppingItem.price exists but is unused in v1. It's forward-compat for the Expenses tab — the category Claude infers today is what makes per-aisle spend possible later.
Ownership is app-layer. Every item carries userId = Cognito sub, every read filters it, and "delete" flips a soft-delete trio rather than removing the row. The AI feature inherits all of it for free.

What's next

The obvious upgrades: stream the parse so items pop in one by one instead of after a beat, and add optimistically so the list feels instant. But the bigger thread is that reserved price field — the next feature is the Expenses tab, turning a checked-off shopping list into per-aisle spend. Claude's categories were always seeds for that.

If you've put an LLM in a real product: where did you draw the line between "the model suggests" and "the model acts"? I'm convinced the review gate is right for anything that writes to a user's data — but I'd like to hear where you'd let the model off the leash.

My main branch wouldn't deploy: CloudFormation forensics on Amplify Gen 2

Ibukun Demehin — Mon, 20 Jul 2026 16:03:03 +0000

My dev branch deployed clean. The exact same commit on main — the merge that fast-forwarded dev into main, byte-for-byte identical backend — rolled back every single time. Amplify Hosting went red, CloudFormation logged ROLLBACK_COMPLETE, and the only explanation it offered was this:

Validation failed with 1 error(s). Call DescribeEvents to retrieve the
full list of issues with resource and property details, resolve each
error, then retry the operation.

No resource name I could act on. No property. One error, unnamed. Here's how I found the one error — and it turned out to be a name two git branches had been quietly fighting over.

TL;DR — On Amplify Gen 2, dev and main are branches of the same Amplify app. If you publish an SSM parameter keyed only on the app id (/myapp/${AWS_APP_ID}/…), both branches generate the identical parameter name. Whichever deploys first owns it; the second branch's deploy dies with a bare Validation failed with 1 error(s) on exactly the nested stack that creates the parameter, then ROLLBACK_COMPLETE. Fix: put the environment in the path (/myapp/${AWS_APP_ID}/${env}/…).

(Part 4 of Building CannyCart, a voice-first shopping app I'm building in public. Self-contained CloudFormation debugging story — no earlier context needed.)

The setup: one app, two branches, a shared backend

For anyone landing here from the error text: AWS Amplify Gen 2 (CDK under the hood), deployed via ampx pipeline-deploy in Amplify Hosting. One Amplify app, two branches wired to it — dev and main. The backend is shared code: Cognito auth, an AppSync GraphQL API, and three DynamoDB-backed models — UserProfile, ShoppingList, ShoppingItem.

One detail matters more than any other, so here it is up front. A post-confirmation Lambda needs the UserProfile table name. You can't hand a Lambda a table name as a CDK token across stacks — auth depends on data, data would depend on auth, and the deploy fails with a circular dependency. The house pattern (and AWS's recommendation) is to publish the name to SSM Parameter Store from inside the table's own stack, and give the Lambda only the SSM path string:

const amplifyAppId = process.env.AWS_APP_ID ?? "local";
const ssmPrefix = `/cannycart/${amplifyAppId}`;          // ← the bug lives here

const userProfileParamName = `${ssmPrefix}/UserProfileTableName`;
new StringParameter(Stack.of(userProfileTable), "UserProfileTableNameParam", {
  parameterName: userProfileParamName,
  stringValue: userProfileTable.tableName,
});

Read that ssmPrefix and hold onto it. It's keyed on the app id and nothing else.

dev worked. Then I merged to main.

dev had been deploying happily for days. I opened a PR, merged dev into main, and watched the first main build. It got a long way:

✔ Backend synthesized in 13.23 seconds
✔ Type checks completed in 15.43 seconds
✔ Built and published assets

Then CloudFormation started creating resources for real. Auth stack: complete. The data stack came up and began creating the three model stacks in parallel. Two of them sailed through:

CREATE_COMPLETE | AWS::CloudFormation::Stack | ShoppingList.NestedStackResource
CREATE_COMPLETE | AWS::CloudFormation::Stack | ShoppingItem.NestedStackResource

And the third:

CREATE_FAILED | AWS::CloudFormation::Stack | …UserProfileNestedStack…
  Validation failed with 1 error(s). Call DescribeEvents to retrieve the
  full list of issues…

That failure rolled straight up the tree:

CREATE_FAILED | data.NestedStackResource | Embedded stack … was not
  successfully created: The following resource(s) failed to create:
  [amplifyDataUserProfileNestedStackUserProfileNestedStackResource…].
ROLLBACK_IN_PROGRESS | amplify-…-main-branch-… | Rollback requested by user.

Four minutes of DELETE_IN_PROGRESS later — the whole backend, auth pool and all, torn back down — it ended where every attempt ended:

ROLLBACK_COMPLETE | AWS::CloudFormation::Stack | amplify-…-main-branch-…

Same commit as dev. Green synth, green type-check. Dead on create.

Wrong theory: "it's a flaky deploy, just retry"

The rollback message literally says "Rollback requested by user," which reads like something transient — as if a retry would clear it. It won't, and that phrasing is a red herring: "user" is CloudFormation's own deployment role, and the rollback was requested because a resource failed, not because anything flaked. I re-ran the build. It failed at the identical stack with the identical bare validation error. Whatever this was, it was deterministic and it was specific to main.

The clue the log did give me: only UserProfile died

Here's the thing I almost scrolled past. Three model stacks were created in the same deploy, from the same schema, with the same auth rules. ShoppingList and ShoppingItem both succeeded. Only UserProfile failed.

If this were a broken schema or a bad credential or a region problem, all three would fail. One failing — and the same one every time — means UserProfile has something the other two don't. So what's different about UserProfile?

Back to that code. ShoppingList and ShoppingItem are plain models. UserProfile is the only stack that also creates an extra resource: the UserProfileTableNameParam SSM StringParameter. Of everything unique to that one stack, a named, must-be-globally-unique resource is the obvious suspect. The bare "Validation failed" was CloudFormation refusing to create a parameter — and the reason was one DescribeEvents call deeper than the build log prints.

The actual cause: two branches, one parameter name

The parameter name is /cannycart/${AWS_APP_ID}/UserProfileTableName. AWS_APP_ID is the Amplify app id — and dev and main are two branches of the same app. They resolve AWS_APP_ID to the identical value. So both branches try to create the exact same SSM parameter:

/cannycart/d216bdrgjoaojz/UserProfileTableName

dev deployed first and created it. When main deployed and its UserProfile stack tried to create the same parameter name, SSM rejected it — the parameter already exists — and CloudFormation surfaced that rejection as the maddeningly generic Validation failed with 1 error(s). The final toolkit error names the culprit stack twice but still never prints the reason:

[CloudFormationDeploymentError] The CloudFormation deployment has failed.
  ROLLBACK_COMPLETE: Embedded stack …UserProfileNestedStack… was not
  successfully created: Validation failure detected. See the operation's
  FAILED event for details.

The reason lived only in the FAILED event, behind DescribeEvents. The build log will point at the stack all day; it will not tell you the parameter was a duplicate.

The fix: put the environment in the path

An app-id-only namespace assumes one deploy per app. The moment a second branch of the same app deploys, the namespace collides. The fix is to make the path unique per environment — main → prod, other branches → the branch name, local sandbox → your username:

- const ssmPrefix = `/cannycart/${amplifyAppId}`;
+ // dev and main are branches of the SAME Amplify app, so an app-id-only
+ // path collides between them. env makes it unique per environment.
+ const ssmPrefix = `/cannycart/${amplifyAppId}/${env}`;

Now dev publishes /cannycart/d216bdrgjoaojz/dev/UserProfileTableName and main publishes /cannycart/d216bdrgjoaojz/prod/UserProfileTableName. No collision. main deployed green on the next run.

What I took away

A nested-stack rollback hides its real reason one level down. Validation failed with 1 error(s) in the build log is a pointer, not an answer — the actual cause is behind DescribeEvents / the stack's FAILED event in the console. Go there first instead of theorizing.
When N identical things deploy and only one fails, debug the difference. Two model stacks succeeded and one didn't; the failing one was the only one creating a named global resource. That asymmetry was the whole case.
Namespace shared infrastructure by environment, not just by app. Any globally-unique name — SSM parameters, S3 buckets, IAM roles — keyed on AWS_APP_ID alone will collide the instant a second branch of that app deploys. Put the env in the key from day one.
"It works on dev" can mean "dev got there first." A resource that another environment already created will fail silently for the next one. Shared-app, multi-branch setups make this a standing trap.

Next up

The feature this whole backend exists for: talking to your shopping list. You say "milk, a couple of bananas, a dozen eggs," and on-device speech recognition plus a Claude Haiku extraction Lambda turn it into a categorised, structured list — with a review step so a bad parse never silently pollutes your data. That's Post 5.

What's the most useless "helpful" error message your cloud provider has handed you? Validation failed with 1 error(s) — with the one error omitted — is my current favourite.

Set up React Query on an Expo Project

Ibukun Demehin — Mon, 20 Jul 2026 15:28:23 +0000

There is a good chance that you will need to interact with an external API to receive and send data, and with React Query, it makes the process easy and lets us focus on the data more than the logic of getting the data. In this blog post, we'll guide you through the steps to set up a React Native project using Expo and integrate it with React Query, ensuring you can manage your API requests efficiently.

Step 1: Set Up Your Expo Project

The first step is to create a new Expo project. Expo is a framework and a platform for universal React applications, and it simplifies the process of developing and deploying React Native apps.

If you have existing project then you can skip this step and move on to step 2

Install Expo CLI: If you haven't already, you need to install the Expo CLI. You can do this globally using npm:

You could use any other package manager you are comfortable with at this time, just replace the npm install command with the appropriate installation instruction of your preferred package

npm install -g expo-cli

Create a New Expo Project: Now, create a new project using the Expo CLI:

expo init my-react-native-query-app

Choose a template based on your preference.

Step 2: Install React Query & Required Dependencies

React Query is a powerful tool for managing server state in your React and React Native applications. It provides hooks to fetch, cache, and sync your data without requiring global state management.

Install React Query

npm install @tanstack/react-query

Install Required Dependencies

npx expo install @react-native-community/netinfo

Step 3: Create Helper Functions for the project

We will create three functions that we will need in this project. The functions will be custom hooks and we can have it saved in a subfolder called hooks at the root directory.

Create useAppState.ts function

import NetInfo from '@react-native-community/netinfo'
import { onlineManager } from '@tanstack/react-query'

onlineManager.setEventListener((setOnline) => {
  return NetInfo.addEventListener((state) => {
    setOnline(!!state.isConnected)
  })
})

This function will perform auto-refetch anytime your reconnect your app to a working internet if you went offline

Create UseOnlineManager.ts function

import { useEffect } from 'react'
import { AppState, Platform } from 'react-native'
import type { AppStateStatus } from 'react-native'
import { focusManager } from '@tanstack/react-query'

function onAppStateChange(status: AppStateStatus) {
  if (Platform.OS !== 'web') {
    focusManager.setFocused(status === 'active')
  }
}

useEffect(() => {
  const subscription = AppState.addEventListener('change', onAppStateChange)

  return () => subscription.remove()
}, [])

Instead of event listeners on window, React Native provides focus information through the AppState module. We will use the AppState "change" event to trigger an update when the app state changes to "active"

Create useRefreshOnFocus.ts function

import React from 'react'
import { useFocusEffect } from '@react-navigation/native'

export function useRefreshOnFocus<T>(refetch: () => Promise<T>) {
  const firstTimeRef = React.useRef(true)

  useFocusEffect(
    React.useCallback(() => {
      if (firstTimeRef.current) {
        firstTimeRef.current = false
        return
      }

      refetch()
    }, [refetch]),
  )
}

In some situations, you may want to refetch the query when a React Native Screen is focused again. This custom hook will call the provided refetch function when the screen is focused again.

Step 4: Implement all the functions in your root file

Whatever your main route file might be based on how your project is set up, you can add the below code right there

import {
  QueryClient,
  QueryClientProvider,
  focusManager,
} from "@tanstack/react-query";
import { AppStateStatus, Platform } from "react-native";
import { useOnlineManager } from "@/hooks/query/useOnlineManager";
import { useAppState } from "@/hooks/query/useAppState";

export default function RootLayout() {
  function onAppStateChange(status: AppStateStatus) {
    if (Platform.OS !== "web") {
      focusManager.setFocused(status === "active");
    }
  }

  const queryClient = new QueryClient({
    defaultOptions: { queries: { retry: 2 } },
  });

  useOnlineManager();

  useAppState(onAppStateChange);
  <QueryClientProvider client={queryClient}>
    {Rest of your project}
  </QueryClientProvider>
}

With this, you'll be able to use react query in your mobile development just the same way you use it in web

Start the Development Server: In your terminal, navigate to the folder that Expo created with all of the boilerplate set-up and run

expo start

Expo projects can be built quickly using Expo Go app that can be downloaded on your phone but it is encouraged to build a development app instead from the beginning of your project. You can see the docs on how to do that.

Conclusion

By setting up an Expo React Native project with React Query, you can streamline the process of managing server state and interacting with APIs. React Query's powerful features, such as caching, background updates, and synchronization, allow you to focus on what truly matters—the data, not the data-fetching logic.

HAPPY CODING 👨🏼‍💻 👩🏻‍💻 💻

Climbing the Leaderboard - HackerRank Solution (Javascript) 🚀

Ibukun Demehin — Mon, 20 Jul 2026 15:27:52 +0000

An arcade game player wants to climb to the top of the leaderboard and track their ranking. The game uses Dense Ranking, so its leaderboard works like this:

The player with the highest score is ranked number 1 on the leaderboard.
Players who have equal scores receive the same ranking number, and the next player(s) receive the immediately following ranking number.

Function Description

Complete the climbingLeaderboard function in the editor below.

climbingLeaderboard has the following parameter(s):

int ranked[n]: the leaderboard scores
int player[m]: the player's scores

Returns

int[m]: the player's rank after each new score
Input Format

The first line contains an integer n, the number of players on the leaderboard.
The next line contains n space-separated integers ranked[i], the leaderboard scores in decreasing order.
The next line contains an integer, m, the number games the player plays.
The last line contains m space-separated integers [j], the game scores.

function climbingLeaderboard(ranked, player) {
    // Write your code here
    // Remove duplicates from the ranked list and sort in descending order
    let uniqueRanks = [...new Set(ranked)];

    let playerRankings = [];
    let index = uniqueRanks.length - 1;

    player.forEach(score => {
        while (index >= 0 && score >= uniqueRanks[index]) {
            index--;
        }
        playerRankings.push(index + 2); // Rank is index + 2 because index starts from 0 and we want the 1-based rank
    });

    return playerRankings;
}

Every icon vanished: a Metro debugging story (featuring a babel package from 2017)

Ibukun Demehin — Mon, 20 Jul 2026 15:27:31 +0000

I added a font and a few icons. Then I ran a development build, and Metro died 2,513 modules in with an error that had nothing to do with either:

iOS Bundling failed
TypeError: Cannot read properties of undefined (reading 'transformFile')

No filename. No line number. Every build failed the same way. The trail ran through two rewrites of an icon library and ended at a @babel/types published in 2017 — 7.0.0-beta.4 — sitting in my node_modules, dragged in by a package I never installed on purpose. Here's the hunt.

TL;DR — A Metro TypeError: Cannot read properties of undefined (reading 'transformFile') with no filename almost always means a broken Babel toolchain, not your code. Mine was an ancient @babel/types@7.0.0-beta.4 (2017) resolved for the transform, pulled in transitively by @aws-amplify/graphql-types-generator. Fix: pin @babel/types and @babel/generator (and react-native-worklets) with overrides in the root package.json.

(Part 3 of Building CannyCart, a voice-first shopping app I'm building in public. This one's a self-contained debugging story — no earlier context needed.)

The build that wouldn't build

The setup, for anyone who lands here from a search: Expo SDK 57, expo-router, NativeWind, with an Amplify Gen 2 backend in the same npm-workspaces monorepo. Icons come from react-native-iconify, which uses a Babel plugin to scan JSX for <Iconify icon="…" /> and inline the SVG at build time. I was wiring up the app's icon set and building a dev client.

Metro started bundling, churned through 2,513 modules, and threw:

TypeError: Cannot read properties of undefined (reading 'transformFile')

No file. No stack into my code. Fully reproducible. When the error names nothing you wrote, the call is coming from inside the toolchain.

Wrong theory #1: the icon library's Babel plugin

react-native-iconify runs during the Babel transform Metro invokes — exactly the kind of thing that can nuke transformFile. And I'd recently bumped its version. Version 2 had restructured its exports: the Babel plugin moved from ./plugin (v1) to ./babel (v2), so my babel.config.js reference looked like a prime suspect.

I fixed the reference to match v2. The crash didn't clear — it moved. Plausible theory, wrong theory: a broken plugin path was real, but it wasn't what was killing the bundler.

Wrong theory #2: it must be worklets

Now the error mutated into something more specific, from react-native-worklets' Babel plugin:

unknown node TSUnknownKeyword

So worklets was choking on a TypeScript AST node. Maybe worklets was the culprit and I needed to pin it. But TSUnknownKeyword is a perfectly normal node type — it exists in any modern @babel/types. If a plugin claims a standard node is "unknown," the plugin isn't broken; it's been handed an ancient @babel/types that predates that node. That was the tell. I stopped chasing plugins and went looking at versions.

The turn: reading the lockfile

I grepped package-lock.json for every @babel/types version in the tree:

 13 "@babel/types": "^7.29.7"
  3 "@babel/types": "^7.29.0"
  1 "@babel/types": "^7.27.1"
  # … a few more 7.2x ranges …
  1 "@babel/types": "7.0.0-beta.4"

One line didn't belong. Everything modern asked for a caret range around 7.29. And then, alone at the bottom: 7.0.0-beta.4. Not a range — an exact pin. A beta. Of a package whose current release is 7.29. 7.0.0-beta.4 shipped in 2017.

A 2017 beta hiding in the tree

Who pins an eight-year-old beta of @babel/types? Tracing it back, the culprit was @aws-amplify/graphql-types-generator — an Amplify GraphQL codegen tool, itself a museum of old transitive deps (its own private copies of yargs, prettier, camelcase from another era). One of them locks @babel/types to that exact 2017 build.

Here's the mechanism. @babel/generator and the worklets plugin construct and inspect AST nodes through @babel/types helpers. Between the 2017 beta and 7.29, @babel/types grew an enormous number of those helpers — including builders and validators for TypeScript nodes like TSUnknownKeyword. When npm's resolution let the old copy serve part of the transform, a modern plugin reached for a helper that didn't exist in the 2017 version, got undefined, and called a method on it. Metro surfaced that as Cannot read properties of undefined (reading 'transformFile'). The "unknown node" error and the "transformFile" error were the same root cause wearing two masks.

The fix: one `overrides` block

npm's overrides (Yarn calls it resolutions) forces a single version of a package across the entire dependency tree, no matter who asked for what. In the root package.json:

"overrides": {
  "@babel/types": "7.29.7",
  "@babel/generator": "7.29.7",
  "react-native-worklets": "0.10.0"
}

@babel/types and @babel/generator pinned to a matching modern pair; react-native-worklets pinned to the build that plays nicely with SDK 57's reanimated. Then rm -rf node_modules && npm install. The bundle went green.

overrides is a sledgehammer — it bypasses semver for everyone in the tree — so it's a last resort. But when the problem is a transitive dependency four levels down pinning something incompatible, it's the only wrench that reaches.

The coda: a green bundle that rendered nothing

The bundler lived, but the icons still weren't right. iconify v2 now threw at build time:

[React Native Iconify] Icon 'mdi:account-circle-outline' not found in babel.config.js

v2 had changed its whole model: instead of auto-scanning JSX, it wants an explicit icon allowlist registered in an app entry file. Under expo-router there is no classic App.js entry to host that registry, so the icons never got registered.

The trap was the feedback. expo export completed successfully — green, no errors — while the icons rendered as null in the actual app, silently. A passing bundle told me nothing about whether a single icon would appear on screen. I confirmed the name wasn't a typo (Iconify's API answers https://api.iconify.design/mdi.json?icons=account-circle-outline), then tested at the Babel-transform level and watched v2's registry simply not inject under expo-router. I downgraded to react-native-iconify@^1.0.2, whose plugin auto-scans JSX and inlines the SVG with no registry and no entry file. Icons came back.

What I took away

A transformFile error that names no file is almost never your code. It's the Babel/Metro toolchain. Check the installed versions of your @babel/* packages before you touch your own config.
overrides / resolutions is the tool for transitive-dependency conflicts. When something deep in the tree pins an incompatible version, this is how you reach past it.
A green build is not a green render. expo export passing meant the bundle compiled, not that the UI worked. For anything that can fail silently at runtime — icons, fonts, native modules — verify on a device, not in CI logs.

Next up

The main branch that refused to deploy while dev worked perfectly:

CREATE_FAILED … Validation failed with 1 error(s).
ROLLBACK_COMPLETE

That's CloudFormation forensics on Amplify Gen 2, and the cause was a name two git branches were quietly fighting over. Post 4.

What's the oldest package you've found lurking in your node_modules? 7.0.0-beta.4 from 2017 is my record — I'd love to be beaten.