Javascript – API-Design zum Besprechen von Benachrichtigungslisten und -details

Ich möchte eine Benachrichtigungskomponente basierend auf MVVM erstellen und alle Daten werden in JSON vorliegen. Die Listenseite verfügt über Filter- und Suchfunktionen. Benachrichtigungsdetails rufen die vorherige Meldung auf und wechseln zur nächsten.

Wenn es keine Filter- und Suchbedingungen gibt, kann die globale vorherige und nächste Umschaltung direkt auf der Detailseite erfolgen, und wenn Filterbedingungen oder Suchbedingungen vorhanden sind, kann die vorherige und nächste Umschaltung in der Suche erfolgen Ergebnisliste.

Option 1:

Das ist ein Plan, den ich mir selbst ausgedacht habe.
Wenn die gesamte Komponente initialisiert wird, werden alle Benachrichtigungen (IDs) unter diesem Benutzer lokal abgerufen und global aufgezeichnet [store.list.all]. Wenn später auf die Detailseite geklickt wird, übernimmt das Frontend die ID des Benutzers Element, auf das geklickt werden soll: Stellen Sie eine Ajax-Anfrage mit Parametern, sodass die Detailseite die aktuelle Benachrichtigungs-ID und eine Liste aller Benachrichtigungs-IDs enthält. Auf diese Weise kann die Detailseite leicht die ID des vorherigen Elements und die ID des nächsten Elements erkennen.
Wenn es Filter- oder Suchbedingungen gibt, denken Sie daran, global [store.list.filter] zu verwenden. Die Methode ist dieselbe wie oben.

• Vorteile: Vorherige und nächste Elemente lassen sich sehr einfach implementieren, und es ist nicht erforderlich, bei jedem Umblättern der Listenseite Daten anzufordern.

• Nachteile: Wenn die Benachrichtigungsliste des Benutzers sehr lang ist, sind die Daten, die während der Initialisierung und Suche angefordert und in [store.list] aufgezeichnet werden müssen, sehr groß, und die Startseite kann sehr groß sein langsam und die Leistung wird sich verschlechtern.

Option 2:

Vorschläge der bisherigen Produkte des Unternehmens.
Bei der Paging-Abfrage auf der Listenseite verwendet jede Anforderung die Seitenzeile als Parameter und die Abfrage wird in Form einer Abfrage der Zeilenanzahl auf der Seite ausgeführt (z. B. Seite = 3, Zeile = 10, was bedeutet, dass die Seite abgefragt wird). 31.-40. Streifen). Filter- und Suchfunktionen sind identisch.
Bei früheren Produkten war das Umschalten zwischen dem vorherigen und dem nächsten Artikel nicht möglich.
Wenn Sie dieser Idee jedoch weiterhin folgen, wird es wahrscheinlich so aussehen:
Senden Sie unter keinen Filtersuchbedingungen die aktuelle ID als Parameter und bringen Sie die nächsten oder vorherigen Parameter mit, damit Sie sich darauf verlassen können Informieren Sie sich über diese Methode beim Abfragen der Datenbank. select * from foo where id = (select min(id) from foo where id > 4)Mit gefilterten Suchbedingungen ist das ziemlich ekelhaft. Ich habe wahrscheinlich den Suchstatus gespeichert, als ich auf der Listenseite auf die Detailseite geklickt habe Diesen Status speichern), und wenn dann zum vorherigen oder nächsten Element gewechselt wird, werden zusätzlich zu id und next auch Suchbedingungen für die Abfrage einbezogen. Es wäre einfach widerlich, die Ajax-Anfrage-API zu schreiben.

• Vorteile: Die Listenseite ist paginiert und Benutzer haben keine Angst davor, wie viele Benachrichtigungen sie haben.

• Nachteile: Beim Umblättern der Listenseite sind Anforderungen und Abfragen erforderlich. Die Abfragebedingungen sind komplex und die Back-End-Belastung ist höher. Eine Ajax-Anfrage für den nächsten Hop auf der Detailseite ist schwieriger schreiben.

Derzeit gibt es nur zwei Ideen, jede mit ihren eigenen Vor- und Nachteilen.

Haben Sie noch weitere Ideen?

Antwortinhalt:

Ich möchte eine Benachrichtigungskomponente basierend auf MVVM erstellen und alle Daten werden in JSON vorliegen. Die Listenseite verfügt über Filter- und Suchfunktionen. Benachrichtigungsdetails rufen die vorherige Meldung auf und wechseln zur nächsten.

Wenn es keine Filter- und Suchbedingungen gibt, kann die globale vorherige und nächste Umschaltung direkt auf der Detailseite erfolgen, und wenn Filterbedingungen oder Suchbedingungen vorhanden sind, kann die vorherige und nächste Umschaltung in der Suche erfolgen Ergebnisliste.

Option 1:

Das ist ein Plan, den ich mir selbst ausgedacht habe.

Wenn die gesamte Komponente initialisiert wird, werden alle Benachrichtigungen (IDs) unter diesem Benutzer lokal abgerufen und im globalen [store.list.all] aufgezeichnet. Wenn später auf die Detailseite geklickt wird, übernimmt das Frontend die ID des anzuklickenden Elements als Stellen Sie eine Ajax-Anfrage mit Parametern, damit die Detailseite die aktuelle Benachrichtigungs-ID und eine Liste aller Benachrichtigungs-IDs enthält. Auf diese Weise kann die Detailseite leicht die ID des vorherigen Elements und die ID des nächsten Elements erkennen.
Wenn es Filter- oder Suchbedingungen gibt, denken Sie daran, global [store.list.filter] zu verwenden. Die Methode ist dieselbe wie oben.

• Vorteile: Vorherige und nächste Elemente lassen sich sehr einfach implementieren, und es ist nicht erforderlich, bei jedem Umblättern der Listenseite Daten anzufordern.

• Nachteile: Wenn die Benachrichtigungsliste des Benutzers sehr lang ist, sind die Daten, die während der Initialisierung und Suche angefordert und in [store.list] aufgezeichnet werden müssen, sehr groß, und die Startseite kann sehr groß sein langsam und die Leistung wird sich verschlechtern.

Option 2:

Vorschläge der bisherigen Produkte des Unternehmens.
Bei der Paging-Abfrage auf der Listenseite verwendet jede Anforderung die Seitenzeile als Parameter und die Abfrage wird in Form einer Abfrage der Zeilenanzahl auf der Seite ausgeführt (z. B. Seite = 3, Zeile = 10, was bedeutet, dass die Seite abgefragt wird). 31.-40. Streifen). Filter- und Suchfunktionen sind identisch.
Bei früheren Produkten war das Umschalten zwischen dem vorherigen und dem nächsten Artikel nicht möglich.
Wenn Sie dieser Idee jedoch weiterhin folgen, wird es wahrscheinlich so aussehen:
Senden Sie unter keinen Filtersuchbedingungen die aktuelle ID als Parameter und bringen Sie die nächsten oder vorherigen Parameter mit, damit Sie sich darauf verlassen können Informieren Sie sich über diese Methode beim Abfragen der Datenbank. select * from foo where id = (select min(id) from foo where id > 4)Mit gefilterten Suchbedingungen ist das ziemlich ekelhaft. Ich habe wahrscheinlich den Suchstatus gespeichert, als ich auf der Listenseite auf die Detailseite geklickt habe Diesen Status speichern), und wenn dann zum vorherigen oder nächsten Element gewechselt wird, werden zusätzlich zu id und next auch Suchbedingungen für die Abfrage einbezogen. Es wäre einfach widerlich, die Ajax-Anfrage-API zu schreiben.

• Vorteile: Die Listenseite ist paginiert und Benutzer haben keine Angst davor, wie viele Benachrichtigungen sie haben.

• Nachteile: Beim Umblättern der Listenseite sind Anforderungen und Abfragen erforderlich. Die Abfragebedingungen sind komplex und die Back-End-Belastung ist höher. Eine Ajax-Anfrage für den nächsten Hop auf der Detailseite ist schwieriger schreiben.

Derzeit gibt es nur zwei Ideen, jede mit ihren eigenen Vor- und Nachteilen.

Haben Sie noch weitere Ideen?

Der fatale Schlag von Option 1: Wenn ein Benutzer 100.000 Benachrichtigungen verwendet.

Der fatale Schlag von Option 2: Eine kontinuierliche Erhöhung der Komplexität der Abfragebedingungen erhöht den Speicherdruck.

======

Mittlere Lösung

N Tage Daten gleichzeitig lesen (vorausgesetzt, die Datenmenge von N Tagen ist grundsätzlich kontrollierbar, andernfalls wird diese Lösung nicht implementiert).

Zuverlässige Lösung

Verwenden Sie Elasticsearch