3 ms·

I can comment on personal experience with this. I've been building a new application using next.js and its new `app` directory setup. First, it is hard to reas

I can comment on personal experience with this. I've been building a new application using next.js and its new `app` directory setup. First, it is hard to reason about what is happening where (server or client). If you want to know then you have to investigate and most of the time when I'm cranking out code I don't pay too much attention. As he mentions, it is really easy to make a small change and then all of a sudden some large part of your page wants to move from server to client. I know I'll have to do a careful and time consuming page-by-page verification before I finally ship - and that sucks. Second, many existing React libraries are assumed to run on client because they use hooks. This can drag code onto the client. The whole point of fighting with this new paradigm is that you get server-side rendering which means fast load times and SEO. That is totally wasted if a library you are pulling in refuses to play nice. Third, there are bugs in the new next.js app directory paradigm. It is still new and it is very complex. Things like dynamic routes and parallel routes and their interactions can just completely break. I've personally filed an issue on next.js github that gained a bunch of "me too" comments. One approach I was taking that was broken was recently fixed by a vercel dev but I had already chosen a new approach to work around it. The most annoying though, is that their dev setup does some lazy-loading and caching magic. I think they try to compute the differences on a page and send partial updates over a web socket or something like that. It can get completely broken and you end up on an unrecoverable state. Sometimes a re-compile will trigger some communication from the server to the client and when I tab back to Chrome the tab is completely hung and I have to use the Chrome task manager to kill the process. It is all just very new and in the stage of many rough edges.

c-hendricks 3y ago
> many existing React libraries are assumed to run on client because they use hooks Do you mean context instead of hooks here? Plenty of hooks work on the server side, in that they do nothing other than initialize some values.
- zoogeny 3y ago
  I might be loose with my terminology, but hooks as standard as `useState` or `useRef` will trigger errors like: You're importing a component that needs useState. It only works in a Client Component but none of its parents are marked with "use client", so they're Server Components by default. There are ways around this, some of which he mentions in the post. It can just get tricky when you are trying to do complex composition. Another thing that hits me is when I have a server component that is marked as `async` and then for some reason it ends up on the client and I get the error that says something like "We don't support async components on the client yet ..." and I have to spend some time looking at my display hierarchy trying to figure out what is causing a client to import it. It reminds me of the "colored functions" blog post about async/await. You end up with colored components in your app which otherwise look and act the same. But now you have to be careful how you compose them together.
- acemarke 3y ago
  Actually, it's worse than that. Next has started throwing errors if it statically detects you even _importing_ hooks inside of a React Server Component environment: - https://github.com/apollographql/apollo-client/issues/10974 https://github.com/apollographql/apollo-client/issues/10974 - https://github.com/apollographql/apollo-client/issues/11167 https://github.com/apollographql/apollo-client/issues/11167 To the point that Lenz Weber( a maintainer of Apollo Client, and my co-maintainer on Redux Toolkit), is considering resorting to a package that wraps and re-exports all of React's public API just to avoid that static analysis: - https://github.com/apollographql/apollo-client/pull/11175 https://github.com/apollographql/apollo-client/pull/11175

c-hendricks 3y ago

> many existing React libraries are assumed to run on client because they use hooks Do you mean context instead of hooks here? Plenty of hooks work on the server side, in that they do nothing other than initialize some values.

zoogeny 3y ago
I might be loose with my terminology, but hooks as standard as `useState` or `useRef` will trigger errors like: You're importing a component that needs useState. It only works in a Client Component but none of its parents are marked with "use client", so they're Server Components by default. There are ways around this, some of which he mentions in the post. It can just get tricky when you are trying to do complex composition. Another thing that hits me is when I have a server component that is marked as `async` and then for some reason it ends up on the client and I get the error that says something like "We don't support async components on the client yet ..." and I have to spend some time looking at my display hierarchy trying to figure out what is causing a client to import it. It reminds me of the "colored functions" blog post about async/await. You end up with colored components in your app which otherwise look and act the same. But now you have to be careful how you compose them together.
acemarke 3y ago
Actually, it's worse than that. Next has started throwing errors if it statically detects you even _importing_ hooks inside of a React Server Component environment: - https://github.com/apollographql/apollo-client/issues/10974 https://github.com/apollographql/apollo-client/issues/10974 - https://github.com/apollographql/apollo-client/issues/11167 https://github.com/apollographql/apollo-client/issues/11167 To the point that Lenz Weber( a maintainer of Apollo Client, and my co-maintainer on Redux Toolkit), is considering resorting to a package that wraps and re-exports all of React's public API just to avoid that static analysis: - https://github.com/apollographql/apollo-client/pull/11175 https://github.com/apollographql/apollo-client/pull/11175