Feature request: Vue composables with search state

[Rigo-m]

It would be nice to be able to access the instant search current state (or states, depending on how many instantsearch parent components we have in the page) in our component's setup via some composables like useInstantSearch, useAisStats, useCurrentRefinements etc.

[Haroenv]

We have so far chosen to not yet support composables, but you can take the logic which is in widgetMixin and put that in a composable instead in your own codebase. You can be inspired by this PR: algolia/vue-instantsearch#1052

[Rigo-m]

Thanks for the quick response!
Can you elaborate on why you chose to not support it? And will you in the future?

[Haroenv]

The ratio of people who were interested to use it vs. the effort it would take to maintain the split API did not seem worth it at the time. We might in the future if there's a higher ratio of people using Vue 3.

[Rigo-m]

Hope you'll reconsider, community is now big on nuxt 3 and vue 3 adoption.
Also, it's 2023, checks out 😄

[Rigo-m]

For anyone stumbling across this discussion, I've started working at a nuxt 3 implementation for instantsearch https://nuxt-swiftsearch.netlify.app/

[kevintruby]

Chiming in here, as the enterprise company I work for relies heavily on Algolia and uses the vue-instantsearch library: now that Vue 2 has reached EOL approximately 6 months ago, is this something Algolia will be looking to reconsider?

Our application has gone through a lot of work to embrace Vue 3's Composition API and the <script setup> pattern with TS¹. To be honest, the current SSR mechanism is incredibly incompatible with our needs and is steadily increasing our technical debt.

I've been able to import types from the core library and derive a custom composable to recreate what createWidgetMixin() wires up for the handful of custom widgets in our stack, but our primary components that manage <AisInstantSearchSsr> instances cannot meaningfully update.

I really appreciate several cases in the past, particularly around 2020 and 2021, where Algolia staff and @Haroenv in particular helped troubleshoot and published updates for specific SSR issues we faced -- especially to help us use two different types of pages driven by the system that, at first, could not navigate between the types directly.

This answer to avoid supporting the pattern entirely made sense in early 2023, when both versions were actively maintained. As it stands now, though, I believe the best course of action would be to sunset Vue 2 support² and offer a solution that fits with the framework's evolution and prioritizes TS support, as other major libraries have done.

Footnotes

1. which relates to this other discussion about TS support ↩

2. retaining an archived version for those who still rely on it ↩

[Haroenv]

Is your question only about exposing composable or is there any other work that needs to be done to support Vue 3 more fully than already the case now?

[Rigo-m]

@kevintruby take a look at https://nuxt-swiftsearch.netlify.app/ it might be of interest in your case.
@Haroenv I think there is a lot of work to be done to refactor the vue-instantsearch package to migrate to vue 3, it's not just about exposing composable logic