Skip to content

New categories saved but rendered nowhere - #221

Merged
brianorwhatever merged 1 commit into
mainfrom
fix/show-empty-user-categories
Jul 31, 2026
Merged

New categories saved but rendered nowhere#221
brianorwhatever merged 1 commit into
mainfrom
fix/show-empty-user-categories

Conversation

@brianorwhatever

@brianorwhatever brianorwhatever commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Adding a category looked like it silently failed. It didn't — it saved and then rendered nowhere.

Verified against prod before changing anything: the list already had both categories stored.

itemCategories: 18 saved
    🥬 Produce …
    🏷️ Food (id=food)      ← added, never displayed
    🏷️ test (id=test)      ← added, never displayed
    🛒 Other (id=other)

Cause

groupByCategory dropped every category with no items. That was right while categories were implicit — a five-item grocery list shouldn't be buried under 15 unused aisle headers — and wrong the moment users create categories by hand. It also left no drop target: you can't drag an item into a category that isn't rendered, so a new category could never receive its first item.

Fix

Visibility keys off a new isPristineDefault: an empty category is hidden only when it's a built-in the user has never touched.

Category Empty Shown
Untouched built-in (Bakery) yes no — keeps short lists clean
User-added (Luggage) yes yes
Renamed built-in (Produce → Fruit) yes yes — renaming signals intent
Re-emoji'd built-in yes yes
Other yes no — noise until something lands in it

On how this shipped

The old behaviour had a passing test asserting it ("groupByCategory omits empty categories, including Other"). It encoded the previous assumption rather than the requirement, so it locked in the bug instead of catching it. Replaced with cases for an added category, a renamed built-in, and a re-emoji'd built-in.

151 pass / 0 fail. Both typechecks clean; lint unchanged.

After merge

Wait for Railway, then reload — "Food" and "test" are already in your list and will simply appear. Nothing to re-create.

🤖 Generated with Claude Code

Note

Show empty user-created and modified categories that were previously hidden

  • groupByCategory in categories.ts previously hid all empty categories; it now hides only empty built-in categories that are untouched (same name and emoji as the default).
  • A new isPristineDefault predicate in itemCategories.ts checks whether a category matches its original built-in definition by id, name, and emoji.
  • User-created categories and renamed or re-emoji'd built-ins are now included in grouped results with an empty items array when they have no items.
  • Behavioral Change: empty categories that were previously omitted from results will now appear if the user created or modified them.

Macroscope summarized c62f59d.

Adding a category appeared to do nothing — it saved to the list and then
rendered nowhere, because groupByCategory dropped every category with no items.
Verified against prod: the list had "Food" and "test" stored in itemCategories
while neither showed in the UI.

That filter was correct while categories were implicit — a short grocery list
should not be buried under 15 unused aisle headers — but wrong the moment users
create categories by hand. It also left no drop target: an item cannot be
dragged into a category that is not rendered.

Visibility now keys off isPristineDefault: an empty category is hidden only when
it is a built-in the user has never touched. Anything added, renamed or
re-emoji'd stays visible with no items. An empty Other is still hidden — it is
noise until something lands in it.

The previous behaviour had a test asserting it, which is why this shipped. That
test encoded the old assumption rather than the requirement; replaced with cases
covering an added category, a renamed built-in, and a re-emoji'd built-in.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@brianorwhatever
brianorwhatever merged commit adce775 into main Jul 31, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant