Closed dustinfarris closed 7 years ago
@mattkrick do you have any thoughts on this?
yeah, you're absolutely right! I need to dig into this & check out the easiest way to do that. I was hoping await/async would have landed sooner in browsers/node so I could just rip out the polyfill, but i suppose this is the better way in case someone is still using IE10.
That's great, I'm glad you're onboard. I wonder if swapping async/await with good 'ol promises would be ok? (albeit much uglier)
As soon as we can drop babel-runtime I have an awesome demo project to put online a la ember-cashay.
yeah, that's not a terrible idea, especially since there are only 2 of them. https://github.com/MatAtBread/fast-async is another option
@mattkrick are you working on this? If not I will take a stab at it.
Not right now, I got a work sprint that's kicking my butt at the moment. If you got a PR in mind by all means! Otherwise it may be another week or 2.
On Nov 18, 2016 12:49 PM, "Dustin Farris" notifications@github.com wrote:
@mattkrick https://github.com/mattkrick are you working on this? If not I will take a stab at it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mattkrick/cashay/issues/138#issuecomment-261638226, or mute the thread https://github.com/notifications/unsubscribe-auth/AFQjvwVnhSVvWIXmC0tvycLK6yJ_JlFqks5q_g9dgaJpZM4KnxXv .
Relying on this library can be problematic depending on the client environment. It is definitely problematic for me.
GraphQL's justification does a better job of explaining than I ever could—so I am going to quote their commit message from https://github.com/graphql/graphql-js/commit/188881b457f030ec1dff6c25458a1fbb66bc515b
Note that the above change took effect in graphql 0.6.1. (cashay currently pegs graphql 0.6.0)