-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
timeseries: preserve select all on page when new runs arrive #4888
Conversation
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.
Overall approach SGTM. Thanks for addressing this!
tensorboard/webapp/runs/views/runs_selector/runs_selector_test.ts
Outdated
Show resolved
Hide resolved
this.snackBar.open(text, 'DISMISS', { | ||
duration: 5000, | ||
horizontalPosition: 'start', | ||
verticalPosition: 'bottom', | ||
}); |
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.
Can we undo this and use the alerts module? This is taking the imperative approach of a view instead of more declarative version: e.g., you are using business logic to determine whether to show a snackbar or not then are making an imperative API call to the snackbar. Instead, the view should react to the data change which we already have in the alerts component. Just add an alert in this case?
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.
Done.
runsExceedsLimitForRoute$.subscribe(() => { | ||
const text = | ||
`The number of runs exceeds ` + | ||
`${MAX_NUM_RUNS_TO_ENABLE_BY_DEFAULT}. New runs are unselected ` + | ||
`for performance reasons.`; | ||
this.store.dispatch(alertReported({localizedMessage: text})); | ||
}); |
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 is effectively creating a composite action; please do this in the alerts feature.
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 per offline discussion, moved the composite action to RunsTable, and added a comment to indicate that this should be considered an exception, which goes against recommended patterns.
this.store.dispatch( | ||
alertActions.alertReported({localizedMessage: text}) | ||
); |
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.
Just wondering, does any asynchronusity disrupt the UX? Adding what is effectively setTimeout(0)
would make me feel tiny bit better about the synchronous composite action.
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 manually added it to try it out, and the UX seems fine, e.g. Alert still appears and the rest of the UI is functional. Not sure how valuable it is to go add setTimeouts to all cases like these, but perhaps worth considering in a separate PR.
* `alertFromAction`. Unfortunately, those currently have no way of knowing | ||
* whether a run table is actually shown (with checkboxes), so we make a |
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.
Just so we are 100% aligned; since the view is a representation of the state in the store, you can reason with the state in the store to know. However, it is quite cumbersome and, now, you have to ingrain presentation logic into the store which is very unpleasant.
); | ||
}); | ||
} | ||
|
||
this.store.dispatch(runTableShown({experimentIds: this.experimentIds})); |
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.
Wow, when did we do this :(
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.
Googlers, see original cl/330969935. Back then, it was also noted that this is kind of an anti-pattern, but a tradeoff was made for convenience. For the same reason as you mentioned, ingraining presentation logic into the store would be unpleasant, so this tradeoff still probably makes sense.
Before, the auto-selection logic was:
For users who frequently want new runs to be automatically
selected, we
that new runs might not be selected.
Manually tested by running a script, pressing the in-app reload.
Googlers, see b/184284696.