JavaScript-API design to discuss a list of announcements and details

Want to make a notification component, based on MVVM, all data goes json. The list page has filtering and search capabilities. Notification details take a next switch.

We hope to achieve the next toggle in the detail page without filtering and search conditions, but when there are filters or search conditions, the previous one is toggled in the search results list.

Scenario 1:

This is the plan that I think of myself.
When the entire component is initialized, all the notifications (IDS) under this user are taken locally, to the global [Store.list.all], and then when you click on the Details page, the front end takes the entry ID that you want to click as an AJAX request, so that the details page has the current notification ID and a list of all the notification IDs. This makes it easy to know the ID of the previous article and the ID of the next article.
When there are filtering or search conditions, remember the global [Store.list.filter], the same method as above.

• Pros: The next bar becomes very easy to implement, and the list page does not need to request data each time it is paged.

• Cons: If the user's notification list is very long, then initialization and search, the data that needs to be requested and recorded in [Store.list] will be very large, the home page speed may be very slow, and the performance will be worse.

Scenario 2:

Company's previous product solutions.
List page to do paging query, each request to use Page+row to do parameters, a page row bar, query page the way to query (such as page=3,row=10, which means query 第31-40条). Filtering and search functions are the same.
The previous product did not implement the previous next toggle.
But if you continue to follow this idea, it will probably be:
No filter search conditions, send the current ID as a parameter, and take the next or previous parameters, so that the database query can rely on select * from foo where id = (select min(id) from foo where id > 4) this way to query.
There are filter search conditions, this is more disgusting, I did not think of a good idea, probably in the list page points into the details page when saving the search status (this can be done, the return button has saved this state), and then in the next bar, in addition to the ID, next, but also with the search criteria to do the query. Is that the AJAX request API will be more disgusting to write.

• Pros: List page pagination, the number of users who are not afraid of notifications.

• Disadvantage: The list page when you also want to request and query, query conditions complex, back-end burden, the details of the next hop on the AJAX request will be more difficult to write.

At present, these two ideas, each have advantages and disadvantages.

Do you have any other ideas?

Reply content:

Want to make a notification component, based on MVVM, all data goes json. The list page has filtering and search capabilities. Notification details take a next switch.

We hope to achieve the next toggle in the detail page without filtering and search conditions, but when there are filters or search conditions, the previous one is toggled in the search results list.

Scenario 1:

This is the plan that I think of myself.
When the entire component is initialized, all the notifications (IDS) under this user are taken locally, to the global [Store.list.all], and then when you click on the Details page, the front end takes the entry ID that you want to click as an AJAX request, so that the details page has the current notification ID and a list of all the notification IDs. This makes it easy to know the ID of the previous article and the ID of the next article.
When there are filtering or search conditions, remember the global [Store.list.filter], the same method as above.

• Pros: The next bar becomes very easy to implement, and the list page does not need to request data each time it is paged.

• Cons: If the user's notification list is very long, then initialization and search, the data that needs to be requested and recorded in [Store.list] will be very large, the home page speed may be very slow, and the performance will be worse.

Scenario 2:

Company's previous product solutions.
List page to do paging query, each request to use Page+row to do parameters, a page row bar, query page the way to query (such as page=3,row=10, which means query 第31-40条). Filtering and search functions are the same.
The previous product did not implement the previous next toggle.
But if you continue to follow this idea, it will probably be:
No filter search conditions, send the current ID as a parameter, and take the next or previous parameters, so that the database query can rely on select * from foo where id = (select min(id) from foo where id > 4) this way to query.
There are filter search conditions, this is more disgusting, I did not think of a good idea, probably in the list page points into the details page when saving the search status (this can be done, the return button has saved this state), and then in the next bar, in addition to the ID, next, but also with the search criteria to do the query. Is that the AJAX request API will be more disgusting to write.

• Pros: List page pagination, the number of users who are not afraid of notifications.

• Disadvantage: The list page when you also want to request and query, query conditions complex, back-end burden, the details of the next hop on the AJAX request will be more difficult to write.

At present, these two ideas, each have advantages and disadvantages.

Do you have any other ideas?

Scenario One critical hit: If a user is notified with a 10W bar.

Scenario two fatal hit: constantly increase the complexity of query conditions, the storage pressure increased.

======

Golden Mean scheme
Read n-day data at a time (provided that the amount of data in n days is basically controllable, otherwise the scheme is not implemented).

Solutions
Using Elasticsearch

