feat(staged): prefill the new-project repo from a single repo filter - #935
Conversation
When the New Project dialog opens without an explicit repo and the window it opens in has exactly one repo filter chip active, seed the form's repo field with that chip's repo + subpath. Zero or several active repo chips still open the dialog empty; status chips (Unread, Running) don't affect the check, so one repo chip prefills even alongside them. `repoSeedFromNewProjectEvent` falls back to the new pure `repoSeedFromRepoFilters` helper when the event carries no repo detail, which covers ⌘N and the sidebar + across all three listening views with no call-site changes; a repo card still dispatches its own repo and keeps precedence. The landing top-bar + button opens the modal directly rather than via the event, so it calls the helper itself. The filter store is module-scoped, hence per-webview, so each window prefills from its own filters. The prefill is a seed, not a lock — the field stays editable. Signed-off-by: Matt Toohey <contact@matttoohey.com>
…ared event Review 36733ca2 flagged that the landing top-bar + button was the only opener that had to remember the repo-filter seeding rule itself, calling repoSeedFromRepoFilters directly while ⌘N and the sidebar + dispatched the plain staged:new-project event and inherited the seed from the listener. Dispatch the no-detail event from the button instead, collapsing every plain trigger onto the one listener path in this component (guaranteed mounted whenever the button is clickable) and dropping the now-unused import and explanatory comment. No behavior change: the listener applies the same repoSeedFromNewProjectEvent fallback. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Matt Toohey <contact@matttoohey.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 970f596164
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| export function repoSeedFromNewProjectEvent(event: Event): RepoSelection | null { | ||
| const detail = (event as CustomEvent<NewProjectEventDetail | undefined>).detail; | ||
| if (!detail?.githubRepo) return null; | ||
| if (!detail?.githubRepo) return repoSeedFromRepoFilters(projectFiltersStore.activeRepoFilters); |
There was a problem hiding this comment.
When the last project is deleted while a repo filter remains active, the filter store deliberately retains that stale selection, but both ProjectsList.svelte and ProjectHome.svelte render SplashScreen instead of the modal. SplashScreen has no initialRepo prop and creates NewProjectForm with empty repo bindings, while NewProjectModal is gated off in this state, so the fallback computed here is discarded and Cmd-N/the top-bar button opens an unprefilled form. Thread the seed through the empty-state form as well.
Useful? React with 👍 / 👎.
1 participant
When the New Project dialog opens without an explicit repo and the window it opens in has exactly one repo filter chip active, seed the form's repo field with that chip's repo + subpath. Zero or several active repo chips still open the dialog empty; status chips (Unread, Running) don't affect the check, so one repo chip prefills even alongside them.
Changes
repoSeedFromNewProjectEventfalls back to a new purerepoSeedFromRepoFiltershelper when the event carries no repo detail. That covers ⌘N and the sidebar + across all three listening views with no call-site changes; a repo card still dispatches its own repo and keeps precedence.staged:new-projectevent instead of opening the modal directly, so every plain trigger goes through the one listener path and no opener has to remember the seeding rule itself.The filter store is module-scoped, hence per-webview, so each window prefills from its own filters. The prefill is a seed, not a lock — the field stays editable.