Project settings: tabbed & grouped marker types — implementation plan¶

Source: user request (not from docs/features/future/backlog.md — the only grouping line there, "group the entries by type" under "Map Edit View Sidebar", is about the map-edit sidebar's POI list, already shipped per map-edit-sidebar-poi-list.md, and is a different screen from this one).

Today, project.tsx's Settings tab renders three stacked sections — "Point of interest types", "Line types", "Area types" — each a flat ItemGroup list, separated by <Separator />. Each type (PoiTypeDefinition/LineTypeDefinition/AreaTypeDefinition in app/lib/poi.ts/line.ts/area.ts) already has an optional group: string field, set via a free-text Input in PoiTypeForm/LineTypeForm/ AreaTypeForm, but nothing currently reads it for display.

This plan replaces the three stacked sections with a nested Point/Line/Area tab bar, groups each tab's list by group, and upgrades the group form field from free text to the existing Combobox component (suggests this project's existing groups for that kind, still accepts a new typed value).

Three parts, sequenced so each leaves project.tsx type-checking and shippable on its own:

1. Structural tab bar (pure reshuffle, no behavior change).
2. Grouped headings within each tab.
3. group field becomes a Combobox in the three add/edit forms.

Cross-cutting decisions¶

Out of scope¶

• Reordering groups manually, renaming a group across all its types in one action, or deleting an empty group.
• Any change to app/components/feature-control.tsx (the map-edit sidebar's own grouped checkbox list) — used only as a reference pattern.
• Grouping/tabs beyond Point/Line/Area (e.g. nested sub-groups).

Part 1: Point/Line/Area tab bar (structural only)¶

Goal¶

The Settings tab shows a nested tab bar (Point, Line, Area) in place of the three stacked, separator-divided sections. No grouping or form changes yet — each tab's content is exactly today's existing list markup, moved as-is.

Scope¶

In: wrapping the existing "Point of interest types" / "Line types" / "Area types" blocks (currently ~project.tsx lines 960–1251) each in its own TabsContent, under one new nested Tabs/ TabsList/TabsTrigger bar; removing the two <Separator />s that currently divide them.

Out: grouping by group (Part 2); any change to the add/edit forms (Part 3); the outer Maps/Settings tab bar (unchanged).

Tasks¶

T1 — Nest a nested tab bar around the three type sections¶

Goal: Selecting Point, Line, or Area shows only that kind's existing list/add-button/inline-form block; nothing else changes.

Acceptance criteria:

• A <Tabs defaultValue="point"> with a <TabsList> containing three <TabsTrigger>s ("Point", "Line", "Area") renders where the three <Separator />-divided <div> blocks currently sit inside the outer Settings TabsContent.
• Each existing block (heading + Add-type button + ItemGroup + inline add form) moves, unmodified, into its own <TabsContent value="point" | "line" | "area"> — same JSX, same conditions (isAddingType / editingTypeSlug etc.), just re-parented.
• The two <Separator /> elements that previously divided the three sections are removed (a tab bar replaces the need for a divider).
• No new useState, fetcher, or server code is added in this task.
• pnpm typecheck passes.
• Manual check: pnpm dev, open a project's Settings tab, confirm all three tabs show their previously-existing content unchanged, and that add/edit/delete on each still work exactly as before.

Part 2: Grouped headings within each tab¶

Depends on Part 1 (grouping renders inside the new TabsContents, so Part 1's structure must exist first).

Goal¶

Within each of the three tabs, types sharing a group value render under a heading for that group; types with no group render under a trailing "Ungrouped" heading. Alphabetical group order.

Scope¶

In: a shared grouping helper; heading markup inserted into each of the three ItemGroup lists; sorting groups alphabetically with "Ungrouped" forced last.

Out: any change to how an individual Item row renders, how add/edit forms behave (Part 3), or how usage counts (countPoiTypeUsage etc.) are computed.

Data model¶

// app/routes/project.tsx — local helper, not exported
function groupByField<T extends { group?: string }>(
  items: T[]
): { group: string; items: T[] }[]

• Buckets items by group, one bucket per distinct value plus one bucket for items with no group.
• Returns buckets sorted alphabetically (case-insensitive) by group, with the no-group bucket last, its group set to the literal string "Ungrouped".

Tasks¶

T2 — groupByField helper¶

Goal: One helper produces alphabetically-sorted, "Ungrouped"-last buckets for any of the three type arrays.

Acceptance criteria:

• groupByField is defined once in project.tsx (near the other local helpers like countPoiTypeUsage) with the signature above.
• Alphabetical comparison is case-insensitive; the "Ungrouped" bucket is always last regardless of its position in a case-insensitive sort.
• An input with no group-less items produces no "Ungrouped" bucket (empty buckets aren't rendered).
• pnpm typecheck passes.

T3 — Render group headings in all three tabs¶

Goal: Each tab's ItemGroup list is broken into per-group sections with a heading, using groupByField.

Acceptance criteria:

• The Point tab maps groupByField(project.poiTypes) and renders a heading (e.g. <h3>) per bucket's group name above that bucket's existing Item rows; same for Line (project.lineTypes) and Area (project.areaTypes).
• The existing per-row edit-in-place behavior (editingTypeSlug etc. swapping a row for its form) continues to work unchanged inside a group's bucket.
• The inline "add type" form (isAddingType etc.) keeps its current position (end of the list) and is not itself grouped.
• A project with no types set for any of its entries (all group undefined) shows a single "Ungrouped" heading, not a headingless flat list — consistent, predictable structure over a special-cased empty state.
• pnpm typecheck passes.
• Manual check: pnpm dev, set a group on a couple of POI types via Edit, confirm they render under a shared heading, and ungrouped ones fall under a trailing "Ungrouped" heading; repeat for Line and Area.

Part 3: group field becomes a Combobox¶

Independent of Parts 1–2 (touches the add/edit forms, not the list display), but sequenced last since it's the most novel piece of UI.

Goal¶

In PoiTypeForm, LineTypeForm, and AreaTypeForm, the group field is a Combobox (from app/components/ui/combobox.tsx) offering that project's existing group names for the matching kind as suggestions, while still accepting a freshly typed new group name.

Scope¶

In: replacing the <Input name="group" .../> in all three forms with a Combobox-based field, backed by a hidden input name="group" carrying whatever value/typed text is current, sourced from a per-kind distinct- groups list computed from project.poiTypes / lineTypes / areaTypes.

Out: any change to the action's group handling (already accepts any string), or to groupByField from Part 2 (a separate, simpler distinct- values list is computed here, per kind).

Data model¶

// app/routes/project.tsx — local helper, not exported
function distinctGroups(items: { group?: string }[]): string[]

• Returns the distinct, alphabetically-sorted (case-insensitive) group values present in items, excluding undefined/empty.

Tasks¶

T4 — distinctGroups helper¶

Goal: Each form can be given the right suggestion list for its kind.

Acceptance criteria:

• distinctGroups is defined once in project.tsx with the signature above.
• Called as distinctGroups(project.poiTypes) / distinctGroups(project.lineTypes) / distinctGroups(project.areaTypes) and passed into PoiTypeForm/LineTypeForm/AreaTypeForm as a new groupOptions: string[] prop.
• pnpm typecheck passes.

T5 — Swap the group Input for a Combobox in all three forms¶

Goal: The group field in each form lets a user pick an existing group for that kind or type a brand-new one, and the chosen/typed value still submits as a plain group string field.

Acceptance criteria:

• PoiTypeForm, LineTypeForm, and AreaTypeForm each gain a groupOptions: string[] prop (from T4) and replace their group <Input> with a Combobox built from Combobox/ComboboxInput/ ComboboxContent/ComboboxList/ComboboxItem/ComboboxEmpty (app/components/ui/combobox.tsx), listing groupOptions as items.
• The combobox is initialized from defaultValues?.group when editing an existing type (same as the current Input's defaultValue).
• Typing a value not present in groupOptions and submitting the form still saves that typed value as the type's group (same free-text behavior as today) — the combobox constrains suggestions, not input.
• Clearing the field and submitting still saves an undefined/no group (matching today's "blank clears the field" behavior from the group || undefined handling already in the action).
• A hidden <input type="hidden" name="group" value={...} /> continues to be what the form actually submits, so no action/server code changes.
• pnpm typecheck passes.
• Manual check: pnpm dev, open the Add-type form for each kind, confirm existing groups (for that kind only) show as suggestions, typing a new group name and saving works, and editing a type pre-fills its current group.