Improve Next.js support

mnajdova commented 1 year ago

Summary 💡

This issue will serve as an umbrella for all issues related to Next.js app router integration. It will be easier to have an overview of all the problems in one place.

Done

[x] Next.js 13 Hydration failed because the initial UI does not match what was rendered on the server #34893
[x] Next.js 13 example with /app folder #34898
[x] Next.js 13 compatibility (app directory/server components) #34896
[x] Add use client directive to all components in a new build step #37503
[x] Next.js 13 Error during SSR Rendering ReferenceError: defaultStyleFunctionMapping is not defined #34910
[x] Next.js 13 global styles issue #37935
[x] Cover useId Next.js limitation #38103
[x] Make Next.js App Router example the default recommended over Next.js Page Router #38204
[x] Configure and document modularizeImports for icons #35450 #36218
[x] Create an npm package to abstract APIs for Next.js, solving boilerplate issue #34575
[x] Simply the Next.js examples. It should be as simple as possible for developers to start a project and to pull in UI from other places, like from the templates. For example https://github.com/mui/tech-challenge-full-stack/issues/3#issuecomment-1743231738 #40661

Opportunities to make it even better

[ ] #39010
[ ] #37934
[ ] #35993
[ ] #38966
[ ] Migrate Link, remove legacyBehavior={true} https://github.com/mui/material-ui/issues/38092
[ ] Add docs on how to integrate the font with the theme https://github.com/mui/material-ui/issues/38082
[ ] Flatten imports for faster dev server speed #35840
[ ] Create guide on how to configure CSP, it's missing in https://mui.com/material-ui/guides/content-security-policy/#how-does-one-implement-csp, related to #36095
[ ] Create a @mui/system-nextjs package, move the logic that has noting to do in @mui/material-nextjs
[ ] Add support for loading indicator between pages when slow network.

https://github.com/mui/material-ui/blob/d37dd5cec56142a16451b9acb6e3d4cd70ac003e/docs/src/modules/components/AppFrame.js#L40-L46

[ ] Full dark/light mode integration, see the features missing from https://github.com/pacocoursey/next-themes

RPDeshaies commented 1 year ago

Not sure if it could be considered to be related to Next13, but I think this issue is also kind of related considering it's about running turbopack within a NextJS 13 application.

https://github.com/mui/material-ui/issues/34910

mnajdova commented 1 year ago

Not sure if it could be considered to be related to Next13, but I think this issue is also kind of related considering it's about running turbopack within a NextJS 13 application.

https://github.com/mui/material-ui/issues/34910

Thanks, added.

mnajdova commented 1 year ago

There have been some movement on emotion's side for supporting it in ./app directory. I've forked their stackblitz and added few Material UI components and a custom theme, and it seems like it works 🎉 Here is the link to stackblitz. You can check the ./blog route that uses server component.

I would appreciate feedback if someone wants to try it. I personally want to try this on the blog page in the https://mui.com site to verify that everything works. I will create an example project based on the stackblitz later this week.

barthicus commented 1 year ago

@mnajdova That's a great news! I hope some day we can use mui in app dir for real :) I tried your example and I was curious if that works with @mui-treasury/layout I use. Unfortunately some @emotion related errors pop up: TypeError: React.createContext is not a function so I stopped testing this further. I only modified the root layout and added the package. Link to my edited stackblitz: https://stackblitz.com/edit/vercel-next-js-zmhzbd

EDIT: Not sure if that helps in any way, maybe there is just a problem in that layout package but I thought I will share it anyway.

mnajdova commented 1 year ago

After doing some more investigation, I noticed that not all Material UI components can be render as server components. I was lucky in the example that the Typography component was one of them. We will need to revisit this. I will be posting more updates here, or create a new issue that will track the progress on all components.

mnajdova commented 1 year ago

Based on https://github.com/emotion-js/emotion/issues/2928#issuecomment-1319747902

Note that you should only use Emotion with the so-called client components (we might add "use client"; directive to our files to make this obvious). They can render on the server just fine - for the initial SSRed/streamed HTML but server "refetches" won't render them on the server, they might be rendered on the client when the "refetch" response comes back. This is not Emotion's limitation - it's a limitation for all CSS-in-JS libs like Emotion (including Styled Components, styled-jsx and more)

Looks like the best way forward is to add the "use client" directive to all Material UI components, at least until emotion supports server components.

Andarist commented 1 year ago

Looks like the best way forward is to add the "use client" directive to all Material UI components, at least until emotion supports server components.

