-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(ui): object comparison #2942
Conversation
Preview this PR with FeatureBee: https://beta.wandb.ai/?betaVersion=9eac986c93204d148e8c78e46290a93ffdb89f89 |
156634a
to
108cbba
Compare
108cbba
to
e83b577
Compare
.join('&'); | ||
return `${projectRoot(entityName, projectName)}/compare?${params}`; | ||
}, | ||
compareObjectsUri: ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are Ops supported as objects?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see by playing with it that they are not - seem like we could support that in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that would be a good future enhancement to make things more consistent. Comparing calls was already scope creep I couldn't resist. :-)
callIds: string[] | ||
) => { | ||
const params = callIds | ||
.map(id => 'call=' + encodeURIComponent(id)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious why you went with IDs over refs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like you could do ref=...
and the ref itself encodes that it is an object or a call. which would unify the model a bit.
It seems a little odd to me that the search params are mutually exclusive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using refs would make the URLs substantially longer and uglier
e.g. comparing three calls here:
http://localhost:9000/wandb-designers/signal-maven/weave/compare?call=491f11f4-cccf-4f0b-b447-897254fa1534&call=d1e494c4-737f-49a8-be89-7703fec23b7b&call=2b58c817-607b-48ed-b4ce-4ec4fb816e95
v.s. with refs it would be:
http://localhost:9000/wandb-designers/signal-maven/weave/compare?ref=weave%3A%2F%2F%2Fwandb-designers%2Fsignal-maven%2Fcall%2F491f11f4-cccf-4f0b-b447-897254fa1534&ref=weave%3A%2F%2F%2Fwandb-designers%2Fsignal-maven%2Fcall%2Fd1e494c4-737f-49a8-be89-7703fec23b7b&ref=weave%3A%2F%2F%2Fwandb-designers%2Fsignal-maven%2Fcall%2F2b58c817-607b-48ed-b4ce-4ec4fb816e95
|
||
// When we replace a ref with its resolved data we insert this key | ||
// with the ref URI to keep track of the original value. | ||
export const RESOLVED_REF_KEY = '_ref'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we do something similar for call expansion - maybe an opportunity for some merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think there's a lot of opportunity for merging functionality, though with all of the problems we have with things like import cycle I'm a little wary of introducing dependencies across different parts of the code and willing to live with more duplication than I'd prefer.
@@ -0,0 +1,70 @@ | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any reason you put this (i suppose the entire compare dir) outside of the pages dir?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At some point I'd like to do a more major reorganization of our UI directory structure. E.g. PagePanelComponents
seems unnecessarily long when everything is already under components
, it seems weird to have Home
in the path to these, "Browse3" isn't a good name, etc.
"pages" seems redundant to me given all of this is under "PagePanelComponents" and I generally would rather have things organized/named by feature. But I can move it if you have a strong preference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the need to refactor. In my mind weave-js/src/components/PagePanelComponents/Home/Browse3
is the root of our weave application and the initial refactor should be to just hoist that to a top level dir. Everything outside of that Browse3
that is not common W&B should be either removed or extracted. Given that framing, the pages
dir serves as the "topmost" dir for our pages.
project: string, | ||
objectVersionSpecifiers: string[] | ||
): ObjectVersionsResult => { | ||
// TODO: Need to introduce a backend query (/objs/read?) to bulk get specific versions of objects |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UGGG lets add that! You are completely right!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filing at https://wandb.atlassian.net/browse/WB-21999 for follow up.
if (oldIndex === newIndex) { | ||
return; | ||
} | ||
const {search} = history.location; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed this elsewhere, but figured I would add one comment: I generally stay way from embedding URL management deep in components like this. Ideally the URL management would happen in a very high level top component (Browse3) and everything below is driven by params and callbacks. The reason for this is that if we ever want to export to reports or embed in other contexts where the state is no longer URL managed, then we incur a pretty hefty refactor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fair. But in the interest of getting this feature out I'm going to propose we do that pretty hefty refactor when the need arises rather than now, and I'll try to keep that in mind for the next feature.
<DropdownMenu.Trigger> | ||
<div className="cursor-pointer"> | ||
<div className="flex items-center gap-10"> | ||
{baselineEnabled |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This toggle does not seem to do anything when there are only 2 things to compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will hide it when there are only two things.
disabled={first.version === 0} | ||
icon="back" | ||
variant="ghost" | ||
onClick={onPrev} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as a user, I am not sure what this does (especially when there are only 2 items?) unclear why these arrows are here, but not in the calls one (without reading the code)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you have selected a sequential set of versions of the same object you can click these arrows to "move the sliding window" on the viewed versions. It's perhaps most intuitive and useful with only 2 items, e.g. you go from diffing v0 and v1, to v1 and v2, to v2 and v3, or vice-versa.
You could possibly come up with a similar concept for calls of the same op and previous/next execution by time, but I don't think there's a lot of value for the amount of effort that would take.
I will try updating the tooltip text to explain the buttons better.
const onlyChanged = queryGetBoolean(history, 'changed', false); | ||
const callIds = getParamArray(d, 'call'); | ||
|
||
if (callIds.length) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this pretty much halts to page
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to limit it to 6 object columns in the grid and show a message. I think that will work for most cases while keeping the entire set in the shopping cart so you can select the items for a pairwise comparison.
e83b577
to
7a249f3
Compare
7a249f3
to
33c27a2
Compare
Description
Adds initial implementation of object/call comparison view.
Testing
How was this PR tested?