refactor middleware

[huseeiin]

i deleted some stuff like deprecation warnings please tell me if they should stay
currently in v2 when you do:

import { createMiddleware } from "@solidjs/start/middleware";

export default createMiddleware({
    onBeforeResponse: (e, response) => {
        console.log(response);
    },
});

response.body is undefined
that is fixed
also, there's a new breaking change (relative to start v1): response is now Response instead of { body: ReadableStream | string } (ReadableStream if mode is "stream", string otherwise)

[changeset-bot]

🦋 Changeset detected

Latest commit: c575fda

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[netlify]

✅ Deploy Preview for solid-start-landing-page ready!

Name	Link
🔨 Latest commit	c575fda
🔍 Latest deploy log	https://app.netlify.com/projects/solid-start-landing-page/deploys/69675a282498f8000897c0b5
😎 Deploy Preview	https://deploy-preview-2047--solid-start-landing-page.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/solidjs/solid-start/@solidjs/start@2047

npm i https://pkg.pr.new/solidjs/solid-start/@solidjs/vite-plugin-nitro-2@2047

commit: c575fda

[katywings]

Imho the deprecation warnings should stay 🤔. Afaik the end goal is that users ideally will just use h3 middleware and we only keep createMiddleware for backwards compatibility.

[huseeiin]

Imho the deprecation warnings should stay 🤔. Afaik the end goal is that users ideally will just use h3 middleware and we only keep createMiddleware for backwards compatibility.

but how do they use h3 middleware?

[huseeiin]

tip for users, when you do this:

export default createMiddleware({
    onBeforeResponse: async (e, r) => {
        console.log(await r.text());
    },
});

and you're streaming, your stream will be deferred.
to avoid that, you can use h3's waitUntil but by then you've left the request and can't respond with your modified response.

export default createMiddleware({
    onBeforeResponse: (e, r) => {
        e.nativeEvent.waitUntil((async () => {
            console.log(await r.text());
        })());
    },
});

[huseeiin]

it seems this crashes with ERROR Worker error: Invalid state: ReadableStream is locked (only when Disable Cache is checked) when i refresh many times (will be fixed by h3js/srvx#158). converting to draft

[katywings]

Imho the deprecation warnings should stay 🤔. Afaik the end goal is that users ideally will just use h3 middleware and we only keep createMiddleware for backwards compatibility.

but how do they use h3 middleware?

To be honest, we still are debating it 😅. My plan is to write an RFC with a new API that will look somewhat like this:
https://github.com/katywings/solid-start/blob/727b61c0a0e13074dcf009298c08c2d391931f59/apps/fixtures/basic/src/entry-server.tsx#L20

In short: the user get's to create the h3 instance themselves and can do with it whatever they want. I will go into more detail about backwards compatibility, composability and more in my RFC. That said, this new API is completely my own idea and I don't know how it will be perceived by the community and team. If you already have your own idea's how it should look, I'd love to hear em 🙂.

P.S. @ryansolid's long term goal/idea is, to basically make Start completely server-framework independent, so Start would just return a handler that can be integrated into any WinterCG compatible framework. We have to keep that in mind when thinking about middleware related API's.

[huseeiin]

Imho the deprecation warnings should stay 🤔. Afaik the end goal is that users ideally will just use h3 middleware and we only keep createMiddleware for backwards compatibility.

but how do they use h3 middleware?

To be honest, we still are debating it 😅. My plan is to write an RFC with a new API that will look somewhat like this: https://github.com/katywings/solid-start/blob/727b61c0a0e13074dcf009298c08c2d391931f59/apps/fixtures/basic/src/entry-server.tsx#L20

In short: the user get's to create the h3 instance themselves and can do with it whatever they want. I will go into more detail about backwards compatibility, composability and more in my RFC. That said, this new API is completely my own idea and I don't know how it will be perceived by the community and team. If you already have your own idea's how it should look, I'd love to hear em 🙂.

P.S. @ryansolid's long term goal/idea is, to basically make Start completely server-framework independent, so Start would just return a handler that can be integrated into any WinterCG compatible framework. We have to keep that in mind when thinking about middleware related API's.

h3 v2 already exposes the app in .nativeEvent.app except it doesn't allow you to add routes (including middleware? i haven't checked) but i guess this is good in theory because more control is always better. but mixing config routes and file routes feels weird

[huseeiin]

this is ready but don't merge before ryansolid/dom-expressions#477