It would be nice to handle the transform from underscored Ruby identifier to camelized GraphQL identifier at the library-level. Something schema-level and opt-in, like:
MySchema = GraphQL::Schema.define do
camelize(true)
end
This would transform:
field :some_thing into someThing (but still call method #some_thing on the underlying object)argument :some_argument into someArgument (but still args[:some_argument] in resolve functions)For example,
field :total_count, !types.Int do
argument :include_archived, types.Boolean, default: false
resolve -> (obj, args, ctx) {
if args[:include_archived]
obj.count
else
obj.where(archived: false).count
end
}
end
would become
totalCount(includeArchived: Boolean = false)
(But the above Ruby code would still work)
Are there other identifiers that need to be transformed?
This might be implemented as an instrumenter: It could , No, that won't quite work because of input objects, which can't be redefined there.redefine the fields to have camelized names and also redefine their arguments.
We're currently migrating an existing ruby REST api to graphql, and also three existing clients that rely on underscored identifiers. We do want to migrate to CamelCase though to conform with the overall GraphQL convention, but doing so at once would havoc clients. What if we could have an option for keeping compatibility with the underscored identifiers? Maybe also adding a deprecation notice automatically.
That would be interesting, you mean to make _both_:
Is that right? Seems like a good idea!
Exactly, this way clients could gradually migrate to the CamelCase version.
Sorry for going off topic but @khamusa you could look into https://github.com/vigetlabs/olive_branch for letting the client specify the casing of the response.
(I haven't tried this with graphql)
@rmosolgo how is this progressing?.
I could really use something like this for fields and arguments.
I would really like to help out with a PR if you want me to.
@rmosolgo underscored fields with a deprecation reason not clean, how about make two schema? One is underscored with deprecation, but no camelized fields. And another is camelized.
And how is progressing?
@jgrau interesting.
@cpunion, is being developed here: https://github.com/rmosolgo/graphql-ruby/pull/555.
Although I'm not sure if it's going to make it, I think I would just settle for some refactoring to ease the develop of an external gem with this feature.
@pabloh thanks.
The class-based API described in #1037 will include this feature, keep an eye there!