ReactiveSearch v4: Suchabsicht statt Query-DSL, Komponenten gegen Cloud-Abhängigkeit
Suchen Sie nach UI-Komponenten für React und Vue. Wenn Sie ReactiveSearch v3 (letzte Hauptversion) verwenden, ist die Verwendung der ReactiveSearch-API über die Abfrage-DSL von ElasticSearch eine Opt-in-Funktion.
Auf einen Blick
- Was ist das?
- ReactiveSearch ist eine UI-Komponentenbibliothek für React und Vue mit über zwanzig Bausteinen für Elasticsearch, OpenSearch, Solr und MongoDB. Mit v4 verlagert das Projekt die Erzeugung der Suchanfrage in die ReactiveSearch-Cloud, was Sicherheit bringt und Bindung kostet.
- Für wen ist es gedacht?
- ReactiveSearch lohnt sich für Teams, die eine facettenreiche Suchoberfläche mit Filtern, Bereichen, Karten und Diagrammen in React oder Vue bauen und dafür fertige, thembare Komponenten statt eigener Abfragebausteine wollen. Es lohnt sich nicht für Projekte, die ihre Suchanfragen selbst erzeugen oder eine eigene Suchinfrastruktur direkt ansprechen müssen: Ab v4 entsteht die Query-DSL in der ReactiveSearch-Cloud, und wer diese Cloud nicht nutzt, verliert den Kern des Ansatzes.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 4 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich JavaScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was ReactiveSearch v4 an den Server schickt: Suchabsicht statt Query-DSL
ReactiveSearch ist eine UI-Komponentenbibliothek für React und Vue, die für den Betrieb mit der ReactiveSearch-Cloud gedacht ist. Das README beziffert den Umfang auf mehr als zwanzig Komponenten, gegliedert in Listen, Bereiche, Suchmasken, Ergebnisanzeigen, KI-Antworten, Diagramme und einen Mechanismus, um eine vorhandene eigene Komponente einzubinden.
Die wichtigste Änderung der Version 4 betrifft den Weg einer Suchanfrage zum Backend. Ab v4 sendet die Bibliothek laut README nur noch die Suchabsicht, nicht mehr eine fertige Abfrage in der Query-DSL der Suchmaschine. Die eigentliche Abfrage entsteht anschließend in der ReactiveSearch-Cloud, und zwar passend zu der Suchmaschine, die man dort konfiguriert hat. Das README nennt Elasticsearch, OpenSearch, Solr, MongoDB und OpenAI als mögliche Backends.
Das Projekt begründet diesen Schnitt mit zwei Effekten: Die Anfrage wird aus Sicht des README sicherer, weil der Client keine DSL mehr formuliert, und die Suchlogik wandert auf die Serverseite. Beides stimmt als Beschreibung des Mechanismus. Die Kehrseite gehört in jede Architekturentscheidung: Ohne die Cloud dieses Anbieters funktioniert v4 nicht wie beschrieben.
Wer noch v3 einsetzt, kann die ReactiveSearch-API ausdrücklich aktivieren. Dafür setzt man die Prop `enableAppbase` in der Komponente `ReactiveBase` auf `true`. Das README knüpft daran eine Bedingung, die man nicht überlesen sollte: Diese Option setzt voraus, dass appbase.io als Backend verwendet wird.
Der Komponentenkatalog: SingleList, RangeSlider, SearchBox, ReactiveList
Der Baukasten folgt einem einfachen Muster. Sensorkomponenten erzeugen aus einer Benutzereingabe eine Filterbedingung, Anzeigekomponenten stellen die Treffer dar. `SingleList` setzt einen exakten Trefferfilter auf das ausgewählte Element, `RangeSlider` erzeugt eine numerische Bereichsabfrage, `SearchBox` liefert Vorschläge und eine Suchabfrage zum eingegebenen Begriff.
Wie die Komponenten zusammenspielen, bestimmt die Prop `react`, und zwar auf Ebene der einzelnen Komponente. Damit lässt sich konfigurieren, welche Komponente auf welche andere reagiert, statt eine zentrale Verdrahtung zu pflegen. Für Filterkombinationen auf einer Seite ist das der Mechanismus, der den Unterschied zu einer Sammlung einzelner Widgets ausmacht.
Auf der Anzeigeseite nennt das README vier eingebaute Komponenten. `ReactiveList` stellt Ergebnisse als Liste oder als Karten dar und erlaubt eigenes Rendering sowohl auf Element- als auch auf Komponentenebene. `ReactiveMap` bindet wahlweise Google Maps oder OpenStreetMaps ein. `AIAnswer` liefert Retrieval-Augmented-Generation-Antworten über die Suchmaschine und OpenAI-Modelle. `ReactiveChart` bringt Diagramme mit.
Gestaltung läuft über die Props `className` und `innerClass` sowie über einen `ThemeProvider`. Das README hebt hervor, dass die Komponenten bereits gestylt und gekapselt sind, also kein externes Stylesheet importiert werden muss.
AIAnswer und ReactiveChart in ReactiveSearch
Zwei Komponenten fallen aus dem Rahmen einer klassischen Suchbibliothek. `AIAnswer` verbindet die Treffer der Suchmaschine mit einem Sprachmodell von OpenAI und gibt eine formulierte Antwort aus, statt nur eine Trefferliste. Wer so etwas sonst selbst bauen würde, bekommt hier den RAG-Ablauf als Baustein, mit allen Fragen, die dieser Ansatz mitbringt: Welcher Kontext geht in die Anfrage, was passiert bei fehlenden Treffern, und wer bezahlt die Modellaufrufe. Das README beantwortet keine dieser Fragen, sondern nennt nur die Verbindung von Suchmaschine und OpenAI-Modellen.
`ReactiveChart` setzt auf Apache E-Charts und bringt fünf Diagrammtypen mit: Kreis, Balken, Histogramm, Linie und Streuung. Weitere Formate im E-Charts-Format sind möglich. Die Einschränkung ist deutlich und steht im README: Die Komponente funktioniert zum jetzigen Zeitpunkt nur mit React, nicht mit Vue.
Damit ist die Vue-Variante kein gleichwertiger Abzug der React-Variante, sondern ein eigener Paketzweig. Im Repository liegen die beiden Zweige als packages/web und packages/vue, entwickelt wird auf dem Branch next. Dieser Aufbau erklärt auch, warum die Versionen auseinanderlaufen.
Installation mit npm und die Versionen von React und Vue
Die Installation besteht aus einem Befehl pro Framework. Für React lautet er `npm i @appbaseio/reactivesearch`, für Vue `npm install @appbaseio/reactivesearch-vue`. Das README verweist für die ersten Schritte auf Schnellstartanleitungen unter docs.reactivesearch.io und nennt eine Starteranwendung im Repository awesome-reactivesearch/reactivesearch-starter-app. Weitere Einrichtungsschritte beschreibt es nicht.
Bei den Versionen lohnt ein zweiter Blick, weil das Projekt keine gemeinsame Versionsnummer führt. Im Material sind für React die Fassung v4.3.1 verzeichnet und für Vue v3.5.0 sowie v3.4.0. Die Vue-Fassung trägt also eine eigene 3.x-Zählung, während die React-Fassung bereits bei 4.x steht. Wer Komponentenverhalten zwischen beiden Zweigen vergleicht, muss deshalb die jeweilige Paketversion prüfen und darf nicht von gleicher Nummer auf gleichen Funktionsumfang schließen.
Zum Ausprobieren gibt es eine Komponentenspielwiese unter opensource.appbase.io/playground, in der sich Props direkt verändern lassen, sowie eine KitchenSink-Anwendung, die die ReactiveSearch-API für alle Komponenten zeigt. Daneben listet das README Liveschauplätze: eine Büchersuche auf einem Goodbooks-Datensatz, eine Büchersuche mit Ant-Design-Gestaltung, eine Filmsuche aus dem E-Commerce-Umfeld und eine Dashboard-Anwendung mit Anmeldung, Suche und Diagrammen.
Die Cloud-Bindung von ReactiveSearch als Grenze
Die auffälligste Grenze des Projekts ist die Kopplung an einen Dienst. Ab v4 ist die ReactiveSearch-Cloud nicht nur ein möglicher Endpunkt, sondern die Stelle, an der aus der Suchabsicht eine ausführbare Abfrage wird. Wer seine Suchmaschine selbst betreibt und die Abfrage im Frontend oder in einem eigenen Backend erzeugen will, verlässt damit den vorgesehenen Pfad. Diese Bindung ist im README nicht als Einschränkung beschrieben, sondern als Sicherheitsgewinn, und beide Lesarten sind berechtigt.
Eine zweite Grenze betrifft die Framework-Abdeckung. Zwar listet das README React, Vue und React Native, doch einzelne Komponenten sind nicht überall verfügbar, wie das Beispiel `ReactiveChart` zeigt. Wer eine Komponente auswählt, sollte ihre Verfügbarkeit in der eigenen Framework-Variante prüfen, bevor er sie einplant.
Drittens ist das Projekt als Monorepo mit mehreren Zweigen organisiert, und der Entwicklungszweig heißt next. Wer Beiträge leisten oder einen Fehler melden will, findet den Leitfaden unter .github/CONTRIBUTING.md. Im Umfeld des Projekts existieren weitere Bausteine: ein API-Gateway mit Sicherheitsfunktionen, Ratenbegrenzung, Auswertung und Anforderungsprotokollen, die Bibliothek searchbox für andere JS-Frameworks und Flutter, der Datenbetrachter dejavu für Elasticsearch und OpenSearch sowie appbase-js für das Indizieren. Diese Aufteilung ist praktisch, vergrößert aber die Zahl der Pakete, deren Versionen man im Blick behalten muss.
InstantSearch und SearchKit im Vergleich zu ReactiveSearch
Das README enthält selbst einen Vergleich mit zwei anderen Bibliotheken, und der taugt als Entscheidungshilfe. SearchKit arbeitet laut Tabelle mit jedem Elasticsearch-Index, ist aber nur für React verfügbar und setzt auf BEM-CSS. Eigene Komponenten einzubinden, wie ReactiveSearch es anbietet, ist dort nicht vorgesehen. Wer Elasticsearch direkt anspricht und nur React einsetzt, findet in SearchKit den schlankeren Weg ohne Cloud dazwischen.
InstantSearch deckt mehr Frameworks ab, nämlich React, Vue, Angular, Vanilla JS und React Native, wobei für React Native keine UI-Komponenten mitgeliefert werden. Der entscheidende Unterschied liegt im Backend: InstantSearch ist auf Algolia ausgerichtet, während ReactiveSearch mehrere Suchmaschinen hinter der Cloud ansprechen kann. Beim Styling verlangt InstantSearch einen externen Stilimport, ReactiveSearch bringt gestylte und gekapselte Komponenten mit.
Die Wahl ist damit weniger eine Frage der Komponentenzahl als der Architektur. Wer bereits Algolia nutzt und mehrere Frontend-Frameworks bedient, ist bei InstantSearch richtig. Wer Elasticsearch, OpenSearch, Solr oder MongoDB im eigenen Betrieb hat und die Abfrageerzeugung abgeben will, bekommt bei ReactiveSearch die passende Kombination, trägt dafür die Cloud-Bindung. Wer Elasticsearch ohne Umweg ansprechen will, liegt bei SearchKit näher am Ziel, schreibt aber mehr Abfragelogik selbst.
Redaktionelles Fazit
ReactiveSearch lohnt sich für Teams, die eine facettenreiche Suchoberfläche mit Filtern, Bereichen, Karten und Diagrammen in React oder Vue bauen und dafür fertige, thembare Komponenten statt eigener Abfragebausteine wollen. Es lohnt sich nicht für Projekte, die ihre Suchanfragen selbst erzeugen oder eine eigene Suchinfrastruktur direkt ansprechen müssen: Ab v4 entsteht die Query-DSL in der ReactiveSearch-Cloud, und wer diese Cloud nicht nutzt, verliert den Kern des Ansatzes. Vor der Entscheidung zu prüfen: ob die eigene Suchmaschine zu den unterstützten Backends gehört, ob die Verlagerung der Abfragelogik in die Cloud mit den eigenen Vorgaben zu Datenfluss und Betrieb vereinbar ist, und ob die benötigten Komponenten überhaupt in der eigenen Framework-Variante liegen, denn ReactiveChart ist laut README nur für React verfügbar.
Community-Notizen