Mantine Component Library / dev mode / Error when evaluating SSR module #421
Comments
|
Thanks for reporting. Can anyone investigate it? It seems the error is different from others. |
|
To confirm, does |
Yes - The problem exists only in |
aheissenberger
changed the title
|
Oh, I misread the description. If it's CJS compatibility, it's a known limitation #110 and the workaround is something like this. waku/examples/12_css/vite.config.ts Lines 6 to 10 in 2742c3a |
|
Thanks - this fixed it - if you tell me where in the docs I can write a short text to help others:
import { defineConfig } from 'vite';
export default defineConfig(({ mode }) => ({
...(mode === 'development' && {
ssr: {
external: ['@mantine/core'],
},
}),
})); |
|
Great to hear. For now, how about |
|
I still have a Problem with all Components using the MantineProvider. They all have This is the wrapper component: repo to reproduce the problem: https://github.com/aheissenberger/waku-mantine-broken
|
|
Update on my tests:
@dai-shi Please give me some advice where I can further investigate to fix this problem. It looks like it is related to the SSR done with |
|
@dai-shi I need help - I have debugged this multiple times and still do not understand why the context ist lost. Here is a repository which only tries to access the Mantine Theme Context and always fails. The repo to reproduce the problem: This is the Mantine Context Provider which fails: |
|
Hi, sorry for the delay. Confirmed the use client directive: https://unpkg.com/browse/@mantine/core@7.5.0/esm/core/MantineProvider/MantineProvider.mjs So, I think we need to sit down and investigate it deeply.
Oh, you already tried it. Then, I'd add Mantine code into your own Context one by one, until it reproduces the error. |
Render StaticcreatePage({
render: 'static',
path: '/mantine',
component: MantinePage,
});Error: @mantine/core: MantineProvider was not found in component tree exists:
Works
Error build with SSR Render Dynamic createPage({
render: 'dynamic',
path: '/mantine',
component: MantinePage,
});Error: @mantine/core: MantineProvider was not found in component tree exists:
Works:
Error start with SSR |
|
add I was able to debug and isolate the Problem - it is related to the library // react-textarea-autosize.browser.esm.js
// line 104
var isIE = !!document.documentElement.currentStyle ;The problem is that You can reproduce the problem with: create a page with: import { MantineProvider } from '@mantine/core';
import { Textarea } from '@mantine/core';
export const TextareaPage = async () => {
return (
<div>
<title>TextAreaPage</title>
<h1>TextAreaPage</h1>
<MantineProvider>
<Textarea autosize={true}/>
</MantineProvider>
</div>
);
};run some more curiositiesThis will build textinput-page.tsx: import { MantineProvider } from '@mantine/core';
import { TextInput} from '@mantine/core'
export const TextinputPage = async () => {
return (
<div>
<title> TextinputPage </title>
<h1> TextinputPage </h1>
<MantineProvider>
<TextInput />
</MantineProvider>
</div>
);
};If I extract the TextInputComponent.tsx: 'use client'
import { TextInput} from '@mantine/core'
export const TextInputComponent = () => {
return (<div><TextInput/></div>);
}textinput-page.tsx: import { MantineProvider } from '@mantine/core';
import { TextInputComponent } from '../components/TextInputComponent.js';
export const TextinputPage = async () => {
return (
<div>
<title> TextinputPage </title>
<h1> TextinputPage </h1>
<MantineProvider>
<TextInputComponent />
</MantineProvider>
</div>
);
}; |
I wonder how Waku imports https://unpkg.com/browse/react-textarea-autosize@8.5.3/package.json "worker" isn't listed in https://runtime-keys.proposal.wintercg.org/ nor in https://github.com/browserslist/browserslist#browsers, and I'm not sure if it means "webworker" or "cloudflare workers". We should probably avoid it. Related #393 by @himself65 |
That's interesting and nice finding for a hint. |
|
I can do that in the next few days! |
I am not an expert on Some how the condition "exports": {
".": {
"types": {
"import": "./dist/react-textarea-autosize.cjs.mjs",
"default": "./dist/react-textarea-autosize.cjs.js"
},
"development": {...},
"worker": {
"module": "./dist/react-textarea-autosize.worker.esm.js",
"import": "./dist/react-textarea-autosize.worker.cjs.mjs",
"default": "./dist/react-textarea-autosize.worker.cjs.js"
},
"browser": {
"module": "./dist/react-textarea-autosize.browser.esm.js",
"import": "./dist/react-textarea-autosize.browser.cjs.mjs",
"default": "./dist/react-textarea-autosize.browser.cjs.js"
},
"module": "./dist/react-textarea-autosize.esm.js",
"import": "./dist/react-textarea-autosize.cjs.mjs",
"default": "./dist/react-textarea-autosize.cjs.js"
},
"./package.json": "./package.json"
}, |
|
@dai-shi what I do not understand is why the rendering (SSR on server during build) export function loadModule(id) {
switch (id) {
case 'rsdw-server':
return import('./rsdw-server.js');
case 'client/react':
return import('./public/assets/react.js');
case 'client/rd-server':
return import('./public/assets/rd-server.js');
case 'client/rsdw-client':
return import('./public/assets/rsdw-client.js');
case 'client/waku-client':
return import('./public/assets/waku-client.js');
case 'public/assets/waku-client.js':
return import('./public/assets/waku-client.js');
case 'public/assets/rsc0-47a606723.js':
return import('./public/assets/rsc0-47a606723.js');
...This is the reason for the |
|
SSR is basically traditional client React rather than RSC. So, it runs with client bundles. Otherwise, we can't render client components on server. I'm not sure if this answers to your question all. Feel free to have follow-up questions. |
Yeah, I think removing the "browser" condition will solve this. But, not sure if it breaks other cases as a side effect. |
I think you will need to bundle a different set of modules for SSR at build time without the condition "browser". The existing modules in the
|
|
"worker" condition looks like an undocumented name. There are two kinds of workers: node worker and web worker, and maybe more: deno worker... anyway they are all just |
In my option - see above - the bundle conditions required for SSR during the build step can leave it to the package.json import configuration to choose the right package. As long as there is no "browser" condition, the default in the import section of packages.json is pointing to a version of the code which does not need a browser environment. |
I'm a bit skeptical about it. Our implementation shouldn't be that complicated, and it basically leads to more "hydration mismatch" errors. Can anyone investigate how Next.js solves it? |
I have no idea how Next.js works but I use Solid Start which uses vinxi from @nksaraf. The internal output folder I did some research based on the official Vite SSR & SSG Example code and my findings are:
Here is my repro which I used to conduct the tests: I suggest to change the build pipeline to support the following target output:
maybe have a look at vinxi - specifically the existing deploy adapter from the Nuxt ecosystems Nitro Stack are amazing. |
|
Okay, if we were to split bundles to three types, it would require re-architecture to some extent and might be able to only come after v0.20. There's an issue with Vite, as I see, because we use Vite's SSR mode for RSC, it's conflicting. We could work it around with two vite configs, but I wish Vite would support RSC (a new server mode) natively. Otherwise, our code base won't be fairly maintainable. That said, I'm not sure if I understand the issue and the community standard (especially Meanwhile, I would like to try two workarounds:
|
|
I found this info related to the needed three graphs: and I could solve the problem mit changing from: to with not including the modules for the ssd build and loading the right packages from node_module folder it fixed the one problem but it broke at an other place in the Mantine code :-( |
|
As here are too many problem intermingled, I will create a specific issue and example implementation with the react-textarea-autosize component for handling packages which correctly provide different code for browser, node and other environments. |
|
Yeah, let's tackle one by one. |
|
Let's say #448 is a separate issue, and disable SSR (no and, if #445 handles CJS as hoped, the remaining issue is #421 (comment), right? |
|
I do not See any changes when using the latest code from the main branch which should include #445 . With the libraries externalized it works for simple Components (e.g. Buttons) but fails for complex ones (e.g. DateInput) with #421 (comment) When I disable this in ssr: {
//external: ['@mantine/core','@mantine/dates','@mantine/hooks'],
},I get this error when loading a page in the browser - gives the same error for |
|
#445 isn't merged yet. |
|
with #445 and without externalized libraries: simple components
complex components (e.g. DateInput)
|
|
Thanks for the summary. #448 will be tackled separately, so known remaining is |
|
#457 fixes all problems except |
|
Here is the simples Test case for
import '@mantine/core/styles.css';
import '@mantine/dates/styles.css';
import { MantineProvider, useMantineTheme } from '@mantine/core';
import { MantineConsumer } from '../components/MantineConsumer.js';
export const MantinePage = async () => {
return (
<MantineProvider>
<div>Mantine</div>
<MantineConsumer />
</MantineProvider>
);
};
'use client';
import { useMantineTheme} from '@mantine/core'
export const MantineConsumer = () => {
const theme = useMantineTheme();
return (<div>Theme: {`${theme?.primaryColor}`}</div>);
}
ERROR: |
|
@aheissenberger It seems like you are becoming fairly familiar with Waku codebase. |
I tried this a couple days ago but could not find a setup which reproduced the problem. "normal" Context works |
|
This fixed it. import { defineConfig } from 'vite';
//import { vanillaExtractPlugin } from '@vanilla-extract/vite-plugin';
export default defineConfig(({ mode }) => ({
...({
optimizeDeps: {
exclude: ['@mantine/core','@mantine/dates','@mantine/hooks'],
},
ssr: {
noExternal: ['@mantine/core','@mantine/dates','@mantine/hooks'],
},
}),
//plugins: [vanillaExtractPlugin({ emitCssInSsr: true }), stylexPlugin()],
}));While investigating, found out that MantineProvider was importing the ESM format of mantine (all modules were seperate), but the CopyButton was receiving the optimized bundled version of mantine (a huge mantine_core.js file, maybe cjs?). I'm not sure about the reason, but I guess this is either a vite issue, because this happened when the module was being imported later on (e.g. dynamic import through chunk loading in waku). Or it's a package exports issue from mantine. I first doubted that waku was importing modules in two different modes (one main thread, one worker) in the server, but that was not correct, plus this issue was also happening in the client (that's why we have Feel free to close this issue if it resolved the problem. |
|
@Aslemammad Thanks for investigating. So, it's dual module issue with CJS/ESM. I wonder why we (waku&vite) don't always pick ESM. |
I don't think it's us to choose, it's mostly related to package exports and these things happen many times. I might be wrong, so if anyone knows how we can enforce ESM, please let us know. |
|
I can start a documentation on how to add React UI Libraries to Waku and would start with Mantine to document the findings from Aslemammad in a central place. Please provide me with the place/folder and if exits with the required document structure. |
|
We haven't decided the docs structure, so let's start with something like |
|
I have a setup wich currently works with all base Mantine Libraries:
Not working:
Not tested (will be done soon):
I have also prepared a template to be added to the Mantine get started Community templates section which will need the next release of Waku to become usable. I also work on a documentation on how to add Mantine including required fixes to a fresh Waku setup. |
|
Update:
@dai-shi the bundling currently does not exists? I get 588 javascript requests on this simple form and a 1.5MB/1.7MB Download https://d3u8jdoqz1djq3.cloudfront.net/appshell/mantine/form |
Do you mean bundling for client? See our simple template. Does it look good? |
|
This is the import { defineConfig } from 'vite';
export default defineConfig(({ mode }) => ({
...({
optimizeDeps: {
include: [
'dayjs', 'dayjs/**/*', // @mantine/dates
'@mantine/charts > lodash/**/*', // @mantine/charts
'@mantine/code-highlight > highlight.js', // @mantine/code-highlight
'@mantine/notifications > prop-types', // @mantine/notifications
],
esbuildOptions: {
preserveSymlinks: true,
},
exclude: ['@mantine/core', '@mantine/hooks', '@mantine/code-highlight', '@mantine/charts', '@mantine/spotlight', '@mantine/notifications','@mantine/carousel','@mantine/dropzone','@mantine/nprogress','@mantine/tiptap'],
},
ssr: {
noExternal: ['@mantine/core', '@mantine/hooks', '@mantine/code-highlight', '@mantine/charts', '@mantine/spotlight', '@mantine/notifications','@mantine/carousel','@mantine/dropzone','@mantine/nprogress','@mantine/tiptap'],
},
}),
plugins: [],
})); |
|
@dai-shi @Aslemammad - you rock! WAKU git commit ff20bfe fixed all problems for Update on DEV MODE problems: Except for the Mantine Charts which fails with an additional Error I can fix the problems in DEV MODE by adding a Error in DEV MODE: - without ssr the error is thrown in the browser. |
Is it possible to create a reproduction without the library? |
|
I will try again - but its hard to replicate the complexity of the main context provider of the library. |
|
I am not able to fix the problem and need help @dai-shi @Aslemammad: I was able to replicate the problem with a simple replication of the Here is a reference project which shows the problem: I had to add the provider as an external package to get the error: The same provider local as part of a WAKU project will not loose the context: |
|
Hmm, hope @Aslemammad has an idea. |
How can I use Mantine with WAKU without getting this Error:
(
waku dev --with-ssrorwaku dev- no problem withwaku build --with-ssr)repo to replicate the error: https://github.com/aheissenberger/waku-mantine-broken
Versions:
Mantine: 7.4.2 - works with NextJS App Router and has
'use client'in all components - https://mantine.dev/guides/next/WAKU: 0.19.1
root-layout.tsx
The text was updated successfully, but these errors were encountered: