ProtectedinitialProtectedloadingProtectedloadingProtectedloadingProtectedlocationProtectedpagesProtectedparamsProtectedrevalidatingStaticDEFAULT_This value should not be relied upon when preloading an API document.
In those cases the pageSize should be taken from the meta information of the preloaded
document. Checkout DiscussionListState.loadPage for an example.
Delete all of the notifications for this user.
ProtectedgetProtectedgetStored state parameters.
ProtectedgetIn the last request, has the user searched for a model?
Load the next page of notification results.
ProtectedloadLoad a new page of results.
Mark all of the notifications as read.
ProtectedmutateProtectedparamsProtectedparseUpdate the this.params object, calling refresh if they have changed.
Use requestParams for converting this.params into API parameters
Protected AbstractrequestGet the parameters that should be passed in the API request. Do not include page offset unless subclass overrides loadPage.
Reload the first page without taking the current results off screen.
refresh() clears the list and shows the loading state before it asks the
API for anything, which is what you want when the reader has changed what
they are looking at: the old results are wrong, and showing them would be a
lie. It is the wrong shape for a background catch-up — a reconnected
websocket, a regained network — where what is on screen is still valid and
merely out of date. There, clearing first means the reader watches content
they already had disappear behind a spinner, and loses their scroll
position, to service a request they never made.
This keeps the list rendered and swaps the results in when they arrive. A failure resolves rather than rejecting: a background refresh that could not complete should leave the reader exactly as they were, not blank the page.
The in-flight background refresh, if any. Deliberately not part of the
isLoading()family: a revalidation is invisible by design, so exposing it there would put the loading state back on screen.