You don't have to add it to all the client components (although that's certainly the easiest solution here). If you have a set of completely headless components that don't rely on Emotion (nor on Styled-Components or other CSS-in-JS libs) then, to the best of my current understanding, you don't have to add that directive there.

Server Components were designed in a way that is at fundamental odds with CSS-in-JS. So don't expect Emotion (or other popular CSS-in-JS libs) to introduce support for them. They just don't allow us to integrate with them anyhow.

However, that doesn't mean that you can't SSR client components using Emotion. The initial HTML response from the server can freely use the rendered client components. The problem is only when it comes to "server component (re)fetches" (where I'm not even exactly sure how to trigger them, although Next.js probably does those on navigation or smth).

You can still do this:

function ServerComponent({ id }) {
  const data = use(fetchData(id))
  return <ClientComponent data={data} />
}

Basically, with server components, you might want to move your data-loading concerns out of your client components. That's it. Note that server components are also unique as they support using async/await - so I expect that many people will want to split those concerns anyway (regardless of the fact if they are using CSS-in-JS or not).

Of course, full support of server components would be neat and would make things easier for consumers - and would only require "splitting" if you really want to use async/await, or if you have another reason to do so. But as mentioned - this is probably not going to happen for CSS-in-JS libs as the server component's design doesn't quite allow this.

robcaldecott commented 1 year ago

I've started experimenting with this using a large app at work and there is an initial FOUC before the styles are applied which is proving tricky to debug. I don't see this on the Stackblitz example shared above but I'll see if I can provide an example, although it may be something the emotion team need to worry about.

Andarist commented 1 year ago

I can't address something that I can't debug 😉 If you provide a repro case then I will happily jump onto it

mnajdova commented 1 year ago

You don't have to add it to all the client components (although that's certainly the easiest solution here). If you have a set of completely headless components that don't rely on Emotion (nor on Styled-Components or other CSS-in-JS libs) then, to the best of my current understanding, you don't have to add that directive there.

Totally 👍 MUI Base components that don’t have any interactions could be server components. All Material UI components anyway load emotion, my comment was referring to them.

Basically, with server components, you might want to move your data-loading concerns out of your client components. That's it. Note that server components are also unique as they support using async/await - so I expect that many people will want to split those concerns anyway (regardless of the fact if they are using CSS-in-JS or not).

100% agree with this. I think the misconception comes from the difference that using plain CSS would allow you do convert the UI components too.

robcaldecott commented 1 year ago

I can't address something that I can't debug 😉 If you provide a repro case then I will happily jump onto it

Hey @Andarist @mnajdova here's a repo that shows the FOUC:

https://github.com/robcaldecott/nextjs-mui-app-folder

It's a single page with Container, Grid and two different TextField components. It's using next@13.0.5. The FOUC happens in both dev and production modes: just refresh the page and you'll see it.

I also see the following console error which may be relevant:

Warning: Each child in a list should have a unique "key" prop. See https://reactjs.org/link/warning-keys for more information.
    at style

I am using the EmotionRootStyleRegistry.tsx from the example above.

Andarist commented 1 year ago

100% agree with this. I think the misconception comes from the dofference that using plain CSS would allow you do convert the UI components too.

Yeah, this is very well put. It's true that some components with "plain css" can be rendered using server components but the majority of them just can't. From my PoV... I wouldn't like to bother thinking in those terms when writing components in the first place. It's creating a mental overhead - "can I use styles in this server component?". It's much easier to just "forbid" this in the code and make the distinction clear (even with a lint rule or something). Having to restructure your server component with plain CSS just because you want to add some interactivity would also be a chore - it's just, IMHO, easier to start with an explicit split between those concerns and leave server components as something without styles at all.

@robcaldecott this was an interesting case to investigate!

You need to add an explicit <head/> element to your layout to fix this:

