Field Extensions (second try)

[rmosolgo]

Trying the same notion from #1411:

• Programmatically modify field resolution on a field-by-field basis
• Low runtime overhead
• Abstract away Promise & friends

TODO:

• add filters that can:
  • add arguments to field definition
  • intercept args before calling methods
  • modify return values
  • pass arbitrary data between before_ and after_ steps
• Migrate connections to use filters
• Migrate scope: to use filters
  • As with filters, raise when scope is used with a legacy resolver (require scope: false to opt out)
• Clean-up:
  • Rename? Is filter a good name?
  • Extract Field#to_options to a separate PR to reduce this diff refactored to use .add_field instead
  • Settle on a consistent API for registering and using filters
  • Refactor Field#with_filters to not create a giant stack trace (as in Change call_hooks to be iterative rather than recursive #1738)
• write a guide
  • Document that it's not supported for function: or legacy field:
• Make sure that promises, errors, nil and skip are all handled by the library, let's wait and see, because you might want to handle those things, I don't want to hide them all.
• Add a dedicated hook to modify the field definiton

[rmosolgo]

Wow, amazingly this seems like it might work. Still lots of clean-up to do though.

[rmosolgo]

I renamed it to FieldExtension to capture that it does more than just filtering inputs. I guess it's OK but I'm definitely open to a better name.

[jcbpl]

"Extensions" makes sense to me, it's similar to ActiveRecord's extending method. The other name that comes to mind for composing fields out of behaviors is "traits," but I think one advantage of "extensions" is that you'd sort of expect to have to pass it a module.

[atomaka]

Relay connections may are implemented as a field extension

Typo.

[rmosolgo]

oops, thanks!

[rmosolgo]

This has an odd side-effect, since connections are now implemented via class-based API, Relay::BaseConnection#arguments is now a plain Ruby hash of symbols, not a Query::Arguments instance. This means it doesn't work with strings or camelized names anymore.

It's a bit of a breakage that i wasn't expecting 😅

[rmosolgo]

This is nice, but the compatibility issue is no joke. I'm going to revert it from 1.8.x and put it in 1.9.x instead.