-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Fix dashboard to refresh visualizations when the refresh button is clicked #27353
Fix dashboard to refresh visualizations when the refresh button is clicked #27353
Conversation
…/kibana into lukasolson-fix/dashboard-refresh
@lukasolson - sorry I'm not sure how to do that "suggest changes on top of this PR" for your PR, but what do you think of this method? I think you were on point for doing the route of a timestamp for the last fetch time. This completely removes the need for any embeddable store. I remember now that I went through an iteration with a store of embeddables and got some great feedback for removing the need for it, but keeping all of the management local inside This also lessens the coupling to angular I think, by removing the reload provider. cc @ppisljar |
I think it'll also make it easy to do per panel reload requests, since the time stamp is stored on the redux tree, per embeddable. |
💔 Build Failed |
all tests passed except a stale dashboard jest snapshot that needs to be updated. |
@@ -231,8 +231,6 @@ app.directive('dashboardApp', function ($injector) { | |||
$scope.indexPatterns = dashboardStateManager.getPanelIndexPatterns(); | |||
}; | |||
|
|||
$scope.$watch('model.query', $scope.updateQueryAndFetch); |
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.
Removing this line does prevent the duplicate network call, but it also makes it so that if you change the query in the URL (and not in the query bar), then saved searches aren't updated.
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.
It still seems odd to me to store something in state relating to a |
Yea, I agree. I had a few thoughts/questions on this: Do we want to reload the visualizations if an absolute time is chosen? Maybe because we are expecting data to be re-indexed? Or maybe that's so rare that it's okay to expect them to do a hard refresh in that case, and otherwise, the "refresh" button is only there to update the "now" time. If the latter, then you could store a timestamp for "now" which would be useful for relative timestamps - which could be helpful anyway in seeing how stale data is on a dashboard and I think there are requests for something like that (related: #21483) But since I'm not sure of the answer to that, I think this is an okay solution. If you really want to hard refresh when that button is clicked, then I think it's okay to store this timestamp on there. I could even see it being useful in the UI (last query at timestamp x). But if anyone has other suggestions, I'm open! |
Pinging @elastic/kibana-app |
💔 Build Failed |
@@ -219,6 +220,12 @@ export class DashboardStateManager { | |||
FilterUtils.cleanFiltersForComparison(getFilters(state)) | |||
)) { | |||
store.dispatch(updateFilters(dashboardFilters)); | |||
} else { | |||
// If the user clickes "refresh" query, it'll get here but without any changes, we still |
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.
What if you added a separate method to DashboardStateManager
to request reload? Then we can call that directly inside updateQueryAndFetch
.
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 you help me see why you prefer that way? I tried to take as much code out of the dashboard_app
file because it is coupled to angular, so any logic that didn't require scope, I would put into dashboard_state_manager
. Way back dashboard_app
was a monolithic file with all logic and everything tightly coupled to angular. Plus, if we pull out into dashboard_app
, then to eliminate the double reload, we would have to duplicate the logic for determining if the filters changed and already caused an update in here. Just don't really see it as an improvement. Thoughts?
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 understand your point of view, I agree that it'd be nice to remove as much as we can that relies on $scope
and Angular. My argument is that in my brain "reloading" is meant to be an intentional action you take. In the current implementation it's a side effect that happens any time applyFilters
is called, but the filters and query haven't changed. While that may currently only happen when the refresh button is clicked, couldn't there be other situations where applyFilters
is called, and nothing changed, and we don't actually want to reload all of the embeddables?
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.
Thanks for the explanation. I don't feel that strongly about this way, and I see your point, I can make the change. Stay tuned!
Yeah, I think that's probably not actually all that rare, I think the way you've done it is good for now. |
💚 Build Succeeded |
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.
Looks good aside from the already mentioned comments.
💚 Build Succeeded |
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.
LGTM!
💚 Build Succeeded |
…icked (elastic#27353) * Fix dashboard to refresh visualizations when the refresh button is clicked * Suggestions * Fix tests * Catch bug with a new test to ensure saved searches update when query in url is modified * Add a test that would have caught the initial problem * Final fixes that should get ci passing and the bug fixed * Move requestReload out of _pushFiltersToState * Fix comparison
…icked (#27353) (#27458) * Fix dashboard to refresh visualizations when the refresh button is clicked * Suggestions * Fix tests * Catch bug with a new test to ensure saved searches update when query in url is modified * Add a test that would have caught the initial problem * Final fixes that should get ci passing and the bug fixed * Move requestReload out of _pushFiltersToState * Fix comparison
suggestions to put on top of #27260
Summary
Fixes #23329.
This PR updates dashboard so that clicking on the refresh button actually refreshes visualizations.
As of #19172, visualizations don't inherit from the dashboard's search source. As a result, when the search source is updated (even when clicking on the "refresh" button), they don't automatically get the new data that's fetched.
Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.This was checked for cross-browser compatibility, including a check against IE11Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n supportDocumentation was added for features that require explanation or tutorialsThis was checked for keyboard-only and screenreader accessibilityFor maintainers
This was checked for breaking API changes and was labeled appropriately