Conversation
386b6e9 to
42f8cf7
Compare
42f8cf7 to
b48552c
Compare
| stat | ||
| ) : isError ? ( | ||
| <Fragment> | ||
| {stat} |
There was a problem hiding this comment.
Is this correct to show stat when there's an error?
There was a problem hiding this comment.
ya, it'll look like the loading state, but also have an error message beside it
static/app/components/repositories/scmIntegrationTree/useScmIntegrationTreeData.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 2 total unresolved issues (including 1 from previous review).
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| export function organizationConfigIntegrationsQueryOptions({ | ||
| organization, | ||
| providerKey, | ||
| staleTime = 60_000, |
There was a problem hiding this comment.
staleTime silently changed from 0 to 60 seconds
Low Severity
Both new query-options helpers default staleTime to 60_000, but the original inline calls in useScmIntegrationTreeData explicitly used staleTime: 0. Since the caller doesn't override, providers and integrations data that was always refetched is now cached for 60 seconds, affecting both the new overview section and the existing SCM integration tree page.


This is the 1st of three overview parts to land. The focus here is to get all the states coded up, and the buttons working.
The design will change. Specifically, the design will look different once the other sections are merged in, as they all share the same grid layout, and the content in the other sections will push content around a little bit.
This adds the first section to the top of the page

The section has a bunch of states, shown in the stories

scmOverviewSection.tsx
Three layers, innermost to outermost:
useSCMOverviewSection() — private data hook Sits between useScmIntegrationTreeData() (which fetches raw API data) and the view. Its job is to compute the display-relevant derived state: filter all SCM integrations down to only supportedScmIntegrations (those that support autofix), then cross-reference against connectedIdentifiers to produce seerRepos, connectedRepos, and unconnectedRepos. It also collects the loading/error booleans and refetchIntegrations. Not exported — it's an implementation detail of the connected component.
SCMOverviewSectionView — exported renderer A pure function of its props. Takes SCMOverviewSectionData (the hook's return shape) plus canWrite and organizationSlug. Renders the section inside SeerOverview.Section and switches between five visual states: loading, error, no integrations, integration-but-no-repos, and the normal stat+action layout. The three action subcomponents (InstallIntegrationButton, CreateReposButton, ConnectAllReposButton) are private to the file. ConnectAllReposButton takes organizationSlug as a prop rather than calling useOrganization(), keeping the entire view tree prop-driven — no context reads below SCMOverviewSectionView except the mutation hook.
SCMOverviewSection — exported connected component Five lines. Calls useOrganization() for the slug, calls useSCMOverviewSection() for the data, and spreads both into SCMOverviewSectionView. The public API for callers that don't want to manage data themselves.
scmOverviewSection.stories.tsx
Imports SCMOverviewSectionView directly (skipping the connected layer entirely). Defines a GITHUB_INTEGRATION fixture and a REPOS array of three repos at the top of the file, then a BASE_PROPS object representing the "happy path" steady state (integration present, all repos visible, none connected yet). Each story overrides only the props relevant to the state being illustrated. The outer SeerOverview grid wrapper is present in every story because SeerOverview.Section uses CSS subgrid and needs a parent grid to inherit columns from.
Notable design decision: SCMOverviewSectionData is defined as a named interface (not inlined in the props) and SCMOverviewSectionViewProps extends it. This means the hook's return type and the view's prop type are formally linked — if the hook's shape changes, TypeScript will surface it at the view's call sites automatically.