-
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
[new-platform] migrate ui/chrome/loading_count API to new platform #21967
[new-platform] migrate ui/chrome/loading_count API to new platform #21967
Conversation
💚 Build Succeeded |
ACK: will try to take a look today or tomorrow evening (CEST) at the latest. |
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.
} | ||
export function __newPlatformInit__(instance) { | ||
if (newPlatformLoadingCount) { | ||
throw new Error('ui/chrome/loading_count already initialized with new platform apis'); |
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.
nit: ui/chrome/loading_count
---> ui/chrome/api/loading_count
?
}, | ||
|
||
getCount$: () => { | ||
return this.count$.asObservable(); |
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.
question: is there any reason why we don't want to use something like this this.count$.pipe(distinct())
instead? It looks like this will always fire even if delta
above is 0
.
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.
nope, I think it makes the most sense for this API to only emit the loading count when it changes.
.subscribe({ | ||
next: ([prev, next]) => { | ||
const delta = next - prev; | ||
this.count$.next(this.count$.getValue() + delta); |
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.
issue: it can easily go to negative numbers, what should do we in this case? Call fatalErrors.add
or just log this weird behavior and keep 0
as the minimum count?
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.
UPDATE: just put console.log
here and indeed I've seen -1
for this.count$.getValue() + delta
a couple of times (with x-pack plugins). Looks like old code didn't have this issue.
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.
Hmm, pretty sure we currently only have two things that are contributing to the loading count: the length of the $http.pendingRequest
array (can't ever go below zero) and calls to chrome.loadingCount.increment()
and decrement()
from here:
chrome.loadingCount.increment(); |
Based on that I can't imagine how we are getting negative loading counts...
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 try running in the debugger and tracing back up the call stack to see what is causing the loading count to go negative?
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't reproduce it with the latest changes, so it's all good now! :)
subscription.unsubscribe(); | ||
} | ||
|
||
this.subscriptions.length = 0; |
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.
question: should we this.count$.next(0)
and this.count$.complete()
here and restart in start
(and simple test for this if you agree)? Otherwise this.count$
and its subscribers will stay in some "undefined" state.
|
||
const startContract = service.start({ | ||
fatalErrors: { | ||
add: jest.fn(), |
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.
optional nit: maybe add a simple test for error
case when we call fatalErrors.add
?
…latform/loading-count
…nd cleanup better
51faa92
to
237f497
Compare
@azasypkin tracked down that error, it was caused by digest cycles that get triggered when react components use methods like |
💚 Build Succeeded |
Huh, nice find! |
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! Tested locally one more time and haven't noticed anything suspicious.
tap(count => { | ||
if (count < 0) { | ||
throw new Error( | ||
'Observables passed to loadingCount.add() must only emit possitive numbers' |
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.
typo: possitive
---> positive
.
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.
Spelling is not my strong suit. Thank you 🙏
…latform/loading-count
💔 Build Failed |
Retest |
💚 Build Succeeded |
…lastic#21967) Part of elastic#20696, required for elastic#20697 This migrates the `chrome.loadingCount` API to the new platform, which was not planned to happen before elastic#20697 but is required as the UiSettingsClient uses the loading count to activate the global loading indicator in Kibana. This service is pretty simple, it allows adding an observable with `core.loadingCount.add(observable)` that will be subscribed to in order to contribute to the current "loading count", which can be retrieved with `core.loadingCount.get$()`. The `ui/chrome/api/loading_count` module is taking the start contract from the service and re-exposing it via the existing `chrome.loadingCount` api that we have today, including `increment()`, `decrement()`, `subscribe()`, and the automatic watching of the loading count exposed by the angular `$http` service.
6.x/6.5: fad921d |
Part of #20696, required for #20697
This migrates the
chrome.loadingCount
API to the new platform, which was not planned to happen before #20697 but is required as the UiSettingsClient uses the loading count to activate the global loading indicator in Kibana. This service is pretty simple, it allows adding an observable withcore.loadingCount.add(observable)
that will be subscribed to in order to contribute to the current "loading count", which can be retrieved withcore.loadingCount.get$()
.The
ui/chrome/api/loading_count
module is taking the start contract from the service and re-exposing it via the existingchrome.loadingCount
api that we have today, includingincrement()
,decrement()
,subscribe()
, and the automatic watching of the loading count exposed by the angular$http
service.