Another issue with separate resolvers is that because the data module memoizes per function, calling getTerms( 'category' ) and getCategories() will cause two network requests, despite being for the same resource.

To your previous point, maybe this is where we ought to go through the select API to resolve terms for the getCategories resolver. This would also mean we'd probably not need (or want, in order to avoid this scenario) to provide state as an argument of the resolver.

One other option, which could also help address another issue I'm encountering†, is to introduce the isFulfilled function discussed in #5219.

Previously we considered it being an object. I'm wondering also if it could just be a property of the resolver function.

export async function* getTerms( state, taxonomy ) {
	yield setRequested( 'terms', taxonomy );
	const restBase = getTaxonomyRESTBase( taxonomy );
	const terms = await apiRequest( { path: '/wp/v2/' + restBase } );
	yield receiveTerms( taxonomy, terms );
}

getTerms.isFulfilled = ( state, taxonomy ) => {
	// return hasRequestedTerms( state, taxonomy );
	return state.terms[ taxonomy ] !== undefined;
};

† I'm trying to refactor the HierarchicalTermsSelector component to query from core data. To do this, I'm inclined to add a new optional options argument to the selector for things like perPage, orderBy, etc. However, this is an issue for memoization, since getTerms( 'category', { perPage: 100 } ) will never memoize (the arguments are compared by reference, and here we create a new object each time). There are various ways we could solve this (constant reference to the query object, memoize on arguments deeply), but the above function could work and avoids imposing any considerations on the consuming developer.

Even if this was implemented another way (e.g. separate selector like getCommonlyUsedTerms), it seems inevitable that eventually someone will create a selector accepting an object which would fail to cache its having been resolved.

Or, if the resolver has access to state, it can simply abort itself if no action is necessary.

I'd love if we avoid the isFulfilled API but at the same time I don't see how would you solve the issue even with state access (when the query is in flight) unless you memoize by deeply comparison.

Maybe it could be optional, if provided use it, if not use memoization

I don't see how would you solve the issue even with state access (when the query is in flight)

Since we synchronously yield setRequested in the terms resolver, all subsequent resolutions should have awareness that the request has been made, even if a request is currently in flight.

This is the idea anyways. I'm having trouble with this in practice, where each call to getTerms has empty requests state. Thinking there might be something off with yielding / resolution occurring in expected order.

It appears to be that since the asynchronous iterator of registerResolvers operates effectively as an array of promises, and since promises don't execute until after the current call stack, both calls to the resolver trigger the setRequested before either has a chance to dispatch to the store.

Related:

• https://medium.com/netscape/async-iterators-these-promises-are-killing-my-performance-4767df03d85b#997c
• https://promisesaplus.com/#point-34

@aduth Funny, that's exactly why I created rungen in the first place. redux-saga was using promises initially and I wanted to use callbacks so synchronous effects are run synchronously :). So I believe it's doable.

So I believe it's doable.

Is it a simple change? Or are we talking introduction of wrapping functions and custom vocabulary?

Since we're not supporting a lot of yieldable values, I believe it should be simple. I haven't looked in detail to the way you implemented the engine behind the generators syntax but I don't think it's a complex task, just replace the promise usage, using simple callbacks (success, error)

@aduth

Here's the whole rungen engine implementation https://github.com/youknowriad/rungen/blob/master/src/create.js#L4-L36

We could use exactly the same implementation and just replace the controls array here https://github.com/youknowriad/rungen/blob/master/src/create.js#L5 with an array containing only our action control.

A control is basically the behavior saying if we have this kind of yielded value, do this behavior and return this value (See the readme of rungen to undersand better).

We only support one unique control in wp.data the action control.

@aduth @youknowriad Is this PR still relevant?

Yes, this still has value, but needs to be brought up to date.

Specifically, we can leverage the isFulfilled API which has since been added (#6084) and enhanced with deep arguments memoization (#6360) as mentioned here previously in #5826 (comment) and #5826 (comment).

At least this can serve as an adequate solution for our needs here. The complexities of handling asynchronous dispatching may still warrant more investigation separately.

I believe this is no longer required with the more recent entities implementation (#6939).