Skip to content
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

Merged
merged 10 commits into from
Feb 26, 2020
Merged

Union type check #41

merged 10 commits into from
Feb 26, 2020

Conversation

miwialex
Copy link
Contributor

@miwialex miwialex commented Feb 5, 2020

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 under type._fields which isn't going to be there for the type GraphQLUnionType. I added a check for this, and then added some logic to find the appropriate field for the GraphQLUnionType. Note: This does not add full support for the union types yet, but I was able to write a custom fieldsMap to resolve my union type to support my needs currently. This should unblock people for now to be able to use union types

@jneurock
Copy link
Contributor

jneurock commented Feb 5, 2020

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]) {
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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

@miwialex
Copy link
Contributor Author

Cool. Thanks for adding this! I think it needs a test, though. Can you add one that will only pass with your code changes?

@jneurock @jgwhite was nice enough to add some tests :)

@jgwhite
Copy link
Contributor

jgwhite commented Feb 12, 2020

Parts of the build matrix are failing. I’ll dig in tomorrow and try to figure out why.

@jneurock
Copy link
Contributor

jneurock commented Feb 12, 2020 via email

@jgwhite
Copy link
Contributor

jgwhite commented Feb 13, 2020

miwialex#4 ← hoping this will get the tests green across the matrix

@jgwhite
Copy link
Contributor

jgwhite commented Feb 13, 2020

Screen Shot 2020-02-13 at 17 21 50

argghh

@jgwhite
Copy link
Contributor

jgwhite commented Feb 14, 2020

@jneurock this PR is in a bit of an awkward spot.

  • For the acceptance test of union type handling, we need to subclass ember-apollo-client’s apollo service in the dummy app.
  • To do this, we need to install ember-native-class-polyfill.
  • The polyfill only supports Ember >= 3.4.
  • Because of this, ember-apollo-client >= 2.0.0 only supports ember >= 3.4.

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.

@jneurock
Copy link
Contributor

@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 0.3.0 version of the addon and update the README to add a note about this stuff. IDK how many people are using this addon with pre-3.0 Ember, if anyone at all.

@jgwhite
Copy link
Contributor

jgwhite commented Feb 14, 2020

IDK how many people are using this addon with pre-3.0 Ember, if anyone at all.

I highly suspect nobody will be in this position.

I think cutting a 0.3.0 is the right approach. And we wouldn’t have to prevent the addon working with older Ember versions, just say that we don’t officially support anything < 3.4.0.

@jgwhite
Copy link
Contributor

jgwhite commented Feb 18, 2020

@jneurock what do you think about cutting an 0.3.0 this week?

@jneurock
Copy link
Contributor

I'm happy to release ASAP. Is there still an issue with the build passing?

@jgwhite
Copy link
Contributor

jgwhite commented Feb 18, 2020

Is there still an issue with the build passing?

The build is passing for the proposed new support range or Ember >= 3.4

@jneurock
Copy link
Contributor

jneurock commented Feb 18, 2020 via email

@jgwhite
Copy link
Contributor

jgwhite commented Feb 18, 2020

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

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
@jgwhite
Copy link
Contributor

jgwhite commented Feb 19, 2020

@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.

@jneurock
Copy link
Contributor

jneurock commented Feb 19, 2020 via email

@jgwhite
Copy link
Contributor

jgwhite commented Feb 25, 2020

@jneurock let us know what you’re thinking with this and if there’s any way we can help out with the release process.

Copy link
Contributor

@jneurock jneurock left a 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.

@jneurock
Copy link
Contributor

@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!

@jneurock jneurock merged commit 4f811c2 into kloeckner-i:master Feb 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants