Urql: Next.js usage example disables its Automatic Static Optimization

[vgrafe]

The example given here does not play well with nextjs9 automatic static optimization: when building, all pages of the project will show as server rendered. Here is the output I have when building:

❯ yarn build
yarn run v1.12.3
warning package.json: No license field
$ next build
Creating an optimized production build ...

Compiled with warnings.

./node_modules/react-ssr-prepass/dist/react-ssr-prepass.production.min.js
Module not found: Can't resolve 'styled-components' in '/Users/vgrafe/Perso/next9/node_modules/react-ssr-prepass/dist'

Warning: You have opted-out of Automatic Prerendering due to `getInitialProps` in `pages/_app`.
Read more: https://err.sh/next.js/opt-out-automatic-prerendering

Page                 Size     Files  Packages
┌ σ /                365 B        0         1
├   /_app            118 kB       0        15
├   /_document
├   /_error          8.45 kB      0         1
├ σ /about           389 B        0         1
├ σ /api/users
├ σ /api/users/[id]
├ σ /firebase        35.5 kB      1         7
├ σ /urql            52.3 kB      0         6
├ σ /users           841 B        0         2
└ σ /users/[id]      970 B        0         2

σ  (Server)       page will be server rendered (i.e. getInitialProps)
⚡  (Static File)  page was prerendered as static HTML

✨  Done in 6.00s.

Well now I see it, the warning message is pretty much on point on this. What approach can be taken to play more nicely with Automatic Static Optimization?

[lukasluecke]

I don't think it's possible to have static pages and SSRed queries together - if you have some pages that use GraphQL and others that don't, you could maybe modify the individual pages instead of _app.js?

[kitten]

I personally haven't explored this much yet, so it's hard for me to judge what we could do here to improve the situation. You can definitely selectively add the higher-order component wrapper around individual pages, and slightly modify it to your needs.

cc @timneutkens: Is there any short-term recommendation how to improve this process potentially? There's obviously also the possibility of introducing static queries, like with Gatsby, where data never updates but is fetched during the build, and dynamic queries which are what we support right now. Any way to make this process with react-ssr-prepass more seamless?

[timneutkens]

@kitten we're going to introduce some changes soon particularly focused on when you do have data fetching requirements. The automatic static optimization is aimed at optimizing completely static pages without data requirements.

Hence why your recommendation seems correct, only use the HoC on the page level when you need it. That way we know if the individual page has data fetching requirements or not.

[vgrafe]

Thank you all for your comments!

I will HoC pages that fetch data only. Looking forward to see the next improvements the team comes up with.

[vgrafe]

🤔 applying the HoC on selected pages only is not as trivial as I thought. Is it possible to have some guidance on this?

[kitten]

Yea, so if I'm not misunderstanding the render code in next-server then the getInitialProps function does not have the full "AppContainer" component with all providers, which the AMP functionality does have. So we can't prerender with react-ssr-prepass

[kitten]

@vgrafe @timneutkens I'm tempted to say, let's move this issue over to Next.js maybe? It's very much a limitation that exists in Next.js right now as it isn't possible to retrieve the full element tree generically in a page's getInitialProps function, which is a shame really, but I'm unsure of how we'll work around this in urql

[kitten]

@vgrafe I think the changes in https://github.com/FormidableLabs/urql/pull/386 will fix this issue. Not sure if you have time to verify them?

[vgrafe]

Sweet! I'll have time to test the new example this weekend, as I am still traveling until then.

[vgrafe]

@kitten, unfortunately I still observe the same behavior with the updated example, with an identical warning message after the build is done :"Warning: You have opted-out of Automatic Prerendering due to getInitialProps in pages/_app.".

[JoviDeCroock]

@vgrafe
I think for this to work you'll need to try it with: v9.0.4-canary.4 and wait for the stable release after that

[kitten]

@vgrafe but is it resolved if you apply the new higher order wrapper around individual pages?

[vgrafe]

Apologies - indeed, using the HoC on individual pages works! (pages that are not wrapped are prerendered)

[vgrafe]

Ok here's a hiccup - running next build does seem to work as expected, but when deugging using next dev, the pages using the HoC crash:

[ info ]  bundled successfully, waiting for typecheck results ...
[ wait ]  compiling ...
[ info ]  bundled successfully, waiting for typecheck results ...
[ ready ] compiled successfully - ready on http://localhost:3000
[ event ] build page: /urql
[ wait ]  compiling ...
[ warn ]  ./node_modules/react-ssr-prepass/dist/react-ssr-prepass.development.js
Module not found: Can't resolve 'styled-components' in '/Users/vgrafe/Perso/next9/node_modules/react-ssr-prepass/dist'
[ info ]  ready on http://localhost:3000
TypeError: Cannot read property 'executeQuery' of undefined
    at /Users/vgrafe/Perso/next9/node_modules/urql/dist/urql.js:839:32
    at /Users/vgrafe/Perso/next9/node_modules/urql/dist/urql.js:867:5
    at /Users/vgrafe/Perso/next9/node_modules/urql/dist/urql.js:851:26
    at useQuery (/Users/vgrafe/Perso/next9/node_modules/urql/dist/urql.js:861:4)
    at PostList (/Users/vgrafe/Perso/next9/.next/server/static/development/pages/urql.js:300:81)
    at processChild (/Users/vgrafe/Perso/next9/node_modules/react-dom/cjs/react-dom-server.node.development.js:3090:14)
    at resolve (/Users/vgrafe/Perso/next9/node_modules/react-dom/cjs/react-dom-server.node.development.js:3013:5)
    at ReactDOMServerRenderer.render (/Users/vgrafe/Perso/next9/node_modules/react-dom/cjs/react-dom-server.node.development.js:3436:22)
    at ReactDOMServerRenderer.read (/Users/vgrafe/Perso/next9/node_modules/react-dom/cjs/react-dom-server.node.development.js:3395:29)
    at renderToString (/Users/vgrafe/Perso/next9/node_modules/react-dom/cjs/react-dom-server.node.development.js:3954:27)
    at render (/Users/vgrafe/Perso/next9/node_modules/next-server/dist/server/render.js:80:16)
    at renderPage (/Users/vgrafe/Perso/next9/node_modules/next-server/dist/server/render.js:260:20)
    at /Users/vgrafe/Perso/next9/.next/server/static/development/pages/_document.js:437:17
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (/Users/vgrafe/Perso/next9/.next/server/static/development/pages/_document.js:206:24)
    at _next (/Users/vgrafe/Perso/next9/.next/server/static/development/pages/_document.js:228:9)

[JoviDeCroock]

Hmm, that would mean the client becomes undefined all of a sudden, so I THINK this bug is more on the next.JS side, not entirely sure though.

[timneutkens]

Next.js only calls getInitialProps, so it's unlikely that it's related to Next.js internals itself.

[JoviDeCroock]

Hey @timneutkens,

Thanks for the response, I’ll try to look into this then

[JoviDeCroock]

I don't know how you implemented it @vgrafe since I don't see your code but just giving a few heads up.

The error you are talking about implies that the client for urql is undefined, since the executeQuery is called on that. This is received from the context, looking at the examples in the next repo I see that they pass the apolloClient down very explicitly https://github.com/zeit/next.js/blob/1765007a10c63cbeebe74da6044b9158ff32fb85/examples/with-apollo/lib/with-apollo-client.js would it be possible that the problem is located around that?

Trying to find out where this goes wrong, it's quite odd that it behaves different in dev vs prod.

[vgrafe]

I'll have a further look.

[vgrafe]

Here is my repo. What to look for: the _app.tsxfile, in which the urql client is set in a Provider component wrapping the whole app. The current code results in the error described above when accessing the /urql page while using the local development server.

Moving the Provider/client to the urql.tsx page makes the query error with the following message:

{
  "name": "CombinedError",
  "message": "[Network] Not Found",
  "graphQLErrors": [],
  "networkError": {},
  "response": {}
}

Weirdly, looking at the network calls in devtools show an attempt to GET http://localhost:3000/graphql, resulting in a 404. Not sure where this comes from, but it seems to be what causes the error.

It looks like I am missing something obvious... sorry if that's the case!

Edit: I just pushed the wrap-page-only branch.

[vgrafe]

I've been playing a bit with the withApollo example as well, with no success. Should the hoc need some tweaking in order to be usable with components (instead of used at the root level in the example)?

[youfoundron]

Also not able to get the Next.js example working. Anyone have a repo with a working setup?

[vgrafe]

Looks like the apollo example was updated. I just cloned and tested, build works as intended and pre-renders non-connected pages.

I don't have much time to adapt the example to urql yet, but will post here in the future if no ones do it before me.

edit: another apollo example, api-routes, is now optimized as expected too.

[youfoundron]

@vgrafe appreciate the work you do man, thank you very much

[JoviDeCroock]

Hey @vgrafe I've solved it in https://github.com/FormidableLabs/urql/pull/421 thanks for the information you've been providing it has been a big help!

[vgrafe]

Of course, thank you for working on this so promptly! Can the example be updated as part of the PR?

[JoviDeCroock]

@vgrafe what would you like to see updated? Normally it introduces the needed fixes

EDIT: do you mean with promisified requests?

[vgrafe]

Oh, my bad. I thought changes would be introduced that would need to edit the example.