-
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
[Search][Dashboard] Restore searchSessionId from URL #81489
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 we merge with master to avoid the noise of the previous PR? Thanks!
import { parse, ParsedQuery } from 'query-string'; | ||
import { Location } from 'history'; | ||
|
||
export function getQueryParams(location: Location): ParsedQuery { |
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 very similar to the utility in src/plugins/es_ui_shared/public/url/extract_query_params.ts. Not sure the best approach here but it would be nice if we could combine these.
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 point me to it!
I extracted my function from existing history
helper (in kibana_utils) so technically I didn't introduce new code.
I decided to leave as is keeping dashboard -> kibana_utils dep and not introducing dashboard -> es_ui dep.
Probably ideally es_ui_shared/public/url/extract_query_params.ts
should be removed and utility from kibana_utils
should be used instead, but es_ui_shared
is not dependent on kibana_utils
today, so doesn't worth introducing dependency to maintain for these couple lines.
import { parse, ParsedQuery } from 'query-string'; | ||
import { Location } from 'history'; | ||
|
||
export function getQueryParams(location: Location): ParsedQuery { |
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.
If we make this generic, can we avoid the cast as string
above?
export function getQueryParams(location: Location): ParsedQuery { | |
export function getQueryParams<T>(location: Location): ParsedQuery<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.
Looked into it,
ParsedQuery<T>
is a weird loose type:
export interface ParsedQuery<T = string> {
[key: string]: T | T[] | null;
}
that attempt to cover all the query cases and doesn't cover undefined
.
T in that case is just type of value
in query object.
So I guess possible way to improve with typecasting for us is something like:
export function getQueryParams<T>(location: Location): T {
return query as unknown as T
}
But I think this is worth then current downcasting on consumer level, because this involves unknown
Pinging @elastic/kibana-app-arch (Team:AppArch) |
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. Added a nit below and just wanted to confirm: Is this the first place we're using actual query parameters instead of stuffing things in the _a
or _g
(app/global state)? Are there any ramifications of this we need to be aware of?
Also wanted to note that I tested this and things seemed to function as expected (sessionId
was properly set and displayed in the inspector and properly cleared when making a change that resulted in a re-fetch, which generated a new sessionId
).
@@ -120,6 +126,9 @@ interface UrlParamValues extends Omit<UrlParamsSelectedMap, UrlParams.SHOW_FILTE | |||
[UrlParams.HIDE_FILTER_BAR]: boolean; | |||
} | |||
|
|||
const getSearchSessionIdFromURL = (history: History): string | undefined => |
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: This would probably make more sense inside src/plugins/dashboard/public/url_generator.ts
. We could add a test for it there too.
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 am keeping it separate because it depends on client side history
and url_generator stuff shouldn't depend on it and should be moved to common eventually.
No, this is not the first place. Dashboard has bunch of other query params options. Reasons I thought we are better of with separate query param:
|
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.
Tested locally in chrome. Restoring a search session works well, and everything else still works as expected. Tests and code LGTM!
); | ||
|
||
if (state.searchSessionId) { | ||
url = `${url}&${DashboardConstants.SEARCH_SESSION_ID}=${state.searchSessionId}`; |
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
We don't have any function in our code base to serialize url params?
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 think that would be
import { stringify } from 'query-string';
but I guess in this particular case using it would add more code then not using it
(can't benefit from it for _a
& _g
params here because their helpers already handling everything)
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
Added one nit
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]@kbn/optimizer bundle module count
async chunks size
page load bundle size
History
To update your PR or re-run it, just comment with: |
Build on top of #81297
Part of #61738
Summary
searchSessionId
from URLsearchSessionId
support to dashboard's URL generatorAdditional info
How to test
You can build a dashboard URL with fake session id:
Open it.
And you should see
__fake__
as session id in inspector.^^ this is what a functional test does
Checklist
Delete any items that are not applicable to this PR.