Skip to content
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

multiSearch function does not resolve the right type after passing a FederatedMultiSearchParams type in parameter #1767

Open
ldelhommeau opened this issue Nov 25, 2024 · 4 comments · Fixed by #1776 · May be fixed by #1793
Labels
bug Something isn't working

Comments

@ldelhommeau
Copy link

ldelhommeau commented Nov 25, 2024

Description
I just updated the Meilisearch Javascript SDK to 0.45 to use the new multiSearch function with the mergeFacets attribute.
I have strongly typed my parameter to be of type FederatedMultiSearchParams as written in the SDK definition:

multiSearch<T extends Record<string, unknown> = Record<string, any>>(
queries: MultiSearchParams,
config?: Partial<Request>,
): Promise<MultiSearchResponse<T>>;
multiSearch<T extends Record<string, unknown> = Record<string, any>>(
queries: FederatedMultiSearchParams,
config?: Partial<Request>,
): Promise<SearchResponse<T>>;
async multiSearch<T extends Record<string, unknown> = Record<string, any>>(
queries: MultiSearchParams | FederatedMultiSearchParams,
config?: Partial<Request>,
): Promise<MultiSearchResponse<T> | SearchResponse<T>> {
const url = `multi-search`;
return await this.httpRequest.post(url, queries, undefined, config);
}

But the return type of the function is always of type MultiSearchResponse<Record<string, any>> were I was expecting Promise<SearchResponse<T>>.

Important note: I tried using this hack to check what was the returned object's type at runtime:
const searchResults = (await this.meilisearchClient().multiSearch(multiSearchArgs)) as unknown as SearchResponse;

And the object is of type SearchResponse with the correct properties at the root level of the object (estimatedTotalHits and facetDistribution):
image

Expected behavior
When calling the multiSearch function with the parameter queries of type FederatedMultiSearchParams I expect to have a response of type SearchResponse.

Current behavior
The TS resolution shows that the return type is MultiSearchResponse.

Screenshots or Logs
image

Environment (please complete the following information):

  • OS: MacOS Sonoma Apple M1 Pro
  • Meilisearch version: Meilisearch v1.11.3 (from docker image getmeili/meilisearch:v1.11)
  • meilisearch-js version: v0.45 (from my package.json "meilisearch": "^0.45.0",)
  • Browser: No brower, the process is run via a Strapi backend v4.15.5 (nodejs)
@Barabasbalazs
Copy link
Contributor

It seems the TS typechecker is not able to infer the return type properly just by the type of the searchparameters. I think creating conditional type could solve this issue.
Something like this:

export type MultiSearchResponseOrSearchResponse<
  T1 extends FederatedMultiSearchParams | MultiSearchParams,
  T2 extends Record<string, unknown> = Record<string, any>,
> = T1 extends FederatedMultiSearchParams
  ? SearchResponse<T2>
  : MultiSearchResponse<T2>;

@flevi29 what do you think?

@Barabasbalazs
Copy link
Contributor

I think this: #1776 should fix it

@flevi29 flevi29 added the bug Something isn't working label Nov 29, 2024
@meili-bors meili-bors bot closed this as completed in ee28916 Nov 29, 2024
@flevi29 flevi29 reopened this Dec 1, 2024
@flevi29
Copy link
Collaborator

flevi29 commented Dec 1, 2024

Reopened for the following reason: #1689 (comment)
We want to be able to provide the type of hits via generics, but at the same time we also want to infer the return type based on another generic, which dictates the type of the parameters. If we provide one generic, the others won't be inferred. If we don't provide generics, it's kind of rough to specify the desired shape of hits. What's the solution here, I'm not sure yet.

@flevi29
Copy link
Collaborator

flevi29 commented Dec 3, 2024

It seems that if you don't pass the arguments directly into the function as they are, TS doesn't even try to infer from it, which feels like a bug to me. There's no nice solution here, the result will have to be casted, which honestly is pretty much what you'd be doing with generics either way, and not a lot more verbose.

@flevi29 flevi29 linked a pull request Dec 4, 2024 that will close this issue
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants