Defaults?

[adamsoffer]

Totally dig this approach! I’m wondering, is it worth providing some defaults (with the option to override those defaults) for those developers who might want to get going with Apollo and Next right away? Removing the requirement of creating 3 new files (initClient, initStore, and apolloFactory) after installing the package would reduce "scaffolding friction". It'd be cool if all a developer had to provide was a graphql endpoint to the library to get started, while still providing the option to override those individual files.

What do you think?

[sbking]

@ads1018 I agree with including defaults, so the user can just wrap their component in the HOC without adding anything else special.

This new version of the package changes the approach so that rather than creating a confusing factory function, you add some combination of static methods on your component (getInitialProps, getApolloClient, and getReduxStore). Obviously these can and should be turned into a super component or a HOC by the user so they can be shared on multiple pages. See https://github.com/sbking/next-apollo-example/blob/using-npm-package/pages/index.js

The getInitialProps and getReduxStore static methods are optional as of now. It would be easy to make the getApolloStore method optional as well, perhaps by using an apolloUri prop or something on the component.

When I first started working on this, I found that I was trying to extract out every little configuration you can make into settings passed to the HOC. I'm all for creating some reasonable defaults for getting started with minimal configuration, but I think the approach should generally encourage the user to use the native APIs for production code, in which they should be writing essentially the same apollo / redux code that they would be writing in any other framework, while this package handles the stuff that is specific to next.js.

[adamsoffer]

This new version of the package changes the approach so that rather than creating a confusing factory function, you add some combination of static methods on your component (getInitialProps, getApolloClient, and getReduxStore). Obviously these can and should be turned into a super component or a HOC by the user so they can be shared on multiple pages. See https://github.com/sbking/next-apollo-example/blob/using-npm-package/pages/index.js

I'm not sure I completely follow. In your example, it seems you would have to include those static methods on every page you want to fetch data. As well as the configuration files initClient and initStore. Is that correct? Or are you saying that example file should be a HOC that lives inside a user's lib directory?

I'm all for creating some reasonable defaults for getting started with minimal configuration, but I think the approach should generally encourage the user to use the native APIs for production code, in which they should be writing essentially the same apollo / redux code that they would be writing in any other framework, while this package handles the stuff that is specific to next.js.

Agreed.