feature request: support calling prepareReactRender client-side

[zenflow]

Using Next.js's getInitalProps can offer us some advantages over using getServerSideProps:

• Solves SSR: Cache data not persisted across client-side navigation #167 since it is called client-side for client-side navigations
• Makes it possible to pass the request-scoped (i.e. authenticated) client to the component a prop on SSR, since props can be non-json-serializable values. This way we don't need to create 2 clients server-side (one for prepass, one for final render) and the cacheSnapshot doesn't need to be deserialized for the final server-side render.

But it looks like the prepareReactRender function is not meant to be called client-side? I noticed some strange behavior when calling prepareReactRender client-side in my getInitialProps.

In my demo, if you go to the films page, open the network tab in chrome devtools, and then navigate to the planets page, you will see that once the "planets" query request completes, the page navigation happens, and the previous page's query ("films") is requested again. I think this has to do with the fact that prepareReactRender clears the client's cache before doing it's thing (behavior identified #165), but I'm not 100%. I know that useHydrateCache has nothing to do with it because I can remove that call and the described behavior (of client-side navigation) remains.

[PabloSzx]

I don't think we should be using getInitialProps, it is there in apollo from legacy, from before getServerSideProps and getStaticProps existed.

But it looks like the prepareReactRender function is not meant to be called client-side? I noticed some strange behavior when calling prepareReactRender client-side in my getInitialProps.

Exactly, it's not mean to be client-side, but maybe the strange behavior you saw is from the bad decision I made when I created "prepareRender" of overwriting the cache instead of simply merging it. It's important to also note that executing that code client-side you are shipping ton of code to the browser that doesn't actually need it at all.

---

The only good think about using getInitialProps is being able to keep the routing logic without those hacky tips I added in the docs, and maybe it could be good for those specific use-cases, but we also have to remember that gqless-react is not meant to be Next.js exclusive at all, and the current design is framework-agnostic.

[PabloSzx]

If you want make some ready-to-use code around the existing code (after #169 is merged), for specific Next.js getInitialProps use, you are very welcome, and we could add it in a specific Next.js page in the docs.

---

PS: In client side navigation gqless should work as normal, you shouldn't need to do any preparation through getInitialProps