diff --git a/app/layout.tsx b/app/layout.tsx
index 9c052a8..68bb86c 100644
--- a/app/layout.tsx
+++ b/app/layout.tsx
@@ -4,6 +4,7 @@ import EmotionRootStyleRegistry from "./EmotionRootStyleRegistry";
 export default function RootLayout({ children }: { children: ReactNode }) {
   return (
     <html>
+      <head></head>
       <body>
         <EmotionRootStyleRegistry>{children}</EmotionRootStyleRegistry>
       </body>

robcaldecott commented 1 year ago

@Andarist OMG thank you so much! I thought the original example had left that in by mistake, ha!

garronej commented 1 year ago

tss-react now provides a setup helper for Next 13 appDir.
If you use it, emotion and consequently MUI will work as well.

barthicus commented 1 year ago

tss-react now provides a setup helper for Next 13 appDir. If you use it, emotion and consequently MUI will work as well.

@garronej You link navigates to a 404 page. Url was encoded and hash was replaced ;) Working link: https://docs.tss-react.dev/ssr/next.js#app-dir

ayushrajniwal-jtg commented 1 year ago

@barthicus, would you mind creating a code sandbox for the same? I have used the same example mentioned in the document but couldn't SSR the MUI component.

I'm still getting the same error:

error - (sc_server)/node_modules/@mui/base/node/FormControlUnstyled/FormControlUnstyledContext.js (13:54) @ eval
error - TypeError: React.createContext is not a function
    at eval (webpack-internal:///(sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/FormControlUnstyledContext.js:48:60)
    at (sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/FormControlUnstyledContext.js (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/app/page.js:3087:1)
    at __webpack_require__ (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///(sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/FormControlUnstyled.js:12:58)
    at (sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/FormControlUnstyled.js (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/app/page.js:3076:1)
    at __webpack_require__ (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///(sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/index.js:35:51)
    at (sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/index.js (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/app/page.js:3109:1)
    at __webpack_require__ (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///(sc_server)/./node_modules/@mui/base/node/index.js:245:52) {
  type: 'TypeError',
  page: '/'
}

Here is the sandbox for the same: https://codesandbox.io/s/white-meadow-ft6ok7?file=/app/layout.tsx

garronej commented 1 year ago

@ayushrajniwal-jtg There you go, ~~your playground fixed~~ a demo setup

You can't use providers in server components: https://beta.nextjs.org/docs/rendering/server-and-client-components#rendering-third-party-context-providers-in-server-components

ayushrajniwal-jtg commented 1 year ago

Thanks for looking into it @garronej. However, the playground is not working either. Getting the same error as mentioned above

@barthicus, would you mind creating a code sandbox for the same? I have used the same example mentioned in the document but couldn't SSR the MUI component.

I'm still getting the same error:

error - (sc_server)/node_modules/@mui/base/node/FormControlUnstyled/FormControlUnstyledContext.js (13:54) @ eval
error - TypeError: React.createContext is not a function
    at eval (webpack-internal:///(sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/FormControlUnstyledContext.js:48:60)
    at (sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/FormControlUnstyledContext.js (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/app/page.js:3087:1)
    at __webpack_require__ (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///(sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/FormControlUnstyled.js:12:58)
    at (sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/FormControlUnstyled.js (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/app/page.js:3076:1)
    at __webpack_require__ (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///(sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/index.js:35:51)
    at (sc_server)/./node_modules/@mui/base/node/FormControlUnstyled/index.js (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/app/page.js:3109:1)
    at __webpack_require__ (/home/e-ubuntu20/Desktop/Experiment/next-13-mui/.next/server/webpack-runtime.js:33:42)
    at eval (webpack-internal:///(sc_server)/./node_modules/@mui/base/node/index.js:245:52) {
  type: 'TypeError',
  page: '/'
}

Here is the sandbox for the same: https://codesandbox.io/s/white-meadow-ft6ok7?file=/app/layout.tsx

garronej commented 1 year ago

@ayushrajniwal-jtg there you go a working demo:

https://github.com/garronej/mui-next-appdir-demo

https://user-images.githubusercontent.com/6702424/209325604-51fd395c-521e-47b8-99b2-a4f908162047.mov

francismanansala commented 1 year ago

@ayushrajniwal-jtg there you go a working demo:

https://github.com/garronej/mui-next-appdir-demo

Screen.Recording.2022-12-23.at.12.05.46.mov

I want to use this tss-react solution you provided for a personal project.

However, I tried running your demo and ran into an issue. I see it load initially then it runs into an error when trying to render the client components:

I'm using node v18.12.1 and on windows 10 if that helps. Do you know why I would be seeing this error when I'm using your demo?

garronej commented 1 year ago

Hi @francismanansala,
Have you run the repo exactly as it's provided as per the instruction in the README?

I'm running it on MacOS with node v16.15.1

francismanansala commented 1 year ago

Hi @francismanansala, Have you run the repo exactly as it's provided as per the instruction in the README?

I'm running it on MacOS with node v16.15.1

Yeah, I've followed the README but used npm instead of yarn. I tried with node 16 as well and I ran into this same issue. I don't think yarn would make a difference

[edited] I tried it with yarn and it made no difference

[edited again] I tried this on a MacOS and it works.

There must be something wrong with my windows machine. It’s my first time using nextjs, and mui on it so maybe I haven’t set it up correctly.

[edited once again] I found this stack overflow post: https://stackoverflow.com/questions/74832268/typeerror-cannot-read-properties-of-undefined-reading-call-on-next-js. Downgraded to 13.0.6 on windows and it resolved my issue. Possibly a bug in 13.0.7 related to the macOS file system not being case-sensitive but other OS are.

garronej commented 1 year ago

@francismanansala Thanks for taking the time to share the result of your investigations!

iamcrisb commented 1 year ago

@Andarist OMG thank you so much! I thought the original example had left that in by mistake, ha!

That did not change anything, the example still causes FOUC, can you provide a repo where this actually works, please?

garronej commented 1 year ago

https://github.com/garronej/mui-next-appdir-demo

andriijas commented 1 year ago

Epic work @garronej!

The bigger question for mui and joy is however how to support RCS in the future. Obviously streamable react server components and concurrent rendering is young and it was only recently mui opted in to emotion on large scale.

garronej commented 1 year ago

Thanks @andriijas,

The bigger question for mui and joy is however how to support RCS in the future. Obviously streamable react server components and concurrent rendering is young and it was only recently mui opted in to emotion on large scale.

See this message and and this other one from Andarist.

iamcrisb commented 1 year ago

https://github.com/garronej/mui-next-appdir-demo

have you tried with nested layouts and redux as top provider?

vanguardapps commented 1 year ago

Since writing a set of wrappers for all MUI components that include the use client directive appears to be the solution most people are going with, has anyone produced such a wrapper library yet? If not I may post one for people to use until there is direct 'splitting' support.

garronej commented 1 year ago

Hello @mnajdova and @Andarist,
I come with bad news 😞
AppDir + emotion is broken.
Hydration errors happen randomly in production (never in dev mode).
After about 50+ hours of thorough investigation, my conclusion: it's a Next.js bug.
I've created a reproduction repo and opened an issue.
If you guys could confirm my conclusions that would help a lot get it noticed by Vercel.

Thanks in advance!

TL;DR: If you start using MUI in an AppDir setup today you'll probably end up with random production errors that breaks the interactivity of the whole app (it's not a warning that can be ignored).

PS: Thank you @Andarist for recommending Replay.io. <3

francismanansala commented 1 year ago

Hello @mnajdova and @Andarist, I come with bad news 😞 AppDir + emotion is broken. Hydration errors happen randomly in production (never in dev mode). After about 50+ hours of thorough investigation, my conclusion: it's a Next.js bug. I've created a reproduction repo and opened an issue. If you guys could confirm my conclusions that would help a lot get it noticed by Vercel.

Thanks in advance!

TL;DR: If you start using MUI in an AppDir setup today you'll probably end up with random production errors that breaks the interactivity of the whole app (it's not a warning that can be ignored).

PS: Thank you @Andarist for recommending Replay.io. <3

I've ran into a issue while developing where the npm run dev command would crash when trying to hot reload my changes to the browser. Do you think that would be related? This is npm run dev logs before exiting:

event - compiled client and server successfully in 1361 ms (2845 modules)
wait  - compiling...

<--- Last few GCs --->

[69188:000001A341C29DD0]  1188701 ms: Scavenge 4073.9 
(4099.1) -> 4071.9 (4099.1) MB, 1.5 / 0.0 ms  (average mu = 0.280, current mu = 0.296) allocation failure   
[69188:000001A341C29DD0]  1188705 ms: Scavenge 4074.8 
(4099.3) -> 4073.4 (4108.3) MB, 1.6 / 0.0 ms  (average mu = 0.280, current mu = 0.296) allocation failure 
[69188:000001A341C29DD0]  1188716 ms: Scavenge 4079.8 
(4108.6) -> 4075.6 (4109.4) MB, 1.6 / 0.0 ms  (average mu = 0.280, current mu = 0.296) task

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory    
 1: 00007FF6DF36151F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+121999
 2: 00007FF6DF2EB386 DSA_meth_get_flags+64118
 3: 00007FF6DF2EC402 DSA_meth_get_flags+68338
 4: 00007FF6DFC22C94 v8::Isolate::ReportExternalAllocationLimitReached+116
 5: 00007FF6DFC0D25D v8::SharedArrayBuffer::Externalize+781
 6: 00007FF6DFAB081C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
 7: 00007FF6DFABD4C9 v8::internal::Heap::PublishPendingAllocations+1129
 8: 00007FF6DFABA49A v8::internal::Heap::PageFlagsAreC 9: 00007FF6DFAAD0F9 v8::internal::Heap::CollectGarbage+2137
10: 00007FF6DFAB59BB v8::internal::Heap::GlobalSizeOfObjects+331
11: 00007FF6DFAFC14B v8::internal::StackGuard::HandleInterrupts+891
12: 00007FF6DF803FF6 v8::internal::DateCache::Weekday+8630
13: 00007FF6DFCB0971 v8::internal::SetupIsolateDelegate::SetupHeap+494417
14: 000001A34461BC45

garronej commented 1 year ago

Hi @francismanansala,
No, this is unrelated.

vanguardapps commented 1 year ago

Well, now I have to choose between mui and the app directory. :(

andriijas commented 1 year ago

Well, now I have to choose between mui and the app directory. :(

You do know that ”the app directory” is beta? https://beta.nextjs.org/docs/app-directory-roadmap

garronej commented 1 year ago

Well, now I have to choose between mui and the app directory. :(

I mean, it will get fixed eventually, but as @andriijas mentioned, this is the kind of setbacks you have to be prepared to when experimenting with beta features.

vanguardapps commented 1 year ago

Well, now I have to choose between mui and the app directory. :(

You do know that ”the app directory” is beta? https://beta.nextjs.org/docs/app-directory-roadmap

Indeed, I am aware. Just whining out loud. My project is a prototype anyway and, as @garronej pointed out, this will get fixed in time. I do really like the changes they made in v13 though, so I'm inclined to pick the app directory over mui for right now. Because it's just me building out the prototype, my options are vast and numerous. Going with Tailwind and a thin custom component layer for now.

Honestly wish I had time to contribute to the Next project and help out.

markhughes commented 1 year ago

If you just need to use MUI on a small portion of the app directory, and are ok with losing SSR until all this is fixed..

Kind ruins the point though.

'use client';

import dynamic from 'next/dynamic';

import type { ThemeProvider } from '@emotion/react';

const DynamicThemeProvider = dynamic(() => import('@mui/material/styles/ThemeProvider')) as ThemeProvider;

import { theme } from '../../theme/that/you/want';

// Required until https://github.com/vercel/next.js/issues/41994 is fixed
export const LayoutWrapper = ({ children }: { children: React.ReactNode }) => {
  return (
    <DynamicThemeProvider theme={theme}>
      {children}
    </DynamicThemeProvider>
  );
};

If you're not using TypeScript just remove the import type and as ThemeProvider portion.

all pages will require 'use client'

LubomirGeorgiev commented 1 year ago

Any movement here?

madaher-dev commented 1 year ago

Seems we will have to wait until app directory is stable

garronej commented 1 year ago

@LubomirGeorgiev Well, I mean, with the TSS setup it works.
Here you have an example: https://react-dsfr-next-appdir-demo.vercel.app/mui And here is the code: https://github.com/garronej/react-dsfr-next-appdir-demo
There is just this random hydration error that ruins the fun but as you can see, it doesn't happen very often and it will probably be fixed by Vercel soon.

LubomirGeorgiev commented 1 year ago

@garronej

@LubomirGeorgiev Well, I mean, with the TSS setup it works.
Here you have an example: https://react-dsfr-next-appdir-demo.vercel.app/mui And here is the code: https://github.com/garronej/react-dsfr-next-appdir-demo
There is just this random hydration error that ruins the fun but as you can see, it doesn't happen very often and it will probably be fixed by Vercel soon.

Yeah but the use client tag defeats the whole purpose of SSR.

I think the emotion and Next maintaners should give us at least some hope that they are thinking about possible solutions. Has anyone heard anything from them regarding this?

LubomirGeorgiev commented 1 year ago

Things look kind of silent here https://github.com/emotion-js/emotion/issues/2928

garronej commented 1 year ago

SSR do work.
If you disable JavaScript in the demo I shared you'll see that the page renders fine.
Now that's true that you can't use Emotion in server components, nor any other CSS-in-JS solution as a mater of fact.
However it isn't "defeating the purpose", Andarist put it better than me: https://github.com/mui/material-ui/issues/34905#issuecomment-1330939826

Things look kind of silent here https://github.com/emotion-js/emotion/issues/2928

This issue will be marked as resolved when there is something equivalent to the TSS's <NextAppDirEmotionCacheProvider/> provided by Emotion, not when Emotion is usable in server components, which probably isn't going to happen according to Andarist.

LubomirGeorgiev commented 1 year ago

@garronej

This issue will be marked as resolved when there is something equivalent to the TSS's provided by Emotion, not when Emotion is usable in server components, which probably isn't going to happen according to Andarist.

If it isn't going to happen, are you guys considering removing emotion from MUI in future versions?

garronej commented 1 year ago

Hi @LubomirGeorgiev,
I'm not working for MUI, you'll have to tag @oliviertassinari or @mnajdova for an answer.

If you want my two cents, it would be a complete paradigm shift. It wouldn't be just replacing Emotion it would mean going away from CSS-in-JS altogether and implement a tailwind like approach instead.
Would it be worth it? Not quite sure, most MUI components are interactive and thus would require "use client"; anyway.
As for the question: "should I stop using emotion for writing my custom style?" the response isn't clear either.
You can very well leverage RSC and still use a CSS-in-JS library. It just means that you would use Server component only for data loading concerns and avoid writing style in them. It's better explained by Andarist.

leerob commented 1 year ago

Hey folks! I'd love to chime in with a few clarifications:

MUI works today in Next.js 13 with no changes required in the pages directory.
The pages directory is not being deprecated – the goal with app is to enable incremental adoption, knowing that some folks will likely have some routes in pages and some in app for a decent amount of time.
You can think of client components in Next.js kind of like Next.js 12 and before – they're still pre-rendered on the server and support SSR. You will be able to use MUI / Emotion with client components. Emotion support is tracked here, as mentioned above.
Turbopack support is independent of all of this, and still in progress.

Looks like the best way forward is to add the "use client" directive to all Material UI components, at least until emotion supports server components.

We're working on better library guidance to help the ecosystem adopt server components. For example, this package includes "use client" and works without additional wrapping components inside the app directory.

Basically, with server components, you might want to move your data-loading concerns out of your client components. That's it. Note that server components are also unique as they support using async/await - so I expect that many people will want to split those concerns anyway (regardless of the fact if they are using CSS-in-JS or not).

Great point. The patterns are still being established, but it's very possible folks might do data fetching in async components, and then still use MUI as client components for everything else further down in the tree.

Finally, it's also worth mentioning that moving to app and using only client components still has a ton of benefits. Async components, co-located tests, styles, and data fetching, importing global CSS in any file, and other in-progress work like mutations and improved support for SEO.

Andarist commented 1 year ago

You will be able to use MUI / Emotion with client components. Emotion support is https://github.com/emotion-js/emotion/issues/2928, as mentioned above.

It's also worth noting that for the most part, this already works. People can copy-paste the snipper from the issue and use the new stream rendering in Next.js with the app directory.

I started to work on making this easier (where I don't really consider the current way to be overly hard) - but my primary goal right now is to add support for general-purpose streaming helper. Next.js doesn't actually expose the wiring to the user so we have to use its useServerInsertedHTML (which is not a big deal and makes it a lot easier for me to integrate with). The current status is that I'm learning things about node streams and how to wrangle them.

oliviertassinari commented 1 year ago

So, from what I understand:

It would be great to solve #34898 today. Even if developers use all Material UI components with "use client", there is still a lot of value in having the /app folder with Next.js. It also seems that there is no blocker for developers to use Next.js /app with Material UI (with client side components).
To have #35993, we would need to make progress with #34826. This would be key for supporting landing pages. For example, a <Stack> shouldn't need to be a client-side component. But it would also benefit all the simple dashboard use cases, e.g. you won't need to virtualize anymore for rendering a list of 500 items.

garronej commented 1 year ago

Hi @oliviertassinari,

It also seems that there is no blocker for developers to use Next.js /app with Material UI (with client side components).

Minus this unresolved Next issue which is a big deal as the app can candomy be uninteractive for some users in production.

Haseebshah936 commented 1 year ago

Hi, I am about start a project for my organisation with next 13. I am familiar with MUI but while reading the docs it came to me that it is still in support can any one tell me what's the status of MUI. I mainly use it for its components so is it a good idea to use it with next 13 right now. The site on which I will be working is an e-commerce store. Whats the suggestion on this and also suggest any other alternatives that work well with next 13 except Tailwind. Thanks

mui / material-ui