I am not seeing how plays into this. We can do essentially the same thing using transitionToParams – see https://github.com/folio-org/stripes-components/blob/master/util/README.md#thistransitiontoparamsparams

On keeping old results around or not: that surely is a matter for optimisation, and we may well want to tune it on an app-by-app basis. So we need to design this so that it works fine whether or not we retain old results. We should be fine so long as our metadata cleanly describes what we do and don't have, and is kept up to date. As you say, we need to avoid having to make assumptions.

Good spot on the re-rendering. However, avoiding that can be seen as a separate optimisation task. In practice it's likely to be pretty cheap, so we shouldn't let the main task be derailed by becoming over-conscious of this refinement.

The general approach sounds good to me.

(And, yes, we really do need to get rid of redux-crud.)

So, turns out paging is more involved than it might appear:

• To add these parameters cleanly it would be really good to do , especially if we're comfortable requiring that paramters be split out.

• It's tempting to want to keep the first page of results when pagedRecordsRequested is increased. After all, it's typically just that the user is moving on to the next page. However, we (will) have it cached and should instead react to this as with any other change to the manifest and start over again. This saves having to make assumptions about whatever happens to be in the state and needing to verify that nothing else salient changed.

• We want to avoid re-rendering the component as each page comes in (which will happen if we put them directly in their ultimately home in the store).

• Order matters. My first inkling was to do them in sequence for now but ultimately we want to be able to fire off all the requests.

• It will be surprising if I don't somehow trip over redux-crud again trying to implement this.

Thought I could do something quick to handle this in the interim with a chain of promises but that rapidly became fiddly and involved hanging more state off of the resource object than I was comfortable with. So instead I'm looking at adding some extra Redux actions/reducers to handle satisfying all the pages and then dispatching redux-crud's success action at the end. Someone even wrote up a handy guide and associated module but given how long redux-crud has outlived its welcome (STRIPES-239) I think I'll just do a modest implementation of it and improve as needed rather than tow another dependency along for this.

Also: the first two thirds of that linked post is good: everything it says is obvious, but it's good to have it all laid out in one place. (The last third is eminently disposable, all about Relay.)

Jason's analysis seems spot on to me, especially his rejection of a fetchMore method.

I am happy to relegate cursors to an indefinite future that may or may not ever happen.

Side-comment on the definition of "pageable": I wonder why the minimum value of limit is 1? I can easily imagine wanting to set it to zero, to get a "pure search" with no retrieval – for example, if I want to determine how many of thing there are, without at that point caring what those individual things are.