-
Notifications
You must be signed in to change notification settings - Fork 121
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
Immutable type builders #110
Conversation
I've updated |
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.
Doing variables
typing right is tough without optional generic types. I think the best option is to just make variables
a generic type (thus dynamic
by default, for now). Seems the most forward looking, as eventually dart will let us make the type arg Map<String, dynamic>
. We could provide some static method to construct the current default without a type arg also.
Another option is to rework the gql_exec
Request
inheritance chain, adding a base generic interface with something like an asExecutable
getter for execution time. Feels awkward and invasive though.
The . I wonder how easily it'd be to an editor plugin that dims/styles the G
prefix doesn't solve everything, but I think it's fineG
.
This was a bit of an issue for me while trying to model union types: google/built_value.dart#831
Thanks for the feedback. I'll defer to @klavs here, but setting variables to
Love the editor plugin idea. What are some cases that the |
Nevermind, I'm wrong. I was thinking |
Yes, that's right |
Sorry for my late response.
I'm open to dropping the prefix and letting users use import prefixes if they choose so.
Could you explain the potential confusion here?
Another hard one. Context may have both useful and useless information. (Or critical and nice-to-have information). I tend to think that Context should not be serializable because it kind-of contains the current state of request execution. It might be a fundamental design flaw in the
I would love to avoid Again, sorry for the late response. I'll try to review the changes by the end of the week. |
Thanks @klavs
We'll need to do some sort of transformation to bypass the lowercase letter limitation. If we simply capitalize all classes, we could have collisions since
If we have both a
I'll think more about this. In However, the
That's fine. I think this is the right call. We can simply leave it to the client to convert the |
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.
I think I would prefer not having the G
prefix, but I see how it makes sense (considering __typename
).
I think this PR is in pretty good shape. We now have the following working:
I've added a number of tests to the Custom scalars require some additional config in the
As an example, here's the targets:
$default:
builders:
gql_build|ast_builder:
enabled: true
gql_build|req_builder:
enabled: true
options:
schema: end_to_end_test|lib/graphql/schema.graphql
gql_build|serializer_builder:
enabled: true
options:
schema: end_to_end_test|lib/graphql/schema.graphql
custom_serializers:
- import: 'package:end_to_end_test/date_serializer.dart'
name: DateSerializer
gql_build|schema_builder:
enabled: true
options:
type_overrides:
Date:
name: DateTime
gql_build|data_builder:
enabled: true
options:
schema: end_to_end_test|lib/graphql/schema.graphql
type_overrides:
Date:
name: DateTime
gql_build|var_builder:
enabled: true
options:
schema: end_to_end_test|lib/graphql/schema.graphql
type_overrides:
Date:
name: DateTime
As you can see, we are repeating the @klavs @micimize Thanks for your feedback. Please let me know if there's anything else before this gets merged. |
It seems the CI is failing due to inconsistencies in import order in the generated files between builds. @klavs do we need the git diff check? |
I'm going to go ahead and merge this since I haven't heard back in a while. |
This PR adds support for building data, var, and schema types as
built_value
immutable data types.Some improvements as a result of this change include:
A few notes:
Prefixes
built_value
does not allow types to start with$
or start with a lowercase letter (without breaking serialization). Therefore, I've decided to prefix all generated types with "G" (which could stand for "Generated" or "GraphQL").Serialization
built_value
's serialization paradigm works by aggregating all serializers into a single global object. I've added an aggregatingserializer_builder
that collects all the serializers from each built class.By design,
built_value
's serialization does not support multiple types with the same name since types are serialized by type name. Therefore, in order to avoid collisions, I've added a "Data" suffix to generated data types and a "Vars" suffix to generated variable types. Data and variable objects for "MyQuery" are therefore built as "GMyQueryData" and "GMyQueryVars", respectively.code_builder
limitationsThecode_builder
library does not include the ability to specifypart
directives and is missing some important operators. I've submitted PRs to fill these gaps, and in the meantime, I've added a dependency override oncode_builder
that points to my PR.dart-lang/code_builder#277
dart-lang/code_builder#269
Edit: the above PRs have been merged.
req_builder
I've laid the groundwork for updating the req_builder to also use
built_value
. I don't think it's necessary to usebuilt_value
forop_builder
orast_builder
.built_value
already plays nice with objects that are immutable, and override "==" and "hashCode" (which DocumentNode and Operation already do). Instead, I've simply added a custombuilt_value
serializer that serializes Operations by printing / parsing the DocumentNode.However, since
req_builder
extendsRequest
fromgql_exec
, there are two issues that I'd like feedback on:variables
property onRequest
provides a Map<String, dynamic>, but ideallyvariables
would reference the built vars object, allowing us to do something like the following:We could save the built vars object to another property (e.g.
builtVars
) and implement thevariables
prop as a getter that runsbuiltVars.toJson()
, but this could be confusing to the developer. Thoughts?Context
on requests?