Replies: 3 comments 4 replies
-
|
I agree with you. I am struggling because useState and pinia are not available while configuring server middleware. Importantly, the Nuxt3 document does not accurately point out that Nitro and Nuxt servers should be thought of separately. |
Beta Was this translation helpful? Give feedback.
-
|
i found NuxtApp is isolated from NitroApp , I setup a global variable in nitro server, but can't get the value from Nuxt APP server side! |
Beta Was this translation helpful? Give feedback.
-
|
Here is an overview of what Nitro does vs. what Nuxt does. The separation between "API routes" that don't need Nuxt to be ran at all, versus Nitro "booting up" the Nuxt application, which then might server-render or not (depending on settings) is important to separate concerns, enable features like cached functions easier etc. |
Beta Was this translation helpful? Give feedback.
-
|
@TheAlexLichter - I'm having an issue here where I'm developing a module and need to inject a static variable into the event context for a handler that my module adds (addServerHandler or addDevHandler). There seems to be some life cycle hang up here. Injecting variables to run time context like: or Don't appear at runtime in the added handler's event context. I'm confused about how a module should inject necessary context variables? |
Beta Was this translation helpful? Give feedback.
-
|
A repro would be appreciated! |
Beta Was this translation helpful? Give feedback.
-
|
here's a repo: Just look at the server output when you start the project. Expected output would be to get the same path at handler registration as at runtime. |
Beta Was this translation helpful? Give feedback.
-
|
@TheAlexLichter - I just realized that link doesn't share the playground as I would expect. I've downloaded it and shared the repo here: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm kind of confused as to the working of nitro with Nuxt. With Nuxt 2, you had a server layer and a client layer. You separate that disparity with something like
proces.clientorprocess.server.With Nuxt 3 you have a Nuxt plugin which also utilizes the same principles as Nuxt 2, but with an additional layer or what I'd like to believe is an additional layer, which is nitro's server, which is inaccessible in Nuxt's context. It feels like with:
Nuxt 2 you went like this:
Sever -> ClientNuxt 3 feels like:
Nitro Server -> Server (?) -> ClientWith that setup in mind, it feels like an unnecessary step is being added to Nuxt, because you have nitro plugins which cater to the nitro setup and has limited to no access to Nuxt's layer. Then on top of that you have Nuxt plugins which does have some semblance of server access, but not towards nitro because if you're using some like a server middleware you can't just use
process.serverin the plugin because it won't be available in nitro's lifecycle since it runs before Nuxt initializes nor does any of Nuxt's features work in the server middleware.Likewise things you do in nitro doesn't translate over to Nuxt's side all that well, also you kind of have to create 2 variants of the same plugin to handle both nitro and Nuxt where both of them do the same thing. On top of this there's 2 layers of middleware here; Nuxt middleware, and Nitro's server middleware, both of which doe what middlewares do, but the Nuxt middleware also accepts
process.severbut also doesn't have access to nitro?It's a bit confusing to have this kind of setup.
Beta Was this translation helpful? Give feedback.
All reactions