-
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
Prevent flicker on Getting Started page #11826
Prevent flicker on Getting Started page #11826
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.
Can you please add some tests for gettingStartedGateCheck()
? Happy to help bootstrap them if you're not sure where to start.
We really should write more unit tests for this stuff rather than jumping directly to functional tests. Sometimes that's not really doable with the legacy code though. |
@@ -11,6 +11,67 @@ import { | |||
CREATE_INDEX_PATTERN_ROUTE | |||
} from './constants'; | |||
|
|||
function handleExistingIndexPatternsScenario(indexPatterns, currentRoute, config) { | |||
// If index patterns exist, we're not going to show the user the Getting Starte 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.
Starte
should be Started
} | ||
|
||
// Otherwise, check if we have a default index pattern | ||
let defaultIndexPattern = config.get('defaultIndex'); |
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 defaultIndex logic doesn't seem appropriate in the getting started guide, as it doesn't seem to be related at all. If someone were to disable the getting_started plugin entirely, it would break the default index behavior.
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 now that this already existed in the getting started guide from the previous PR. Where was it moved from? Can it be moved back?
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.
The same sentiment applies further down in this file with the "please create a new index pattern" logic.
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 doesn't need to be dealt with in this PR since you're fixing a bug here and just moving stuff around, but we really should sort it out in a follow up.
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.
So the reason the two pieces of logic (getting started and default index patterns) have been combined is that both use RouteSetupManager.addSetupWork(fn)
to do their job.
In an early implementation I had the two independent of each other but I would see the "No default index pattern" notifier on the Getting Started page. This was happening because, AFAICT, there's no way of specifying the order of execution of the two fn
s registered with RouteSetupManager.addSetupWork(fn)
. So my solution to control the order was to combine the two pieces of logic into one fn
.
* gettingStartedGateCheck, which does the actual work. | ||
*/ | ||
function _gettingStartedGateCheck(Private, $injector) { |
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.
How about gettingStartedGateCheckProvider
? Or just putting this inline with uiRoutes.addSetupWork()
?
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'll take the latter option. Gracias.
src/ui/public/notify/notifier.js
Outdated
@@ -230,7 +230,7 @@ Notifier.config = { | |||
errorLifetime: 300000, | |||
warningLifetime: 10000, | |||
infoLifetime: 5000, | |||
setInterval: window.setInterval, | |||
setInterval: window.setInterval.bind(window), |
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.
Why does setInterval
need to be bound to window but clearInterval
doesn't?
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.
clearInterval
probably does too. The code path I was testing with the Getting Started page ended up exercising setInterval
, so I fixed that one. I will fix clearInterval
as well. Thanks for pointing it out.
3f61821
to
f39599d
Compare
LGTM |
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
* Consolide chrome visibility toggle code into single module * Extracting code into helper functions for better readability * Removing redundant setting * Extracting functions to higher level in scope so they are not defined multiple times * Fixing typo in comment * Starting to add unit tests * Actually adding the tests this time * Adding unit tests for handleGettingStartedOptedOutScenario function * Binding this to window to prevent Uncaught TypeError: Illegal invocation * Adding unit tests for handleExistingIndexPatternsScenario function * Add helper function to aid unit testing * Refactor unit tests * Inlining function to prevent naming awkwardness * Binding this to window to remove ambiguity * Adding missing import * Fixing import * Catching expected error
Backported to:
|
* Consolide chrome visibility toggle code into single module * Extracting code into helper functions for better readability * Removing redundant setting * Extracting functions to higher level in scope so they are not defined multiple times * Fixing typo in comment * Starting to add unit tests * Actually adding the tests this time * Adding unit tests for handleGettingStartedOptedOutScenario function * Binding this to window to prevent Uncaught TypeError: Illegal invocation * Adding unit tests for handleExistingIndexPatternsScenario function * Add helper function to aid unit testing * Refactor unit tests * Inlining function to prevent naming awkwardness * Binding this to window to remove ambiguity * Adding missing import * Fixing import * Catching expected error
This reverts commit c4b3ade.
* Revert "When on an embedded page, bypass Getting Started gate check (#12040)" This reverts commit 05293f1. * Revert "Making tweaks. (#12003)" This reverts commit aa3fa06. * Revert "Functional tests for the Getting Started page (#11850)" This reverts commit 099178a. * Revert "Prevent flicker on Getting Started page (#11826)" This reverts commit c4b3ade. * Revert "Getting Started page (#11805)" This reverts commit 32eff37. * Remove check for Getting Started page from navigateToApp
* Revert "When on an embedded page, bypass Getting Started gate check (#12040)" This reverts commit 05293f1. * Revert "Making tweaks. (#12003)" This reverts commit aa3fa06. * Revert "Functional tests for the Getting Started page (#11850)" This reverts commit 099178a. * Revert "Prevent flicker on Getting Started page (#11826)" This reverts commit c4b3ade. * Revert "Getting Started page (#11805)" This reverts commit 32eff37. * Remove check for Getting Started page from navigateToApp
* Revert "When on an embedded page, bypass Getting Started gate check (elastic#12040)" This reverts commit 05293f1. * Revert "Making tweaks. (elastic#12003)" This reverts commit aa3fa06. * Revert "Functional tests for the Getting Started page (elastic#11850)" This reverts commit 099178a. * Revert "Prevent flicker on Getting Started page (elastic#11826)" This reverts commit c4b3ade. * Revert "Getting Started page (elastic#11805)" This reverts commit 32eff37. * Remove check for Getting Started page from navigateToApp
Fixes #11808.
What's in the box
This PR:
Prevents flicker of the chrome by starting out the chrome as invisible. Then, depending on the scenario being handled in the
add_setup_work.js
module'sgettingStartedGateCheck
function, makes the chrome visible again.Consolidates the code that toggles the chrome visibility into a single module,
add_setup_work.js
, making it easier to reason about chrome visibility under various scenarios.Extracts the three scenarios handled by the
gettingStartedGateCheck
function into their own functions for better readability.Before this PR
After this PR