Hi Apollo team! Firstly, thanks for all the work you're doing with Apollo, we love using it. This is just a little request which would make consuming this library easier. 馃槃
Current Pain Point/Use-case: Trying to use apollo-client with React Native, with TypeScript.
Problem: The NodeJS type definitions conflict with the react-native definitions.
Detail: The type definition here requires NodeJS.Timer. This requires the user to install the global node type declaration (there is no other style available). To use React Native, the user has to also include the react-native typings, which turns out to be global as well. Many definitions from both of these declarations conflict, and blows up when trying to compile.
Suggestion: As the usage referenced above is the only place that uses the NodeJS type definition, I would kindly suggest that Apollo just internalises that type and uses a custom type for it. Since this is a client (non-NodeJS) library, in my opinion it doesn't make sense to depend on NodeJS definitions anyway.
I know this would be fixed by making the React Native definitions non-global, but as there isn't a module version available, this seems to be the easiest solution.
I currently workaround this by adding just the NodeJS.Timer type definition in my consuming project manually.
If there are any other solutions, please let me know, I'm open to anything.
I'd happily accept this change as a PR! I think it's a good idea to reduce dependencies on trivial stuff like that.
@frederickfogerty is this something you would be interested in working on? Sounds like it could be a pretty simple fix.
@stubailo Actually, I spent some time working on getting apollo-client 0.5.* to work with react-native 0.29 typescript based project.
Things that I had to do:
generateErrorMessage to static, because the tsc/babel combo doesn't see this.generateErrorMessage after the final transpilation.Note that some of these concerns could be mitigated by using a custom babel preset to react-native project, instead of the default one.
Just documenting it here for someone else that comes along. I'm not sure whether this is PR material, considering mine is a specific use-case.
Hi @ncthis. Did you write a fork for this? Or did you just check them in locally? I would definitely appreciate these as a PR if it wasn't too hard. I don't think react-native is too specific of a use case - we'll be using apollo with react native soon.
@frederickfogerty, I have a fork, yes.
These are the 4 commits that you're looking for:
I can't directly submit a PR because these changes will only build IF typings from react-native are present.
I'm not sure how conflicts between @types/node, @types/es6-shim from this dependency and @types/react-native could be resolved. If you have a good idea on solving that, let me know. I can probably patch ApolloError better and send a PR.
I think this is solved now.
@helfer Can you link to the commit(s) that should resolve this?
@sondremare I think we fixed this a while ago, most likely with this commit: https://github.com/apollographql/apollo-client/commit/6402b2fb3e81866687e3ffe1f7a8b234d3126614
Let me know if it's not fixed for you.
Most helpful comment
@helfer Can you link to the commit(s) that should resolve this?