Closed Destaq closed 7 months ago
I've noticed that if you throw an error inside of nuxtServerInit
, as so:
export const actions = {
async nuxtServerInit({ commit }, { req }) {
throw new Error('Makes DaisyUI work');
}
}
However, this obviously isn't a good solution. However, it may help in identifying the problem with Nuxt Bridge.
If you set disable Tailwind's JIT mode, then there is a slightly different result.
Instead of there being a short flicker, the screen freezes on the unrendered, pre-plugin styling, and then styles everything. From there, in-app navigation works without styling issues - this only happens on page loading. This leads me to believe that Tailwind plugin style loading is somehow failing to block the page render.
Any chance of this getting addressed anytime soon?
I've been hesitant to continue working with Nuxt Bridge since there's been no fix to this Nuxt-caused issue for the past month.
I'm facing the same issue with Tailwind and Nuxt 3
I'm facing the same issue with Tailwind and Nuxt 3
Have you been able to come up with a solution?
Any news on this bug? I figured out that any global styles that you define in the css property on nuxt.config are added to the page by a script and not inlined in the HTML on SSR.
This causes a flicker because the page is first shown without any styles and then the styles are loaded.
This is also true if you generate static pages using nuxi generate
using Nuxt Bridge.
I tried to compile tailwindcss using the Tailwind CLI and the using the compiled output on nuxt.config -> Got the same result.
Would be a lot better if the global styles were added inline the same way style defined in the components are added.
I found a workaround to remove the flickering. Instead of adding the global tailwind css file to nuxt.config css
property, I have imported it into my layouts/default.vue file like so:
<style lang="postcss">
@import '@/assets/css/main.css';
</style>
This way the tailwindcss is inlined into the final HTML and not loaded with <link rel="preload">
. The only drawback is that your HTML file becomes bigger. However my Lighthouse performance went from a 70 to a 92 because it no longer has a poor CLS score.
If you have more than one layout, you need to add this to every layout.
Adding styles to layouts seems a reasonable workaround, however, it leads to style duplication (even when using sass @use
which should theoretically dedupe). Inlining styles from NuxtConfig.css is something we really need
Why not add the following to app.vue? instead of layouts?
<style lang="postcss">
@import '@/assets/css/main.css';
</style>
Why not add the following to app.vue? instead of layouts?
<style lang="postcss"> @import '@/assets/css/main.css'; </style>
I think the role of app.vue is actually the same as of layouts/default.vue If not, I would be happy to be wrong
I think the role of app.vue is actually the same as of layouts/default.vue
Not really, IIRC app.vue is the application entrypoint, and will be the first to render, any layout would be rendered in the place where
I am not really sure, but I think docs need to be updated then to indicate what is the role of app.vue other than replacing a single layout file.
I still dont think adding critical css files in app.vue is still the way to go. It results in a poor lighthouse score (as this is claimed to be bad js) and has partially resulted in this somehow? https://github.com/FortAwesome/vue-fontawesome/issues/342
Which is also the reason behind an initial flicker. when markup is loaded but the css is loaded when js executes.
A critical problem lies here because the vite bundler doesnt support dynamic glob imports (in the style of nuxt2)
Edit: I clearly missed the bridge tag on this issue, but this seems to occur on nuxt3 with vue3 too
The flicker issue (on webpack at least) is related to the missing SSR critical CSS collection in vue-loader v16. I have managed to work around this by using a fork which adds naive inlining: https://github.com/phoenix-ru/vue-loader. I've written it for Vue 3 SSR but turns out that this also works for Nuxt 3. The Bridge works without any FOUCs though.
turns out that this also works for Nuxt 3.
Can you explain usage?
You need to install the packaged tarball in place of vue-loader and check that npm resolves to the patch.
npm i -D vue-loader@https://github.com/phoenix-ru/vue-loader/releases/download/critical-css/vue-loader.tgz
npm ls vue-loader
Beware that this patch only works for webpack (config.vite=false
) and may introduce style duplication with Nuxt (or may not)
You can check the source code at https://github.com/phoenix-ru/vue-loader/tree/critical-css. Sorry for an inconvenient structure, this is a dirty patch and I had no time to update it for a merge request.
npm ls vue-loader
βββ¬ nuxt3@3.0.0-27386975.6e06d2b invalid: "latest" from the root project
β βββ¬ @nuxt/webpack-builder@npm:@nuxt/webpack-builder-edge@3.0.0-27386975.6e06d2b
β βββ vue-loader@17.0.0
βββ vue-loader@16.8.2 invalid: "https://github.com/phoenix-ru/vue-loader/releases/download/critical-css/vue-loader.tgz" from the root project
npm ERR! code ELSPROBLEMS
still good? I am using yarn and add this as a dependency instead of a dev dependency
npm ls vue-loader
βββ¬ nuxt3@3.0.0-27386975.6e06d2b invalid: "latest" from the root project β βββ¬ @nuxt/webpack-builder@npm:@nuxt/webpack-builder-edge@3.0.0-27386975.6e06d2b β βββ vue-loader@17.0.0 βββ vue-loader@16.8.2 invalid: "https://github.com/phoenix-ru/vue-loader/releases/download/critical-css/vue-loader.tgz" from the root project npm ERR! code ELSPROBLEMS
still good? I am using yarn and add this as a dependency instead of a dev dependency
Seems like Nuxt has updated the loader to v17. I guess you could still use it?..
Seems like Nuxt has updated the loader to v17. I guess you could still use it?..
Doesnt seem like it. Additionally, I cant even import things like windi-css which use virtual to mount css (which cannot be resolved in a style context). Proper style resolution is the only thing, as far as I can see that is stopping nuxt3 from being used in production, mainly because of the weird initial flicker that visitors experience.
I am not really sure, but I think docs need to be updated then to indicate what is the role of app.vue other than replacing a single layout file.
The docs apparently do suggest the same, https://v3.nuxtjs.org/docs/directory-structure/app
Remember that app.vue acts as the main component of your Nuxt application. Anything you add in it (JS and CSS) will be global and included in every page.
I cant even import things like windi-css which use virtual to mount css
Could you elaborate more on that please?
The patch I did is naive and works by providing the styles from the SFC to the SSR context in a beforeCreate
hook via importing the SFC dependencies. It was initially developed to overcome the FOUC when loading modules through Webpack 5 Module Federation.
Note that it does not really inject the styles, as that is done by Nuxt, but only provide them to the context (and that's the reason I assume that I move in the right direction). The critical CSS collection is tricky and hasn't been solved since the introduction of vue-loader v16.
I know that windicss uses JIT-like compilation, but I haven't checked their webpack implementation (https://github.com/windicss/windicss-webpack-plugin).
I'd really like to contribute to Nuxt and to Vue renderer in general by solving this problem because we already invested a big chunk of time and resources and seeing Nuxt introduce breaking changes is something we really want to avoid.
P.S. I have no information about the Vite implementation and will not be looking there.
I cant even import things like windi-css which use virtual to mount css
Could you elaborate more on that please?
Ah apologies, I didnt intend to point anything on your implementation, my statement was more in general towards nuxt.
I just tested vite with windicss, and it actually seems to work as intended. (Granted i still cant use taildwindcss/ui with windicss). Overall my intention was that anything that goes to the css field in config, should also be uglified if possible. (https://github.com/FortAwesome/vue-fontawesome/issues/342, this issue is a thorn on my end, as the css is shipped in js somehow, and is very large in size) Lighthouse even complains for the same.
When will it be resolved??
When will it be resolved??
In october 2021 i used i think
// build: {
// optimization: {
// runtimeChunk: true,
// splitChunks: {
// maxSize: 240000,
// name: true,
// cacheGroups: {
// styles: {
// name: 'styles',
// test: /\.(css|vue)$/,
// chunks: 'all',
// enforce: true
// }
// }
// }
// }
// },
I've tried quite a few different things to try to resolve this issue on my own project;
1) Add the css file in an app.vue
file
2) Add the css to the default.vue
layout
3) Import it in the style
block
4) Original css import in Nuxt.config
did not seem to work
Basically, css seemed to work fine in nuxtjs. But, after adding Nuxt Bridge, we get that flash of un-styled pages when doing a hard refresh of the browser.
Haven't found a solution. Pretty much stuck at this point.
I've tried quite a few different things to try to resolve this issue on my own project;
Hi, in my setup everything works fine when adding it via SCSS to layouts/default.vue
and all other layout files (Nuxt Bridge):
<style lang="scss">
@use './my_styles.css';
</style>
I've tried quite a few different things to try to resolve this issue on my own project;
Hi, in my setup everything works fine when adding it via SCSS to
layouts/default.vue
and all other layout files (Nuxt Bridge):<style lang="scss"> @use './my_styles.css'; </style>
Thanks for the reply, but this did nothing for me. I even tried setting the styles directly in the default.vue
file for my default layout, but this also did nothing. It has something to do with processing the style and setting it before the screen renders. This has never been a problem before attempting to update to bridge
.
As it is, this, as well as an issue with nuxt auth
compatibility makes bridge
a non-starter for our app.
I've tried quite a few different things to try to resolve this issue on my own project;
Hi, in my setup everything works fine when adding it via SCSS to
layouts/default.vue
and all other layout files (Nuxt Bridge):<style lang="scss"> @use './my_styles.css'; </style>
HI, this works for me, but I get a new error when my CSS is from my node_modules with relative paths for font-files, like the bellow screenshot.
I've tried quite a few different things to try to resolve this issue on my own project;
Hi, in my setup everything works fine when adding it via SCSS to
layouts/default.vue
and all other layout files (Nuxt Bridge):<style lang="scss"> @use './my_styles.css'; </style>
HI, this works for me, but I get a new error when my CSS is from my node_modules with relative paths for font-files, like the bellow screenshot.
This is not related to the topic, but I had the same issue.
If that is your library, make sure you either set webpack's publicPath
to the name of your library (e.g. publicPath: '@yourscope/yourlib'
) or you do a construction like this:
// your_library.scss
$module-path: '@' !default; // or any alias to project root
// same file, in your font-face definition
src: url(#{$module-path}/path/to/font)
// when consuming (e.g. in nuxt)
@use '@yourscope/yourlib/your_library.scss' with (
$module-path: '@yourscope/yourlib'
);
@pi0 Any ideas for us on this one? Whenever I do a hard refresh, I get about a second of the app being unstyled. Wondering what the solution might be.
My solution for now was to remove this from my nuxt.config.ts
css: [
`~/assets/scss/index.scss`,
],
And add this to my layouts/default.vue
<style lang="scss">
@import '~/assets/scss/index.scss';
</style>
@justindasilva I have the same issue. I tried your solution but it didn't worked for me. I'm still seeing my app being unstyled for a second after hard refresh. I'm using nuxt bridge with tailwind.
Do you have or does anyone have a suggestion or workaround for this?
I also have this issue, but when disable nitro - it works fine (inlines css in SSR):
export default defineNuxtConfig({
...
bridge: {
nitro: false,
}
})
I tried disabling the nitro and it works. I no longer encountered unstyled components for a second after reloading the page. Is there other way to fix it without disabling the nitro?
Disabling nitro is not the solution as well as placing CSS in layouts, all of that are dirty workarounds. Nuxt Bridge should support it's default feature of referencing CSS files in nuxt config.
@danielroe any ETA for this fix? Could it be prioritized for RC11 ?
Just looking into this, I can't reproduce - in production - with the following config:
import { defineNuxtConfig } from '@nuxt/bridge'
export default defineNuxtConfig({
bridge: {
nitro: true,
vite: false
},
})
Note that:
@danielroe yes, that's correct, the issue is reproducible only in development mode with Webpack, but it has to work the same as in production, right?
@danielroe is there any issue where I could track progress on adding inline styles for Vite?
This still seems to be an issue on Bridge 3.0.0-27833237.ddd8ecc
with Nitro(nuxi), running yarn build && yarn start
Even with this config: https://github.com/nuxt/bridge/issues/26#issuecomment-1256707353
Would you be able to provide a reproduction? π
This issue was closed because it was open for 7 days without a reproduction.
Environment
Darwin
v14.17.4
2.15.8
npm
Webpack
head
,css
,plugins
,bridge
,components
,buildModules
,modules
,build
cookie-universal-nuxt@2.1.5
,@nuxtjs/axios@5.13.6
Build Modules:
@nuxt/bridge@3.0.0-27237089.3e38eb8
Describe the bug
TailwindCSS plugins requirements are not being loaded as they should, being run only after the plugin has been rendered. For this specific case, I'm using the TailwindCSS framework which is being enhanced by DaisyUI.
However, there is an initial flicker from TailwindCSS styling to DaisyUI after the page loads. See below recording:
https://user-images.githubusercontent.com/61620873/137582807-4ec2eec8-ab0a-437c-a15d-642447fda13a.mov
I brought up this issue on the DaisyUI repo here: https://github.com/saadeghi/daisyui/issues/249, but the creator noted that it was an issue with a lack of details on Nuxt 3 and Bridge documentation. They provided a working example for Nuxt 3 in addition to that for Nuxt 2, but neither is functional in Bridge.
Reproduction
Modified NuxtJS Bridge example.
Additional context
No response
Logs
No response