Follows-up to #711
Created by @JeroenDeDauw with Claude Code.
Context: NeoWiki select property type implementation, competitive analysis of Notion/Airtable/Coda.
Written by Claude Code, Opus 4.6
Summary
The select property type currently stores options as plain strings (e.g. ["Draft", "Review", "Approved"]). All major competitors (Notion, Airtable, Baserow, NocoDB) support per-option colors, rendering selected values as colored tags/chips.
The current data model is forward-compatible — options could later become objects with label + color (e.g. [{"label": "Draft", "color": "blue"}, ...]) without changing the property type name or storage value type.
What to consider
- Named colors from a fixed palette (like Notion:
"blue", "green", "red") vs hex codes (like NocoDB)
- Auto-assignment of colors when options are created
- Colored rendering in infobox display, subject editor chips, and schema display
- Migration path from plain string options to object options
Related: #719
Follows-up to #711
Summary
The select property type currently stores options as plain strings (e.g.
["Draft", "Review", "Approved"]). All major competitors (Notion, Airtable, Baserow, NocoDB) support per-option colors, rendering selected values as colored tags/chips.The current data model is forward-compatible — options could later become objects with
label+color(e.g.[{"label": "Draft", "color": "blue"}, ...]) without changing the property type name or storage value type.What to consider
"blue","green","red") vs hex codes (like NocoDB)Related: #719