Favorites, recents, and trending

You'll touch the same forty or fifty ACI classes over and over. Relearning their names every time is a waste. Favorites, notes, backend-synced recents, the org-wide trending list, and detail-panel preferences turn the Class Browser from a raw MIM viewer into a personal and team-aware working set.

Starring a class

Every row in the list has a star icon. Click it once and the class becomes a pending favorite — a small input appears (under the search bar in the dialog, inline in the selector) where you can type an optional note.

• Press Enter to save the favorite with the note.
• Press Esc to cancel; no favorite is created.
• Leave the input empty and press Enter to save without a note.

Once saved, the star turns solid. The class now appears in the Favorites section at the top of the left panel on every future open, and is matched first in search results.

Favorites are backend-stored, per-user. Signing in on another machine gives you the same starred set. There's no localStorage fallback for favorites — if the backend is unreachable, the star button won't persist.

Why notes matter

The note is the whole point. ACI class names (eqptIngrBytes5min, fvRsPathAtt, compHv) are often opaque; a note like "per-port ingress bytes, 5-min rollup" or "binding between EPG and static path" makes the class findable by what it does, not what Cisco named it.

Three payoffs:

• Notes are searchable. Typing in the search box matches against both class names and favorite notes. "ingress bytes" finds eqptIngrBytes5min because the note contains that phrase. The matching favorite shows up first in results with a note chip.
• Notes are personal vocabulary. Two teammates can star the same class with different notes for their own mental model. Favorites are not shared.
• Notes are previewed. Inside the list row, the note shows as italic text under the label, so you don't have to remember what you wrote.

Editing a note

Hover a starred favorite in the list. The pencil icon (📝) opens an inline editor; type the new note, press Enter to save, Esc to cancel. Removing the text entirely keeps the favorite but clears the note.

Unstarring

Click the solid star to remove the favorite entirely — the note goes with it. There's no confirmation prompt; re-star to get the favorite back, but the previous note is not restored.

Favorites-only mode

The Favs button in the search bar flips the left panel into favorites-only mode. No search, no recents — just your starred classes. Useful when you know the class is in your favorites but you don't remember its name.

In child mode, favorites-only is filtered to valid children of the current parent — starred classes that can't legally live under the current parent are hidden automatically. No risk of picking a stale favorite.

Recents (backend-synced)

Below Favorites, the Recent section lists the last 10 classes you added to a query from this dialog or selector. It populates automatically — no toggle, no opt-in.

How it works

• Backend-stored. Every class you add via Confirm / double-click / Enter increments a RecentClass row in PostgreSQL (use_count, last_used_at).
• Cross-device. Open a query on your laptop, drop a class, open the same browser on another machine — the recent shows up there too. Same user account = same recent list.
• Sorted by use_count, then recency. The class you reached for ten times last week beats the one you used once this morning, but ties are broken by recency. This is intentional: power users converge on a working set, and the recent list should surface that set even after a weekend.
• localStorage fallback. If the backend is unreachable when the dialog opens, the panel falls back to localStorage so you still see the most recent additions from this browser. When the backend comes back, the next confirmation re-syncs.
• One-time migration. The first time you open the dialog on a session that has localStorage history but no backend rows, those entries are pushed to the backend (idempotent — update_or_create). After migration, the backend is the source of truth.

Recent vs Favorites

Recents and favorites can overlap; the two sections don't deduplicate. A class you've used five times today might be both a favorite and a recent — that's fine, it's surfaced in both sections so you find it whichever way you scan.

Recents are especially useful during an exploration session when you're pulling related classes onto the canvas — the thing you added ninety seconds ago is always right there, no search needed.

Trending in your org

In root mode (no parent — the dialog opened from a top-level Class Query), the empty-state landing shows a Trending in your org section above Favorites and Recent. It's the top 10 classes other Fabrik users have added in the last 30 days.

How it works

• The endpoint (/api/mim/classes/trending/) aggregates RecentClass.use_count across all users who haven't opted out of telemetry.
• No per-user breakdown is exposed — only the aggregate class names and total counts.
• The list refreshes once an hour client-side (1-hour staleTime).
• Default window is 30 days; the endpoint accepts a days parameter (1–365) for tuning.

Why it matters

For new team members, Trending answers "what does the rest of the team actually use?" in a way that no static documentation can — the list reflects this week's reality. For senior users, it's a quick check on whether a new use case is gaining traction ("three people queried bgpPeer this week — there's a trend").

Privacy and the opt-out

Telemetry is opt-out, default ON. The toggle lives in Settings → Privacy under Share class usage with org-wide trending. When you turn it off:

• Your RecentClass rows still exist (you still get your personal recent list).
• They're excluded from the trending aggregation. The query filters by user__profile__share_class_telemetry=True.
• The change is immediate — the next trending fetch (within an hour) reflects it.

The data shared is only class names and use counts; no query content, no node configurations, no DN values. If your environment forbids any usage telemetry, set the default to OFF in deployment configuration before rolling out.

Suggested children (parent mode)

In child mode (the dialog opened to pick a child class), the empty-state landing shows a Suggested section. It's the top 25 useful children of the parent, drawn from getClassInsights().smartChildren.common — the same list the Class Detail Panel's Overview tab uses for "structural children."

The suggestion list is stats-filtered: monitoring/health/fault/trend classes are excluded automatically, even though they're real CONTAINS-children. The premise is that 95% of the time you want structural children (EPGs under a tenant, subnets under a BD), not stats children.

If you specifically need a stats child, type the search box to bypass the suggestion list and get the full filtered result, then toggle monitoring/stats off if needed.

Common roots (root mode fallback)

When you open the dialog in root mode for the first time and have no favorites, no recents, and no trending data yet, the landing shows Common roots instead of an empty panel:

• fvTenant — the most common starting point
• polUni — policy universe root
• fabricInst — fabric instance root
• and other classes flagged isContextRoot=true

This is purely a discovery aid for novices — once you have any usage history, Trending and Recent take over.

The detail panel preferences

The right panel shows details for whichever class is focused in the list. The five tabs (Overview, Properties, Relationships, DN & REST, Faults) are all visible by default; the persistence is which tab was open last.

• Tab choice persists. Per browser, in localStorage under fabrik-class-browser. The next dialog open shows the same tab as the last close.
• Tab order is fixed. No reordering — Overview is always first, Faults always last. The order matches the workflow: glance → drill → relate → REST → operate.
• No section-level visibility toggles in the new design. Earlier versions let you collapse Description, DN reference, etc. The new tabbed layout already separates concerns; collapsing within a tab isn't needed.

Why you'd care which tab

• Designers spend most time on Properties — keep that tab open by default.
• Operators correlating with APIC alerts spend most time on Faults.
• Integrators hitting REST endpoints live on DN & REST.
• Architects mapping the MIM use Relationships heavily.

The persisted tab means "your" view is what shows up.

Putting it together

A realistic personal setup after a week of use:

• 30–60 favorites — your working classes, each with a one-line note.
• Properties tab persisted as the default open tab — you're past needing MIM prose.
• Filter chips all on: monitoring/deprecated/abstract/hidden hidden by default.
• Recents — backend-synced, follows you to any device.
• Trending in your org — checked once a week to spot what teammates are exploring.

Once that's in place, opening the Class Browser is instant: start typing, pick from favorites, or glance at recent/trending. You're rarely more than two keystrokes from the class you want.

Troubleshooting

---

That's the Class Browser end-to-end. The next section — AWX Automation — is a different world: instead of reading from APIC, you're driving Ansible playbooks to push configuration back out.