Nachdem ich in meinem letzten Blog-Beitrag aufgezeigt habe, wie du deine LiveView-Ansicht um einen Load-More-Button und Sortierung erweitern kannst, kümmern wir uns nun um das Filtern der Liste.
Du findest das Projekt auf Github. Ich baue hier auf dem Ergebnis aus meinem letzten Blog-Beitrag auf.
Datenbankmodell
Im ersten Schritt erweitern wir das Datenbankmodell für die Länder, um die Filter im Abruf der Daten aus der Datenbank einzubinden:
Wir legen hier zuerst einen Abfrage-Query zum Abruf aller Länder aus der Datenbank an (29) und wenden dann die Filter aus dem Parameter filters darauf an(34-38). Wir wandeln dazu den Parameter in eine Liste um (33). Jeder Eintrag dieser Liste enthält ein Key-Value-Paar, wobei der Schlüssel den Namen des zu filternden Felds anzeigt. Der Wert enthält den Wert, nach dem gefiltert werden soll. Soll z. B. nach „Name enthält DE“ gefiltert werden, wäre das entsprechende Paar: { 'name': 'de' }. Die Filter werden über den SQL-Vergleichsoperator ilike realisiert (37). Dadurch werden Groß- und Kleinschreibung ignoriert. Die %-Zeichen, die am Anfang und Ende des Filterwerts hinzugefügt werden, bewirken, dass nach Werten gesucht werden, die beliebige Zeichen vor oder nach dem Filterwert beinhalten. Es werden also sämtliche Einträge ausgegeben, die den eingegebenen Wert beinhalten.
Der restliche Code enthält die Sortierung und Paginierung, die wir im vorherigen Artikel kennengelernt haben.
Die Funktion list_countries/1 ruft jetzt diese erweiterte Funktion mit einem leeren Filter auf:
Template
In der Datei lib/phoenix_rise/web/core_components.ex, die Vorlagen für verschiedene Komponenten enthält, passen wir die Tabellen-Vorlage an, um Eingabefelder für die Filter hinzuzufügen:
Der button (491-496) ist eine etwas schickere Version zum Sortieren der Tabelle. Die Form zum Filtern wird danach eingefügt (499-507). Die Form löst sowohl bei der Eingabe von neuen Zeichen, als auch beim Bestätigen das filter-Event aus. Das wird durch phx-change bzw. phx-submit angegeben (499). Über phx-debounce (504) wird festgelegt, dass das filter-Event nur jede Sekunde aktualisiert wird. Das verhindert eine übermäßige Beanspruchung der Datenbank. Je nach Tabellengröße können hier längere oder kürzere Zeitangaben sinnvoll sein. Kürzere Zeitangaben sorgen für ein direkteres Feedback, während längere Zeitangaben die Datenbankzugriffe reduzieren.
Makro
Weitere Änderungen sind im Ordering-Modul notwendig.
In der mount-Funktion wird der list_function, die den Aufruf von list_countries/2 abstrahiert, ein Parameter für die Filter hinzugefügt (32):
Ebenfalls wird für den Socket eine Variable für die Filter angelegt (39).
In den Event-Handlern für die bereits bestehenden Events werden die Filter nur durchgereicht:
Schließlich benötigen wir einen Event-Handler für das filter-Event:
Der wichtige Part ist hier das auswerten der Filter aus den Input-Feldern (100-110). Die Filter werden mit den übrigen Parametern zum Sortieren an die list_function übergeben, um die gefilterten Elemente aus der Datenbank zu erhalten (114-118).
Live Views
In der Datei lib/phoenix_rise_web/live/country_live/index.ex ersetzen wir die list_function In der Datei lib/phoenix_rise_web/live/country_live/index.ex ersetzen wir die list_function &Basic.list_countries/1 durch &Basic.list_countries/2, die den filters-Parameter enthält:
Im letzten Schritt geben wir in der Datei lib/phoenix_rise_web/live/country_live/index.html.heex die filters-Variable aus dem Socket an die Tabelle aus den core_components weiter (12):
Fazit
Etwas sauberer wäre es, eine neue Komponente anzulegen (z. B. .filter_and_order_table), statt die .table-Komponente aus den core_components zu ändern. Das verhindert Konflikte mit anderen Ansichten, die die .table-Komponente verwenden.
Wir haben die Tabellen-Komponente um einfache Filter, Sortierung und Paginierung erweitert.
Falls Dir der Beitrag gefällt, oder wenn Du Fragen oder Anmerkungen hast, lass doch gerne einen Kommentar da.
Schreibe einen Kommentar