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.

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.

If we make this generic, can we avoid the cast as string above?

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

Nit: This would probably make more sense inside src/plugins/dashboard/public/url_generator.ts. We could add a test for it there too.

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.

//nit
We don't have any function in our code base to serialize url params?

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)