Svelte: implement new reference panel against new Usages API#63724
Conversation
c5c3f13 to
140667a
Compare
bf17cfd to
b0cb9c4
Compare
| box-shadow: var(--focus-box-shadow); | ||
| box-shadow: var(--focus-shadow-inner); |
There was a problem hiding this comment.
Unrelated: use an inner box shadow so that stack order of siblings doesn't interfere and so we show it on all four sides (the left and right get cut off)
| // Wait until DOM was updated to possibly show the history panel | ||
| await tick() |
There was a problem hiding this comment.
@fkling do you have more context on this? It seemed to be causing some very weird bugs when I tried to add explore panel stuff to the snapshot.
There was a problem hiding this comment.
The historyPanel component is only rendered when it's selected. When we restore selectedTab we have to wait for the DOM to update before historyPanel is available and before we can restore its data.
Which problems did you encounter?
c65e8b2 to
5ac65b3
Compare
8498092 to
d3b11fc
Compare
23d02d4 to
64de261
Compare
69afe5c to
5908096
Compare
|
Did try this locally, works cool, found a few small layout problems (mostly about content overflow, nothing that big)
cc @camdencheek |
|
Thanks @vovakulikov! Made long paths wrap rather than creating a scroll container: Added |
fkling
left a comment
There was a problem hiding this comment.
I feel like we should still update the URL to include a reference to the line/range of the symbol you just clicked. That will also highlight that line in the blob view.
After clicking 'find references', or rather after navigating back to a page with the reference panel open, it's not obvious where I opened the reference panel from (if that makes sense).
Compare that with the current reference panel implementation:
That aside, I love that we got rid of the preview 😃
| export let repo: string | ||
| export let path: string | ||
| export let usages: ExplorePanel_Usage[] | ||
| export let scrollContainer: HTMLElement | undefined |
There was a problem hiding this comment.
Makes me wonder whether we should pass the scrollContainer as context. Then we wouldn't have to pass props around. Not sure if it's possible to have optional contexts though.
But in general I find the idea reasonable: We have one "Scroller" component that's supposed to be used whenever you want to react to visibility or scroll events and that component provides the context for other components.
There was a problem hiding this comment.
Oh, I like the idea of tying this in to context with a Scroller. Will save that for a followup though.
| // Wait until DOM was updated to possibly show the history panel | ||
| await tick() |
There was a problem hiding this comment.
The historyPanel component is only rendered when it's selected. When we restore selectedTab we have to wait for the DOM to update before historyPanel is available and before we can restore its data.
Which problems did you encounter?
Yep, that makes perfect sense, and if I'm understanding you right, that's exactly what this issue is all about. |








This implements a first pass at the new references panel built against the new usages API.
Stacked on https://github.com/sourcegraph/sourcegraph/pull/63816
Notable omissions:
infinityQuery), but the backend just returns everything, so we just render a massive list.pushStateandSnapshotwork together nicely, but would love to pair on this.Notable decisions:
Test plan