ReactiveSearch: React and Vue Search UI Components for Elasticsearch, OpenSearch, Solr and MongoDB

What ReactiveSearch actually solves for a search front end

Building a faceted search page by hand means writing the same loop over and over: a dropdown selection becomes a filter clause, a slider becomes a numeric range, a typed term becomes a suggestion query, and every one of those has to re-trigger the others. ReactiveSearch packages that loop as components. The README lists over 20 UI components covering lists, ranges, search inputs, result displays, AI answers and charts, and it splits them into two roles. Sensor components produce queries. A SingleList applies an exact match filter on the selected item. A RangeSlider applies a numeric range query. A SearchBox applies a suggestions and search query from the typed term. Display components consume the results: ReactiveList for list and card output, ReactiveMap for Google Maps or OpenStreetMaps rendering, AIAnswer for retrieval augmented generation through search engine and OpenAI models, and ReactiveChart for pie, bar, histogram, line and scatter charts on top of Apache E-Charts.

The audience is narrow but real. You need a React or Vue front end and one of the four engines the README names: Elasticsearch, OpenSearch, Solr or MongoDB. If you are on another JS framework, React Native or Flutter, the README points you to Searchbox rather than this library. ReactiveChart is React only at this time, so a Vue team gets the rest of the component set but not the charts.

The react prop and the v3 to v4 query boundary

The mechanism that holds the library together is the react prop. Each component declares which other components it should react to, and the README describes this as configurable on a per-component level. That is how a SingleList selection can narrow a ReactiveList while a RangeSlider simultaneously constrains it, without the application wiring the dependency graph by hand. The library handles the transformation of UI interactions into search intent queries.

What changed in v4 is where that intent is resolved. In v4, the README states, the library only sends the search intent, and ReactiveSearch cloud generates the search query DSL based on whichever engine you configured there. The stated rationale is twofold: it is more secure, and it moves search business logic to the server side. The trade-off is architectural rather than cosmetic. Your front end no longer needs to know Elasticsearch query DSL, but it does need a cloud service in the path between the browser and your index. In v3, using the ReactiveSearch API instead of Elasticsearch query DSL was opt-in, enabled by setting the enableAppbase prop to true on ReactiveBase, and the README notes that this assumes appbase.io as the backend. So the version you pick determines whether the cloud is mandatory or optional, and that decision is worth making before you write components.

Installing ReactiveSearch and rendering a first list

The README gives one-step installation through npm. The package name for the React build is @appbaseio/reactivesearch.

npm i @appbaseio/reactivesearch

After installation you wrap your search page in ReactiveBase, which is the component that carries the backend configuration, and then place sensor and display components inside it. The README does not reproduce a full ReactiveBase example inline; it points to the quickstart page and to the reactivesearch starter app repository for a working project. The component playground at opensource.appbase.io/playground is where the README suggests you inspect each component: filter by ReactiveSearch, pick a story such as the Range components RatingsFilter, and use the knobs section to change props and watch the effect. That playground is the fastest way to confirm a prop name before you commit it to code, because the README itself documents components by linking out to docs.reactivesearch.io rather than by listing props.

One practical note for v3 users: if you are on v3 and want the ReactiveSearch API path, the README's instruction is to set enableAppbase to true on ReactiveBase. That prop does not appear in the v4 description, because in v4 the intent-only path is the default.

Where the documentation thins out

The README is a directory, not a manual. Nearly every component reference is a link to docs.reactivesearch.io, and the repository README itself does not list required or optional props for any component. That means you cannot evaluate the API surface from the repository alone. You have to follow the links.

The more consequential gap is the migration path. The README explains that v4 changed the query model and that v3 had enableAppbase as an opt-in, but it does not document what happens to an existing v3 application that upgrades. There is no rollback guidance in the README, no statement of which v3 props were removed, and no compatibility table. The changelogs directory and CHANGELOG.md exist in the repository layout, and the release list shows v4.3.1 as the current React release alongside [email protected], so the version history is tracked. But if you are planning an upgrade, the README will not tell you the cost. You will be reading changelog entries and the API reference instead.

A second limitation is structural. Because v4 sends intent rather than query DSL, any query the ReactiveSearch API reference does not express is out of reach without going around the library. The README does not describe an escape hatch for raw engine queries in v4.

ReactiveSearch compared with Searchkit

Searchkit is the comparison that surfaces most often in searches around this project, and the difference is not cosmetic. Searchkit is a React component library that talks to Elasticsearch directly: the components build Elasticsearch queries and the application owns the connection to the cluster. ReactiveSearch v4 inverts that. The front end emits a search intent, ReactiveSearch cloud translates it into the query DSL for whichever engine you configured, and the engine-specific logic lives on the server. If your constraint is that no third party sits between your UI and your index, Searchkit's model matches that constraint and ReactiveSearch v4's does not. If your constraint is that you want to switch between Elasticsearch, OpenSearch, Solr and MongoDB without rewriting query construction, ReactiveSearch's model is the one that addresses it, because the README lists all four as supported engines behind the same component set. ReactiveSearch also spans React and Vue, which Searchkit does not. The honest framing is that these are two different answers to where query logic should live, and you should pick based on that answer rather than on component counts.

Maintenance, licence and the cost of staying current

The repository is not archived, and the last push was on 2026-07-26, which is recent enough that the project is being worked on rather than parked. The release cadence visible in the release list is uneven between the two frameworks: v4.3.1 for React and [email protected] both landed on 2026-07-26, while the previous Vue release, [email protected], was on 2025-03-10. That is a gap of more than a year between Vue releases, and it is worth knowing if Vue is your target, because a React-side fix may not appear in the Vue package on the same schedule.

The licence is Apache-2.0, declared in both the repository metadata and the root package.json. Apache-2.0 permits commercial use and modification and includes a patent grant, which is why it is a common choice for a UI library that companies embed in products. It also carries notice and attribution obligations when you redistribute. That is a description of the licence terms, not advice about your situation; if you are redistributing the library as part of a product, have your own counsel read the LICENSE file rather than this article.

Upgrade cost is the part the README understates. The v3 to v4 shift from opt-in intent to intent-only is a change in where queries are built, so an upgrade touches your backend configuration as well as your components. The repository tracks changes in CHANGELOG.md and the changelogs directory, and the README's link to the ReactiveSearch API reference is the specification you would need to read. Budget for that reading before you budget for the code change.

Editorial conclusion

ReactiveSearch fits teams building a faceted search UI on React or Vue who are willing to run ReactiveSearch cloud as the query layer: v4 sends search intent rather than query DSL, and the cloud generates the engine-specific query. Teams that must keep query construction inside their own backend, or that need a native mobile UI, should look at the Searchbox pointer in the README or at Searchkit instead. Before adopting, verify two things: whether the ReactiveSearch API reference documents the intent payloads for every component you plan to use, and whether your deployment can reach the cloud endpoint the library targets. The README's v3 note about enableAppbase is the clearest statement of the v3 to v4 boundary, and it is worth reading before you pick a version.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes