javascript - API design for discussing notification lists and details

I want to make a notification component, based on MVVM, and all data will be in json. The list page has filtering and search functions. Notification details bring up the previous one and switch to the next one.

It is hoped that when there are no filtering and search conditions, the global previous item and next item can be switched directly in the details page; and when there are filter conditions or search conditions, the previous item and next item can be switched in the search result list.

Option 1:

This is the plan I came up with myself.
When the entire component is initialized, all notifications (IDs) under this user are fetched locally and recorded globally [store.list.all]. Then when the details page is clicked, the front end takes the ID of the item to be clicked as a parameter. ajax request, so that the details page has the current notification id and a list of all notification ids. In this way, the details page can easily know the id of the previous item and the id of the next item.
When there are filtering or search conditions, remember to global [store.list.filter], the method is the same as above.

• Advantages: Previous and next items will become very easy to implement, and there is no need to request data every time the list page is turned.

• Disadvantages: If the notification list of this user is very long, then during initialization and search, the data that needs to be requested and recorded in [store.list] will be very large, the home page may be very slow, and the performance will be worse. .

Option 2:

Projects of the company’s previous products.
To do paging query on the list page, each request uses page+row as parameters, and the query is performed by querying the page of row items (for example, page=3, row=10, which means querying items 31-40 ). Filtering and search functions are the same.
Previous products did not implement switching between the previous and next items.
But if we continue with this idea, it will probably look like this:
Under the unfiltered search condition, send the current id as a parameter, and bring the next or previous parameters, so that you can rely on select * from foo where id = ( select min(id) from foo where id > 4)This way to query.
With filtered search conditions, this is rather disgusting. I didn’t come up with any good ideas. I probably saved the search status when clicking into the details page from the list page (this can be done, the return button saves this status) , and then when going to the previous item or next item, in addition to id and next, search conditions are also included for query. It’s just that the Ajax request API would be disgusting to write.

• Advantages: The list page is paginated, and users are not afraid of how many notifications there are.

• Disadvantages: When turning the list page, requests and queries are required. The query conditions are complex and the back-end burden is heavy. An ajax request for the next hop on the details page will be more difficult to write.

At present, there are only two ideas, each with its own advantages and disadvantages.

Do you have any other ideas?

Reply content:

I want to make a notification component, based on MVVM, and all data will be in json. The list page has filtering and search functions. Notification details bring up the previous one and switch to the next one.

It is hoped that when there are no filtering and search conditions, the global previous item and next item can be switched directly in the details page; and when there are filter conditions or search conditions, the previous item and next item can be switched in the search result list.

Option 1:

This is the plan I came up with myself.
When the entire component is initialized, all notifications (IDs) under this user are fetched locally and recorded globally [store.list.all]. Then when the details page is clicked, the front end takes the ID of the item to be clicked as a parameter. ajax request, so that the details page has the current notification id and a list of all notification ids. In this way, the details page can easily know the id of the previous item and the id of the next item.
When there are filtering or search conditions, remember to global [store.list.filter], the method is the same as above.

• Advantages: Previous and next items will become very easy to implement, and there is no need to request data every time the list page is turned.

• Disadvantages: If the user's notification list is very long, then during initialization and search, the data that needs to be requested and recorded in [store.list] will be very large, the homepage may be very slow, and the performance will be worse. .

Option 2:

Projects of the company’s previous products.
To do paging query on the list page, each request uses page+row as parameters, and the query is performed by querying the page of row items (for example, page=3, row=10, which means querying items 31-40 ). Filtering and search functions are the same.
Previous products did not implement switching between the previous and next items.
But if we continue with this idea, it will probably look like this:
Under the unfiltered search condition, send the current id as a parameter, and bring the next or previous parameters, so that you can rely on select * from foo where id = ( select min(id) from foo where id > 4)This way to query.
With filtered search conditions, this is rather disgusting. I didn’t come up with any good ideas. I probably saved the search status when clicking into the details page from the list page (this can be done, the return button saves this status) , and then when going to the previous item or next item, in addition to id and next, search conditions are also included for query. It’s just that the Ajax request API would be disgusting to write.

• Advantages: The list page is paginated, and users are not afraid of how many notifications there are.

• Disadvantages: When turning the list page, requests and queries are required. The query conditions are complex and the back-end burden is heavy. An ajax request for the next hop on the details page will be more difficult to write.

At present, there are only two ideas, each with its own advantages and disadvantages.

Do you have any other ideas?

The fatal blow of option 1: If a user uses 100,000 notifications.

The fatal blow of option 2: Continuously increasing the complexity of query conditions will increase the storage pressure.

======

Medium solution
Read N days of data at a time (provided that the amount of N days of data is basically controllable, otherwise this solution will not be implemented).

Reliable solution
Use Elasticsearch