Requests not batched when using UMD via <script> tags

[sarahdayan]

Description

When loading Autocomplete and Autocomplete plugins via <script> tags, it seems that requests to Algolia aren't being batched like they should be. For example, when you have one source in getSources and you're using the Query Suggestions plugin, you get two separate requests to Algolia instead of a multi-query.

Reproduction

Preview →

Steps

1. Go to sandbox and open Network panel filtered on "algolia"
2. Type "a" in the search input
3. See two requests go

Expected behavior

When using ESM imports, requests are batched as expected (see example).

It should work regardless of what imports you're using and how you import them.

Environment

• OS: macOS Monterey 12.2
• Browser: Firefox 96.0.3
• Autocomplete version: 1.5.2

[Haroenv]

I wonder if this is because the plugins have their own state that's shared with -js if bundled?

[sarahdayan]

Plugins behave like our InstantSearch middlewares, and we process all sources at once in onInput, that's where we "merge" requests—the plugin doesn't perform requests on its own. Normally once the functions are available in the scope they shouldn't act differently, but we could be overlooking specific behaviors related to the UMD format.

[tkrugg]

it looks like when using the UMD build, each bundle contains its own declaration of .execute method,
which causes this check to fail. I'm not sure this check is mandatory, can we get rid of it? am I missing something that makes it necessary?

[sarahdayan]

@tkrugg Excellent finding!

The goal of this branch is to group Algolia requests per client before dispatching them. For example, if you have three sources using getAlgoliaResults with the same client, we group them and use the requester of the first one to process each query (since we've determined this is the same requesters using the same internals).

Technically, you could have two requesters using the same client, but with two different execute functions (I can't think of a practical example, and we don't have any in our code, but if a user writes one, it could happen). In this case we want to check whether execute is the same between two PackedDescriptions to make sure we don't group requests that should be processed differently (regardless of whether they use the same client).

Note that this problem is only theoretical for now. Removing the check doesn't break any test, and I don't believe there's any other reason. If we want to stay cautious, we can identify the function differently (e.g., add a private __id on it and compare that) which shouldn't add to the bundle.

cc @Haroenv

[sarahdayan]

This is solved by #902, released in 1.5.3.