-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Optionally underscore _Any keys #248
Conversation
@jturkel Thanks for the PR. This could lead to a big migration for large projects. Is there any way we could make this adoptable on a per-entity basis? |
@grxy - That's a fair concern. What about an class User < BaseObject
underscore_reference_keys true
def self.resolve_reference(reference, context)
USERS.find { |user| user[:my_id] == reference[:my_id] }
end
end This would also allow applications to opt into this behavior for all entities via a class BaseObject < GraphQL::Schema::Object
include ApolloFederation::Object
field_class BaseField
underscore_reference_keys true
end |
@jturkel I think that approach makes a lot more sense since it allows both incremental and all-at-once adoption. We can talk about it in the future, but we can probably make that behavior the default in a future major release, for consistency with GraphQL Ruby. |
@grxy - I switched to using a per-entity setting. Let me know what you think. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems almost there. Have a suggestion for documentation, a small implementation detail change, and an additional test request.
# [3.8.0](v3.7.1...v3.8.0) (2023-06-02) ### Features * optionally underscore _Any keys ([#248](#248)) ([f1688e7](f1688e7))
🎉 This PR is included in version 3.8.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
In a previous Pull Request (Gusto#248) there was added support for underscoring the keys and while this covered the `Object` class, it didn't also cover the `Interface` module. This commit adds the same `underscore_reference_keys` method to the `Interface` module.
In a previous Pull Request (Gusto#248) there was added support for underscoring the keys and while this covered the `Object` class, it didn't also cover the `Interface` module. This commit adds the same `underscore_reference_keys` method to the `Interface` module.
In a previous Pull Request (Gusto#248) there was added support for underscoring the keys and while this covered the `Object` class, it didn't also cover the `Interface` module. This commit adds the same `underscore_reference_keys` method to the `Interface` module.
In a previous Pull Request (Gusto#248) there was added support for underscoring the keys and while this covered the `Object` class, it didn't also cover the `Interface` module. This commit adds the same `underscore_reference_keys` method to the `Interface` module.
In a previous Pull Request (Gusto#248) there was added support for underscoring the keys and while this covered the `Object` class, it didn't also cover the `Interface` module. This commit adds the same `underscore_reference_keys` method to the `Interface` module.
* Optionally underscore _Any keys. * Switch to per-entity setting * Apply feedback
# [3.8.0](Gusto/apollo-federation-ruby@v3.7.1...v3.8.0) (2023-06-02) ### Features * optionally underscore _Any keys ([Gusto#248](Gusto#248)) ([f1688e7](Gusto@f1688e7))
This PR adds optional support to underscore the keys in the
_Any
scalar for consistency with thefields
argument of theApolloFederation::Object.key
method and graphql-ruby's general conversion from camelcase to snakecase. I disabled this by default for backwards compatibility but it should probably be enabled by default in the next major release.