Naming conventions for slots once you pass 20 of them?
Our workspace grew organically over a year and the slot list now reads like a horror story: hero2, test-banner, final-final-cta, and my personal favorite, new-new-promo. Nobody remembers what half of them do, and the names are already leaking into the codebase.
Before this mess spreads any further, how do teams with 20+ slots actually name and organize them? Is there a convention that holds up over time, and is there any sane way to clean up the existing graveyard without breaking things
2 answers
The mental shift that fixed this for us: slot IDs are API contracts, not labels. They are referenced directly from code, fetchContent('home-hero'), SlotContent<'home-hero@1'>, so renaming one later means touching the codebase. Treat naming with the same care as an endpoint path.
The convention that has held up for us across ~35 slots is page-context plus role: home-hero, pricing-faq-list, checkout-trust-banner. It answers "where is this and what does it do" without opening anything. What does NOT hold up is naming by content or by campaign (summer-sale-banner, new-promo), because the content rots while the placement stays, and you end up with final-final-cta.
Two more rules we enforce in review:
- Pin the version in the ID: home-hero@2. Unpinned means @latest, and a schema publish can silently break the app. The pin also documents which schema the code expects.
- No abbreviations that need tribal knowledge. pdp-cross-sell is fine if everyone says PDP; hm-hr-2 is not.
For the graveyard: since IDs live in code, migrate placement by placement. Create the well-named slot, switch the code reference, then retire the old one.
Page-context plus role is exactly the kind of rule I can put in a lint doc. The endpoint-path analogy will land well with the team, thanks.
For the cleanup half of your question: the status dots in the dashboard do most of the triage for you. Red means the slot has received no requests for 7+ days, and in a workspace like the one you describe, the red ones are almost always dead code paths or abandoned tests. Grey means it never received traffic at all, which usually means someone created it and never integrated it.
We did this exact exercise last quarter: sorted by status, confirmed the red and grey ones against the codebase, and archived them. Bonus: that freed a chunk of our slot quota, so the cleanup paid for itself before we even got to renaming anything.