Relay: Support adding multiple items to a connection

[kaychaks]

Currently each RANGE_ADD config only supports adding a single item to a connection. The server must return a single new edge, as opposed to a list of new edges.

There will be times when a mutation would take a list of objects as input and hence it would be expected that the response payload contains list of newly created edges. RANGE_ADD should check if an array of new edges and append/prepend all of them.

The alternative right now to achieve something like this is to use FIELDS_CHANGE to update the complete parent node but that might be a costly operation.

[josephsavona]

Note: edited the original post for clarity.

[ekosz]

Just came across this as well. I think the best way to support this would be to detect if edgeNode is a list and if so append that entire list. That way the outward facing API wouldn't need to change.

[wincent]

Relay 2 is going to bring with it a new mutations API that is more expressive and imperative in nature. With it, users should be able to surpass limitations like this that were intrinsic to the old declarative API.

As we are unlikely to undertake further work on the Relay 1 mutations infrastructure, I'm going to close this with a "relay 1" label. We'd still be open to PRs with enhancements for the existing API, but we're probably not going to work on them directly.

Thanks for the input folks!

[juhaelee]

@wincent is this currently achievable with Relay 2's GraphQLMutation today?

[wincent]

GraphQLMutation isn't part of the new Relay core; it's already shipped in Relay. But it doesn't have build-in support for adding multiple items to a connection at once because it still needs to integrate with the pre-existing mutation configs (and those only have basic RANGE_ADD support).

The new Relay core will come with a default connection handler that knows how to cover the same basic cases (append/prepend) as the old implementation. Nobody has built an out-of-the-box abstraction for inserting multiple items at once because we haven't needed to do so internally yet, but it is certainly possible to implement something that would meet this use case using the low-level primitives we have (we have, for example, an insertEdgeAfter function that could be called repeatedly).