Skip to content
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

Merged
merged 2 commits into from
Nov 21, 2024
Merged

Conversation

jamie-rasmussen
Copy link
Collaborator

Description

Adds initial implementation of object/call comparison view.

Testing

How was this PR tested?

@circle-job-mirror
Copy link

circle-job-mirror bot commented Nov 8, 2024

@jamie-rasmussen jamie-rasmussen force-pushed the jamie/compare-everything branch 2 times, most recently from 156634a to 108cbba Compare November 15, 2024 16:12
@jamie-rasmussen jamie-rasmussen marked this pull request as ready for review November 15, 2024 16:38
@jamie-rasmussen jamie-rasmussen requested review from a team as code owners November 15, 2024 16:38
@jamie-rasmussen jamie-rasmussen force-pushed the jamie/compare-everything branch from 108cbba to e83b577 Compare November 18, 2024 18:46
.join('&');
return `${projectRoot(entityName, projectName)}/compare?${params}`;
},
compareObjectsUri: (
Copy link
Collaborator

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?

Copy link
Collaborator

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

Copy link
Collaborator Author

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))
Copy link
Collaborator

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?

Copy link
Collaborator

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

Copy link
Collaborator Author

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';
Copy link
Collaborator

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.

Copy link
Collaborator Author

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 @@
/**
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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
Copy link
Collaborator

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!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (oldIndex === newIndex) {
return;
}
const {search} = history.location;
Copy link
Collaborator

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.

Copy link
Collaborator Author

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
Copy link
Collaborator

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

Copy link
Collaborator Author

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}
Copy link
Collaborator

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)

Copy link
Collaborator Author

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) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we might want to limit the number to a reasonable set:
Screenshot 2024-11-19 at 15 23 18

Copy link
Collaborator

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

Copy link
Collaborator Author

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.

@jamie-rasmussen jamie-rasmussen force-pushed the jamie/compare-everything branch from 7a249f3 to 33c27a2 Compare November 21, 2024 16:08
@jamie-rasmussen jamie-rasmussen merged commit 370c6ec into master Nov 21, 2024
115 checks passed
@jamie-rasmussen jamie-rasmussen deleted the jamie/compare-everything branch November 21, 2024 16:33
@github-actions github-actions bot locked and limited conversation to collaborators Nov 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants