Iterate on version history view #3365
Conversation
…er if no versions are available
…into volume-restore
…version 0 in version view
…into refine-version-view
…add more update action descriptions
| @@ -83,28 +102,71 @@ class VersionList extends React.Component<Props, State> { | |||
| Store.dispatch(setAnnotationAllowUpdateAction(true)); | |||
| }; | |||
|
|
|||
| previewVersion = (version: number) => previewVersion({ [this.props.tracingType]: version }); | |||
There was a problem hiding this comment.
Hmm, is there a better way to name the method? Having the same names for a method and a function is a bit confusing. Maybe we don't need the method and can inline its content?
There was a problem hiding this comment.
I didn't want to inline it to avoid unnecessary re-renders and renamed it to handlePreviewVersion.
| return _.mapValues(groupedVersions, versionsOfOneDay => { | ||
| let chunkIndex = 0; | ||
| let chunkTime = 0; | ||
| return _.reduce( |
There was a problem hiding this comment.
Do you think this can be refactored into a helper function, which can be used like:
chunkIntoTimeWindows(versionsOfOneDay, batch => _.max(batch....), CHUNK_BY_X_MINUTES)
First parameter would be the data array, second parameter the function which maps an entry to a time and the third the window size? Then, we could also write a unit test for the chunking code :)
There was a problem hiding this comment.
What a marvelous idea 😀 I did both of that :)
| @@ -360,7 +360,7 @@ declare module "lodash" { | |||
| defer(func: Function, ...args?: Array<any>): number; | |||
| delay(func: Function, wait: number, ...args?: Array<any>): number; | |||
| flip(func: Function): Function; | |||
| memoize(func: Function, resolver?: Function): Function; | |||
| memoize<T>(func: T, resolver?: Function): T; | |||
This PR refines the version view as described in #3309. Versions are grouped by day and collapsed into 5-minute buckets. If a 5-min bucket would only contain a single version, it will be displayed directly.
A version 0 (
createTracing) is added to the version view, so it is possible to revert to the very first state of the tracing.This PR also minimizes (to some extent) the number of update actions that are being sent to the server. We're no longer unconditionally sending
updateTracingupdate actions, if nothing changed. Additionally, subsequent update action batches that only contain anupdateTreeupdate action for the same treeId (happens for every keystroke when editing a comment, for example) will be "compressed", so that only the lastupdateTreeupdate action is sent to the server.Open issues:
Ideally, I would like to jump to the respective volume tracing's
editPositionwhen previewing previous volume tracing versions in a hybrid tracing, so the user can see the changed buckets, but I can only think of hacky ways to do that (by default only the skeleton tracing editPosition is used, and the volume one is discarded). Maybe you have a good idea for that?When previewing volume versions (very) fast, bucket request errors are printed to the console (caused by the pending requests), however, I could not see any display artifacts. I also made sure that previewing volume versions doesn't cause a memory leak.
Screenshots:
URL of deployed dev instance (used for testing):
Steps to test:
Issues: