fix(insights): handle multiple setUserToken call before search.start()

[eunjae-lee]

Summary

In #4849, we introduced a regression that insights middleware throws when setUserToken is called twice before search.start().

In the revised implementation of the insights middleware either adds a configure widget with userToken or calls refine function of renderState. However when instantSearchInstance is not started yet, even though configure widget is added, there is no renderState. That's why it's failing.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 767a506:

Sandbox	Source
InstantSearch.js	Configuration

[Haroenv]

please also make the renderState optional so typescript will catch this in the future :)

[eunjae-lee]

// implementation #1
const setUserTokenToSearch = (userToken?: string) => {
  const refineFromRenderState =
    instantSearchInstance.renderState?.[instantSearchInstance.indexName]
      ?.configure?.refine;

  if (configureUserToken && refineFromRenderState) {
    refineFromRenderState({ userToken });
  } else {
    if (configureUserToken) {
      instantSearchInstance.removeWidgets([configureUserToken]);
    }
    configureUserToken = createWidget({
      searchParameters: { userToken },
    });
    instantSearchInstance.addWidgets([configureUserToken]);
  }
};

// implementation #2
const setUserTokenToSearch = (userToken?: string) => {
  if (configureUserToken) {
    instantSearchInstance.removeWidgets([configureUserToken]);
  }
  configureUserToken = createWidget({
    searchParameters: { userToken },
  });
  instantSearchInstance.addWidgets([configureUserToken]);
};

In #4849, we tried to avoid "adding/removing widget" situation. That's why I used refine function from renderState once the widget is added. Now that we know renderState isn't there if instantSearchInstance is not started, it's kind of unavoidable. Does implementation #2 make sense? Or do we have another idea? cc @Haroenv

[Haroenv]

Another option to continue using renderState might be to somehow get access to the render state of the widget without waiting for InstantSearch to have it available. I'm not really sure, as it will expect the arguments given to init at least, but maybe there's an option?

[eunjae-lee]

Another option to continue using renderState might be to somehow get access to the render state of the widget without waiting for InstantSearch to have it available. I'm not really sure, as it will expect the arguments given to init at least, but maybe there's an option?

Yeah that's a path. I'll look if it's possible tomorrow.

[eunjae-lee]

@Haroenv I hoped that configureWidget.getWidgetRenderState(...) would work, but it takes helper as an argument. At subscribe() of middleware, we don't have a helper yet.

Since we aim to be able to attach userToken from the very first search call, I cannot think of other option.

[Haroenv]

let's keep it simple and fix this issue quickly, I think your solution that's not commented out is the way to go

[Haroenv]

removing and adding a widget is heavier than refining after search, but before it's the only option. LGTM

[eunjae-lee]

removing and adding a widget is heavier than refining after search, but before it's the only option. LGTM

yeah indeed. We could conditionally do differently between before and after search, but keeping it simple for now will help us refactor or improve it later.