4 ms·

> 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 serv

> 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

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