Update mergeSchemas and delegation API, plus Schema Transfroms

[freiksenet]

This adds new API for delegation, that includes GraphQL Transforms.

[stubailo]

Todo:

• Add test for calling delegateToSchema directly
• Add a nice error for when the wrong number of arguments is passed, since that means people probably forgot to pass in the name of the schema
• Documentation and blog post about transforms

[stubailo]

Let's call this ANY_TYPE

[stubailo]

We could make this more general and also work for namespacing if this took a function instead of an object:

(type) => ({
  oldName: 'newName'
}[type])

(type) => ('NameSpace' + type)

[stubailo]

Proposed list of transforms:

1. Rename types
2. Rename fields
3. Select types/fields (opt-in)
4. (maybe) remove types/fields (opt-out)

[sync]

Can confirm that the problem with fragment into fragment we were experiencing is now fixed. Thank you once more.

[freiksenet]

Let's merge it folks @benjamn @stubailo

[martijnwalraven]

This is great, happy to see we're getting close to a release! I know I haven't really been involved with this, so I'm a bit late to the party, but some questions that came up while looking at this:

• Why do we export the built-in transforms under a Transforms object, instead of having people import them individually? Apart from the unusual capitalization, I feel it may draw too much of a distinction between built-in and custom transforms.
• Since we're changing the API anyway here, would it make sense to try and come up with a better name than mergeInfo that we can also use to put additional utility methods on (like accessing a schema by name)? Maybe just utils or tools?

[freiksenet]

@martijnwalraven I'll change the transforms export. Our API is backwards compatible, so I think we are stuck with mergeInfo, I don't think it's worth a rename, esp if we have to keep compatability layer.

[martijnwalraven]

Oh, I thought we were changing the API from a mergeInfo closure argument to mergeInfo on info. I don't want to bikeshed this too much, but I'm afraid mergeInfo doesn't cover what we want to use this for so if we have an opportunity to fix it I think we should do that.

We'll probably want to add a resolveSchema method for instance, that resolves a schema by name. It seems weird for that to live on mergeInfo. What do you think of alternative names? I think something like tools or stitching makes the most sense to me.

[freiksenet]

Moved transform export to top level. Also added two transforms that a) were reported by users b) I needed for my blog post (:D)

[benjamn]

Note: I changed this code so that it now handles arrays as well as any other kind of object, preserving the original prototype. I think it's important to transform arrays as well as objects here, since you could have objects nested inside array results that need their __typenames to be updated.

[benjamn]

I like this new style a lot better, thanks!

[benjamn]

I forgot to submit a comment from a couple weeks ago (sorry), and this code has changed a bit since then, but I think the question is still relevant: is // apply result processing ??? an important TODO?