Suggestion: extract apollo helpers like withData into a separate repo

[thealjey]

I wish withData was a separate npm package, so that it would be easier to track updates to it.

[timneutkens]

@ads1018 cc

[thealjey]

yeah, I've seen that
that is where I am copying and pasting the code from, every time
however, it's just an example implementation, not exactly reusable, and not available as an npm package
and what if the author updates it? how am I to keep track of that?

[timneutkens]

@thealjey I meant I want Adam to check it out 👍 😄

[adamsoffer]

@thealjey I'd also like to see a next-apollo package. I've been meaning to release one, but haven't gotten around to it. @sbking had a work in progress a while back but it was never completed. https://github.com/sbking/next-apollo

One thing to think about is how configurable we'd want to make it. We had a discussion around defaults here sbking/next-apollo#1

[thealjey]

@ads1018 it seemed so unmaintained I didn't even consider using it
although, potentially it could be a very awesome tool
in my mind, in a perfect world, it would include everything by default, without even forcing you to wrap your components multiple times (I do 4 wraps most of the time, e.g withData(mutationState()(compose(graphql(query, config))(MyComponent)));); elegantly handle errors; and require no configuration or set up at all for a basic app running on localhost
but at the same time be extremely extendable, possibly with the use of plugins instead of config objects

[kolpav]

I think updating withData in all apollo examples so they look more of less the same would be enough. Having it as a separate package with plugins and what not is overkill. I also got confused that the three versions are bit different in these areas.

• try catch around await getDataFromTree
• Head.rewind()
• this condition

if (context.res && context.res.finished) {
  // When redirecting, the response is finished.
  // No point in continuing to render
  return
}

I don't fully understand the last two but I combined all of them together and it works.

[dburles]

@kolpav I think you may have answered your own question as to why it's worthwhile making it a package! Came here to +1 this. It should be a package.

[adamsoffer]

Hey folks - I finally got around to abstracting the Apollo Next integration into a separate package! You can check it out here: https://www.npmjs.com/package/next-apollo

Let me know what think and send me your feedback.

Note: Apollo Client 2.0 was released yesterday and it's not yet compatible with that version. Working on that next.

[adamsoffer]

Update: the package now supports Apollo Client 2.0