for any curious passerby, this made me check whether we allow duplicates in the repo UI, which we do, but we must deduplicate somewhere because we still only count results for 1 repos (https://sourcegraph.sourcegraph.com/insights/aW5zaWdodF92aWV3OiIyS1MwRHgxaFJQVVVpWlV5dlh0R2h3WERYSjAi)

@leonore prior to this PR we used deprecated repositoryScope query in each data series definition, but since all series share the same set of repositories we moved this query on the top level and there is no more need to do a uniq filtering here.

If customers somehow end up with repositories duplicates I think we should dedupe them on the backend

Is this related to CSS order in production issue?

Oh yeah (I've had this PR before we added :where to the card styles), I think we can remove it, right?

Curious, if we still need this eslint rule at this point?

I think we can drop this. will do it in a separate PR

Does that mean that the items array is updated on every render, which causes setSuggestOptions(items) inside of the MultiComboboxList, which might cause a lot of rerenders since it updates the top level object? (might not a be a problem, just double-checking)

I see what you mean here but I think this is safe because

• In this particular example there is only one moment when we don't have connection object and fallback on empty (first time list loading phase)
• Even if we call useLayout every time in the MultiCombobox implementation I used mutable ref variable as a store so no additional react call will be triggered

Is there a binding between this fragment and the query it assumes already fetched these fields? I wanted to find a query where this fragment is used to understand how it relates to the API request sent to the server.

there is no strict binding, I mean we don't use this particular fragment anywhere else but here, it does rely on the cache data, we assume that at the moment when we open this modal we already loaded information about the currently opened dashboard. I added a comment about this and linked the original query on which we rely here.

Interesting stuff! We recently discussed with @philipp-spiess how viable it would be to use usefragment_experimental to bind React components to their data needs.

Pagination hooks still look scary :)