Not everything is based on UI State

[Haroenv]

There's two problems to this:

• createURL and refine actually use helper state inside widgets

This causes ui state to be possibly out of sync after a refine, which is why getUiState needs to refreshUiState first.

• places that calculate UI State don't use the previous UI State

https://github.com/algolia/instantsearch.js/blob/57c32c0a43bd2c6cbdd3f8ea7eac8109e3024f2a/src/lib/InstantSearch.ts#L569-L575

https://github.com/algolia/instantsearch.js/blob/57c32c0a43bd2c6cbdd3f8ea7eac8109e3024f2a/src/lib/InstantSearch.ts#L603-L620

https://github.com/algolia/instantsearch.js/blob/8f2aad2f0465cc883681143f350a11c24ce694e2/src/middlewares/createRouterMiddleware.ts#L26-L38

https://github.com/algolia/instantsearch.js/blob/ddf60adea7cf35f93338d6a70466ccfdbb71749e/src/widgets/index/index.ts#L434-L439

This means that an unmounted widget is automatically no longer in UI State (probably good, its refinement definitely should not be taken in account), but it also means that the following situations aren't possible:

A widget that gets mounted later has a refinement in the URL (URL gets cleared immediately of that state, unless there's another, possibly virtual, widget for the state)

• unmounting a widget and unmounting its state are linked

In React InstantSearch we have a slightly different design, where the searchState for a non-mounted widget stays in place, but in the cleanUp phase, widgets remove their respective state. This is logical for a "widgets drive state" design, that we still have, but it means that if you only want to visually unmount a widget (even if another widget is present for the same state), it's not possible.

There's some ways I imagine around this:

1. have a cleanUp step be optional per widget
2. have a cleanUp step for UI State when a widget unmounts only happen for the last widget of that state
3. allow abandoned state in all cases (possibly seems a little confusing for very dynamic use cases where you have two totally separate search interfaces on the same "page", the previous state should be removed from the URL probably?)

Possible solutions

1. make createURL and refine use UI State

This is a massive breaking change of course for all custom widgets, so maybe a transition period or a good guide on how to transform is needed. It has the advantage of not needing the helper anymore for toggling state (you'd only use getWidgetSearchParameters).

A way in which this could be mitigated is by creating a different way than normal to do createURL and refine in widgets, leaving the current way working, but warning in some way to use the modern method?

2. Keep track of the current UI State somewhere

At the moment InstantSearch doesn't know the current UI State, it needs to recompute it. I feel like this is problematic to allow unmounted widgets to stay in the UI State.

[Haroenv]

One way in which I found this problematic recently is dynamicWidgets. To have them play nicely with routing, I needed to make sure that all possible widgets are initially mounted, so the search parameters are used for the initial search.

I was trying to find a way in which there's a fallbackWidget (used when none of the attributes match), but that doesn't work for the initial mount, as you don't know which attributes currently have a refinement to be able to mount all.

[francoischalifour]

The UI state being in control of the whole search parameters is definitely flawed, and I think that the very initial problem comes even before this design decision, which is that widgets are in control of facets.

(From the library creation, widgets have been in control of both facets and facetFilters.)

The more I work on custom search implementations directly based on the JS helper, the more I appreciate non-reactive facet declarations because it leads to more predictable behaviors, and more control as a developer.

Ultimately widgets should give hints to the InstantSearch manager that they require certain facets, but I don't think they should control them. Only refinements (i.e. facetFilters) should be dynamically enabled/disabled. (And the InstantSearch manager should only disable a facet if no other widgets use it, which is another flaw in the current design).

This shift would let users have better control over the facets.

[Haroenv]

#2917 lists a similar issue, as current refinements are based on the helper, it means ui state that's not related to the helper will not show up or have any effect. We could change that by using getUiState in the current refinements widget, and setUiState as its refine, although that obviously is a big breaking change. It also means we'll need to map from the object-form to (nested?) arrays for the actual "refinements". Maybe each widget should be able to map its own ui state to an "refinements" array instead (à la metadata in React InstantSearch)

[eunjae-lee]

↑ Indeed a big breaking change, but I like that direction. Let's say we do this. After that, what left part of helper do we still get to use? barely?

[Haroenv]

helper would still be used for getWidgetSearchParameters and doing the actual request I think (unless that's also changed?)