remove result in favor of the key's returned by the query

[jbaxleyiii]

Discussion in #30

cc @abhiaiyer91

[jbaxleyiii]

I'm going to give this a day for people to chime in if they are interested / opposed to this change.

cc @stubailo @apollostack/community-contributors @johnthepink

[johnthepink]

👍

[abhiaiyer91]

I'm in :)

[abhiaiyer91]

Thanks! I was going to do this but thanks for going for it!

[jbaxleyiii]

@abhiaiyer91 I had some down time today 🎈

[stubailo]

I think this should be 0.2 to conform to NPM's semver handling!

[stubailo]

I think we should add a warning in the case where the query returns a property that conflicts with other things we return like refetch, error, loading. It's easy to work around with an alias, but it would be great for people to find out about the problem early!

It would be a bit weird to have a root query called error, but who knows, especially as we add more metadata.

[abhiaiyer91]

Yes we can also write some Eslint rules for Apollo Query data, and ship that tooling?

[stubailo]

Eslint rules for Apollo Query data

What would they do? We can add it here maybe: https://github.com/apollostack/eslint-plugin-graphql

Since a plugin can ship multiple rules, we can add as many as we want to that plugin.

[jbaxleyiii]

@stubailo I'll update this PR tonight 🎉

[jbaxleyiii]

@stubailo this one should be good to go. I'm good with calling it discussed and merging if you are