feat(replay): unify add-to-collection menu into searchable modal#60099
Merged
pauldambra merged 4 commits intoMay 26, 2026
Conversation
Replaces the bulk multi-select "Add to new collection" and "Add to collection" submenu with a single "Add to collection" action that opens a modal. The modal searches existing collections (server-side, ordered by most recently modified) and includes a "New collection" affordance that swaps to the create-collection form. Existing collection picks outnumber new-collection creations roughly 3:1 on clicks and 1.6:1 on unique users over 90 days, so the modal keeps both flows but surfaces the dominant one first with search and last-modified hints — addressing user feedback that the prior submenu had no ordering signal or search. Generated-By: PostHog Code Task-Id: 281c899f-ccc5-4a00-afe4-e36e6f6bbe10
Contributor
|
🎭 Playwright didn't run on this PR — your changes touch code that could affect E2E behavior, but Playwright is opt-in via label now to keep CI cost down. Add the Most PRs don't need this. Real regressions still get caught on master and fix-forward. |
Contributor
|
Size Change: +1.38 kB (0%) Total Size: 80.1 MB 📦 View Changed
ℹ️ View Unchanged
|
Covers the four interesting states of the new modal: no search entered (default list), search with results, search with no results, and the empty "no collections yet" state. Exports AddToCollectionModal so the story can mount it directly under a BindLogic + MSW decorator. Generated-By: PostHog Code Task-Id: 281c899f-ccc5-4a00-afe4-e36e6f6bbe10
Contributor
|
Reviews (1): Last reviewed commit: "chore(replay): add storybook stories for..." | Re-trigger Greptile |
Contributor
|
✅ Visual changes approved by @pauldambra — baseline updated in 2 changed, 8 new. |
… the loader Moves the debounce off the loader (was 300ms before the API call) and onto the setAddToCollectionSearch listener (200ms). The loader now fires the API call immediately; the post-API breakpoint() still discards out-of-order responses when a newer load supersedes a slow one. Opening the modal no longer waits 300ms before the first fetch. Generated-By: PostHog Code Task-Id: 281c899f-ccc5-4a00-afe4-e36e6f6bbe10
10 updated Run: 4deed78f-4649-4b81-a708-214b4eb9c1a8 Co-authored-by: pauldambra <984817+pauldambra@users.noreply.github.com>
![stamphog[bot]](https://avatars.githubusercontent.com/in/3000332?s=60&v=4){kind=small}
There was a problem hiding this comment.
The code is technically clean and follows established kea patterns, but this is a T1d-complex behavioral UX change with zero reviews — the guidelines require escalation here. Request a review from a teammate on the replay/session-recordings team before re-requesting auto-approval.
pauldambra
requested review from
a team,
TueHaulund,
arnohillen,
fasyy612,
ksvat and
nicowaltz
and removed request for
a team
arnohillen
approved these changes
May 26, 2026
Member
Author
Merge activity
|
pauldambra
deleted the
posthog-code/replay-unified-add-to-collection-modal
branch
pauldambra
added a commit
that referenced
this pull request
May 26, 2026
Follow-up to #60099. - Pause any mounted session recording player when the Add to collection modal is opened, so playback doesn't keep running while the user picks a destination. - Fire `loadCollectionsForBulkAdd()` in the same handler that opens the modal so the loading state is already in flight by the time the modal renders. The previous setup relied on a kea listener triggered by the reducer update, which left a brief "No collections yet" flash on first open before a search was typed. The storybook is updated to drive the same explicit load. Generated-By: PostHog Code Task-Id: 281c899f-ccc5-4a00-afe4-e36e6f6bbe10
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
see papercuts https://posthog.slack.com/archives/C0ACRAMJUAG/p1779804160629989
Problem
When users multi-select session recordings, the bulk action menu offers two related items: "Add to new collection..." (opens a modal) and "Add to collection" (a submenu listing every collection by name). The submenu has no search, no ordering hint, and renders only the first 30 results — users with many collections cannot find what they want, and the split between "new" and "existing" forces a decision before they know what's already there.
Changes
Replaced both menu items with a single "Add to collection..." action that opens one modal:
90-day autocapture for the bulk menu (filtered by
data-attrto exclude the unrelated single-recording pin button) shows the existing-collection submenu trigger gets ~3× the clicks of the new-collection item (2,012 vs 695 clicks; 838 vs 534 unique users), so the modal keeps both flows but defaults to the dominant one and adds the search/ordering signals users were asking for.The modal's "New collection" button retains the
add-to-new-collectiondata-attr so the prior click signal stays comparable; the menu entry that opens the modal carriesadd-to-collection.How did you test this code?
I'm a Claude Code agent — no manual UI testing.
Automated checks I actually ran:
pnpm --filter=@posthog/frontend run typegen:write— kea types regenerate cleanly with the new actions/reducers/loadertsc --noEmit— no new TypeScript errors in either touched file (pre-existing@posthog/quillerrors are unrelated)oxlint— clean on both filesoxfmt— applied to both filesJest could not run in this environment due to the same pre-existing missing
@posthog/quillmodule, so the playlist logic test file wasn't exercised here.Publish to changelog?
no
Docs update
n/a — internal UX change with no docs surface.
🤖 Agent context
Tools used: Claude Code with PostHog MCP (
execute-sqlagainsteventsfor the autocapture frequency check) and the signed-commit tool.Key decisions:
\$autocaptureby the precisedata-attrstrings inelements_chain(rather than\$el_text, which collides with the single-recording pin button) isolated bulk-menu clicks to the SettingsMenu portal. Existing-collection submenu opens beat new-collection clicks ~3:1, so collapsing the two into one search-first modal preserves both flows without removing functionality.sessionRecordingCollectionsLogic.setSavedPlaylistsFilters({ search })— rejected because that mutates the Playlists tab's filters and URL. Added a dedicated loader (collectionsForBulkAdd) onsessionRecordingsPlaylistLogicwith its own debounced search so the modal doesn't bleed into other scenes.isNewCollectionDialogOpen→isAddToCollectionModalOpen, keptnewCollectionName/handleCreateNewCollectionBulkAdd) so the create-collection path stays untouched at the API/listener level. NewisCreatingNewCollectionInModalreducer toggles between the two views inside the modal, and all related state resets whenever the modal closes.PlayerMetaLinks"Add to collection" button — out of scope; the data showed the multi-select menu was the friction point.Created with PostHog Code