[Ember Data] Improve findHasMany/findBelongsTo decision making

[mydea]

Rendered

This is based on #356 & emberjs/data#5574 (comment).

[runspired]

The approach here to resolving #356 is predicated on resolving several current implementation details, and would require leaking parts of private APIs we are seeking to eliminate. Furthermore, the approach entangles the concerns of the adapter, relationship and store. We are currently working to separate, simplify and clearly delineate the boundaries and concerns of these primitives, and do not wish to add unnecessary wiring between them.

For these reasons, I think we should refactor this to pursue an approach based on unifying these requests at the adapter level.

Here's a quick overview of the primitives in play and their current responsibilities:

• RelationshipState: stores information about connections resources
• RecordData: stores information about a single resource
• IdentityMap: caches resources by keys
• Store: Manages the IdentityMap and initiates requests to the adapter for data not in the map yet.
• Adapter: Manages fulfillment of a request for data.

Ideally in the future the IdentityMap duties of the store will be agnostic to the "initiating requests" duties. This is a bit more clear if you consider that an adapter might decide to fulfill a request from cache (local storage, indexdb, in-memory, etc.). E.g. for this RFC, consider the perspective that in the future, the responsibility of fulfilling a request for data, even when from cache, will always be the adapter (or more likely something that we build to replace the adapter). In other words, the role of the adapter is to manage the fulfillment of requests for data.

E.g. in the future a query for data (which may be a query for a relationship) would have the following flow, in which the cache is one of many potential sources and the adapter is responsible for assembling the list of resources to give back to the store that fulfill the query for data:

Store ⇄ Adapter ⇄  Source(s)

Here's what the API surface area for a request object that might make this simple could look like:

interface RelationshipRequest {
  // derived from previous API responses
  links: Object|null;
  meta: Object|null;
  data: Object|Array|null;

  // derived from local schema info
  definition: Object|null;
  parentRecordData: RecordData;

  // request specific
  options: Object|null;

  // the state we are in, derived from the nature and result of various previous requests
  relationshipState: RelationshipState;
}

And here is what this might look like from an API perspective:

// internal method when you call `record.get('relationshipName')
//    or record.belongsTo('relationshipName').re/load(options)`
Relationship.getData(options): Array<Record>
  => RecordData.findBelongsTo(relationshipRequest): Collection (internal primitive)
    => Store.findBelongsTo(relationshipRequest): Collection (internal primitive)
      => Adapter.findBelongsTo(relationshipRequest): JsonApiDocument

[runspired]

@mydea for the thing I am proposing above, yes, this means that coalescing would need to be an adapter level concern for this to continue working with coalesceFindRequests. That is it's own RFC; however, we may want to RFC some overall improvements to the adapter layer in parallel.

[mydea]

So how would you propose that we proceed here? I generally agree with everything you wrote - these things make a lot of sense to me. Still, I feel like it would be great to have a way to do this in the meanwhile - as I guess all of these changes will be a certain time off, and it would be really great to have a way to handle this as soon as possible.

Maybe, as a compromise, we could follow one of the alternatives I lined out in the meanwhile, splitting up _findHasManyByJsonApiResource/_findBelongsToByJsonApiResource into other (private) functions, that at least make it possible to overwrite the current behavior. E.g. put a private _shouldFindViaLink() method on the store, which is used by both of these functions?

[rwjblue]

Some discussion around this went on in a recent ember-data team meeting, @runspired do you happen to recall the specifics?

[runspired]

After further discussion OOB with @mydea we're going to accomplish this a different way. A new approach is being drafted to move coalescing into the adapter, which will support multiple efforts to disentangle our primitives in addition to making it easier to accomplish the original intent of this RFC which is to make all relationship requests use the same adapter entry points.

[ctcpip]

@runspired is the new approach being tracked somewhere as of yet?