Code insights: Add new repositories UI field #45687
Conversation
Bundle size report 📦
Look at the Statoscope report for a full comparison between the commits 3437b94 and 936ad3e or learn more. Open explanation
|
764d7e0 to
5297863
Compare
9a3a303 to
aea9f6c
Compare
|
@vovakulikov I didn't make it all the way though this but did see a small issue in the create. If you have data in both a repo search and a list of repos it sends both to the mutation. The mutation rejects it because it's not sure which one is correct. |
|
Another thing I noticed is that entering |
ab927a0 to
52ecbe4
Compare
AlicjaSuska
left a comment
There was a problem hiding this comment.
Thank you for making those changes @vovakulikov (I love that the repo count works! It's awesome). Here is the design QA page with all the design details I've spotted.
30d9a02 to
c9d6caa
Compare
a17bdfa to
4520fac
Compare
valerybugakov
left a comment
There was a problem hiding this comment.
Tested the feature locally and left a couple of optional comments!
| // required | ||
| const isRepoURLsListRequired = isSearchQueryORUrlsList && isURLsListMode | ||
|
|
||
| const validateRepoQuerySyntax = useMemo(() => createValidateRepoQuerySyntax(apolloClient), [apolloClient]) |
There was a problem hiding this comment.
Would useLazyQuery work here instead of useApolloClient?
There was a problem hiding this comment.
Yeah I think it would work, but I still would have needed wrap it with useMemo because field validator API expects to have boolean from validation function and validators always should be not re-rendered on each render call otherwise it all will fail with recursive error.
| InputDescription, | ||
| InputErrorMessage, | ||
| InputElement, |
There was a problem hiding this comment.
What are the reasons for exposing these components? Would it be possible to implement the same functionality relying only on the Input component?
Context: we discussed exposing these earlier while we worked on the Wildcard v2 and decided to export only the higher level Input component to keep things consistent in the UI because it would limit the number of combinations that consumers can create (e.g., label + input + error + description). Understanding the motivation behind lowering the abstraction level here would be great.
There was a problem hiding this comment.
Yeah, basically I had to have this element, because Input component for example always returns wrapped with LoadingInput component layout. Sometimes it returns wrapped with Label layout. I see that consistency here is already broken. You have to care about different input layout combination every time you use Input element.
For my particular case I use Searchbox Input with standard Input layout (error message, label, etc) The search box itself provides loading state, in order to decouple loading from Input component I extracted Input Element.
Also in my case I need to put preview button in one line with input and that error or description message were below this line with input and preview button, with current Input API this ins't possible, I could extend it but I would have became even more complicated rather than now. So I decide that low-level abstractions here are necessary.
f9b5943 to
824b7c3
Compare
|
Codenotify: Notifying subscribers in CODENOTIFY files for diff c8f520b...3437b94.
|
|
Codenotify: Notifying subscribers in OWNERS files for diff c8f520b...3437b94.
|
|
❌ Problem: the label |
9302c29 to
b2fcfb0
Compare
…ght-repo-section/InsightRepoSection.tsx Co-authored-by: chwarwick <christopher.warwick@sourcegraph.com>
b2fcfb0 to
52e5333
Compare
Closes https://github.com/sourcegraph/sourcegraph/issues/45427
Useful links
How to test
Locally
sg start web-standaloneor any other command that runs FE locallycodeInsightsRepoUIexperimental feature flag in the setting (possible values"single-search-query", "search-query-or-strict-list")Remote
Backround
This PR changes the repositories UI field for the insight creation UI (search-based and capture group insight creation forms). It adds a new field UI that can be run in two different modes.
codeInsightsRepoUI: 'single-search-query'inexperimentalFeaturessetting cascade section)codeInsightsRepoUI: 'search-query-or-strict-list',inexperimentalFeaturessetting cascade section)Todo list
repo:.*to the search repositories query field which should be fully equivalent to the all repos mode that we had before)Test plan
repo:.*value in the search repo fieldApp preview:
Check out the client app preview documentation to learn more.