Optimistic UI

[francoischalifour]

InstantSearch has always relied on the result event emitted by the Algoliasearch Helper, which means that the UI doesn't get updated before the network response comes back to the browser. Can we speed up this feedback loop?

Motivation

The current InstantSearch lifecycle relies on the Algoliasearch Helper events—and we rely on the result event to render. This is problematic in terms of perceived performance because there's no feedback given to users as soon as they interact with the filters. This is particularly visible on mobile, where network connections tend to be less reliable, and you're used to touching your screen another time to make sure your action was received.

This is why I'd like to introduce the discussion about what is often called "Optimistic UI".

Description

An optimistic UI follows the principle of displaying an optimal state when an action can take some time.

In the context of InstantSearch, that would be computing the expected UI after an interaction as soon as possible, and to complete this UI after the state is effectively returned by the network.

Flow

Prerequisites

To achieve such an experience, I think that giving access to the search status to our APIs (e.g., loading, stalled, idle) would make it easier to deal with.

What it would look like

Here's a implementation from scratch (no Algoliasearch Helper, no InstantSearch) of what I have in mind for this feature.

Notice:

1. We're online, hits load
2. We go offline
3. We filter the search
4. The filter UI gets updated
5. The network doesn't answer to the user action
6. We roll back the state
7. We display an error toast

Going forward

I believe this is a feature that people don't realize they need, but they won't be able to go back once they have it.

Does anybody else realize they want this?

[Haroenv]

I guess what we can decide as indicator for "offline" is an error returned from algoliasearch, is that what you had in mind?

[francoischalifour]

Yep—you can catch the RetryError from the search client which is an indicator that all servers in the cluster have failed, and therefore there's no chance for the network response to come back.

That's how we handle network errors in DocSearch v3 too.

[eunjae-lee]

TIL about SWR and its Local Mutation reminded me of this discussion.

[Haroenv]

Since version 4.50.0 of InstantSearch.js, 4.8.0 of Vue InstantSearch and 6.39.0 of React InstantSearch Hooks, we support optimistic rendering as described here.

• when you make a change to the search state, it immediately is used for display of the existing results (feat(rendering): always render with current state #5429)
• when an error happens, we revert to the "last-known-good" state, which also updates the URL back to that state. (feat(rendering): revert search state on error #5438)

[avremel]

I've implement something like this in React Instant Search Hooks for my custom refinement list component.

• When a user clicks on a checkbox, I store the selection in state and immediately display the change.
• If items (returned from useRefinementList) updates, state gets updated to reflect that.

The code is roughly:

  const [selectedValues, setSelectedValues] = useState(() =>
    items.filter((item) => item.isRefined).map((item) => item.value)
  )

  useEffect(() => {
    setSelectedValues(items.filter((item) => item.isRefined).map((item) => item.value))
  }, [items])

The checkbox uses selectedValues.includes(value) to determine if it is selected.

[Haroenv]

Hey @avremel :) That sounds cool, but if you update to the latest version (6.39.0+), you'll get optimistic UI out of the box!

[avremel]

I upgraded to the latest libraries and don't see optimistic UI. The selected items only become refined after status finishes loading.

[Haroenv]

🤔 is this something you can reproduce? in the example of React InstantSearch Hooks for example, I can see it working as expected https://codesandbox.io/s/github/algolia/instantsearch/tree/master/examples/react-hooks/default-theme

[avremel]

CodeSandbox Notice the logs: status becomes loading before items are refined.

This isn't very noticeable in the code sandbox, but is noticeable in our app:

• Default optimistic UI
• My custom implementation with useState

[Haroenv]

Yes, the render happens on the next tick, and in your implementation it happens in React render indeed. I'm not sure what causes the event loop to be visually delayed on your implementation, that could have different reasons