-
Notifications
You must be signed in to change notification settings - Fork 10
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
Union type check #41
Union type check #41
Conversation
Cool. Thanks for adding this! I think it needs a test, though. Can you add one that will only pass with your code changes? |
@@ -22,6 +22,14 @@ export const ensureList = (item) => item == null | |||
|
|||
export const getFirstKey = (obj) => Object.keys(obj)[0]; | |||
|
|||
export const getUnionField = (type, fieldName) => { | |||
for (const t of type._types) { | |||
if (t._fields[fieldName]) { |
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 might be an edge case, but would there be an issue if multiple types had the same fieldName
but the fields were different types?
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.
That would be an issue but addressing it seems like a much larger piece of work that can potentially come later.
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.
Yes, this would be an issue. I feel the appropriate thing would be to add full UnionType functionality at that point, where this is a simple fix that allows us to add UnionTypes and use mapping to accomplish it
Parts of the build matrix are failing. I’ll dig in tomorrow and try to figure out why. |
I'll try to help when I get a chance. I want to get this merged and
released as soon as I can.
|
miwialex#4 ← hoping this will get the tests green across the matrix |
@jneurock this PR is in a bit of an awkward spot.
I’d encourage us to adopt the same supported range as ember-apollo-client (rather than the full LTS range), but totally open to discussion. |
@jgwhite, without giving a ton of thought, I'd lean the same way regarding supported Ember versions. This addon should be GraphQL client agnostic, though. I'll have to think about it a little more but my first thought is to release these changes with a |
I highly suspect nobody will be in this position. I think cutting a |
@jneurock what do you think about cutting an 0.3.0 this week? |
I'm happy to release ASAP. Is there still an issue with the build passing? |
The build is passing for the proposed new support range or Ember >= 3.4 |
I see. The Ember Try setup can be changed in this pull request.
|
Yeah, the PR does tweak the ember try config but maybe there’s some Travis tweaking still needed |
add check for union type to properly get field type
af8ff06
to
fe175bc
Compare
This commit is, I’ll confess, controversial. However, ember-apollo-client only supports Ember >= 3.4 and it makes our lives *much* easier to follow suit, and to take that even further and follow ember-cli’s recommendation to only test the last two LTS releases. The real source of the 3.4 minimum is ember-native-class-polyfill which ember-apollo-client now requires Ember < 3.6. As per [the ember-apollo-client 2.0.0 release notes][1]: > If you are using Ember versions 3.4 or 3.5 you must add > ember-native-class-polyfill to your application. [1]: https://github.com/ember-graphql/ember-apollo-client/releases/tag/v2.0.0
fe175bc
to
7e75372
Compare
@jneurock this is green now. I faffed around with the ember-try config a bunch and ended up just using exactly what’s in the current ember-cli addon blueprint (the last two LTS releases). I think we should still support back to 3.4 (as discussed) but this seemed like a stable starting point. |
Cool. Thanks! At one point I tried and failed to update dependencies a
while back. Everything worked locally but 3.4 failed in Travis and I felt
too close to madness to continue. I'll think a little bit on the support
topic and how to appropriately update the README but I think it could be
fine to release a new version that works with these changes.
|
@jneurock let us know what you’re thinking with this and if there’s any way we can help out with the release process. |
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.
What's this about? Just curious.
@jgwhite I was looking into running more tests with older Ember versions but I think it doesn't matter that much. This is really about the dummy app in the addon and not the versions of Ember that are supported. I had a couple of questions about some of the file changes but other than that, this is ready to go. Maybe after a little explanation of some changes I'll quickly release 0.3.0 as we discussed and update the README a bit. Where I could probably use some help is documenting how someone would go about using this addon with union types in the README. Any help there would be appreciated. I have no real world union type experience to help me there. Thanks! |
Currently in the
getFieldType
function, the only check that happens is to see if the field is__typename
and then returns null. Otherwise it automatically looks for the field undertype._fields
which isn't going to be there for the typeGraphQLUnionType
. I added a check for this, and then added some logic to find the appropriate field for theGraphQLUnionType
. Note: This does not add full support for the union types yet, but I was able to write a customfieldsMap
to resolve my union type to support my needs currently. This should unblock people for now to be able to use union types