[Discussion] universal-middleware/hono

[fortezhuo]

I still don't get about universal middleware.

I have code like this using hono

export const preference = (): MiddlewareHandler => {
  return async function preference(c, next) {
    const cookiePreference = getCookie(c, "preference")
    const preference = cookiePreference
      ? JSON.parse(cookiePreference)
      : PREFERENCE
    c.set("preference", preference)
    await next()
  }
}

export const ssr = () =>
  vikeNode({
    pageContext: (c: Context) => {
      return {
        preference: c.var.preference,
        user: c.var.user,
        vendor: c.var.vendor,
      }
    },
    static: {
      root: distClient,
    },
  })

instance.use(preference())
instance.use(ssr())

And with universal-middleware, can I still use hono context using native behavior like c.var and c.set ?

[brillout]

@fortezhuo Does magne4000/universal-middleware#75 answer your question?

@magne4000 Maybe we can start documenting runtime at https://universal-middleware.dev/recipes/context-middleware.

It's currently undocumented because I'm still not sure what the actual user-facing API should look like for it.

Happy to help if you feel like you need a fresh perspective on it.

[fortezhuo]

Hm.. I still don't get how to use native behavior like c.var and c.set ? Maybe documentation with more examples will be great for better understanding

[magne4000]

@fortezhuo the "right" way to do that is with universal-middleware all the way:

import { type Get, type UniversalMiddleware } from "@universal-middleware/core";
// This lacks documentation, I'll fix this
import { createMiddleware } from "@universal-middleware/hono";
import { getCookie } from "@universal-middleware/core/cookie";

const preference = (() => (request, context, runtime) => {
  // Update Context
  return {
    ...context,
    preference: getCookie(request, "preference"),
    // ...
  }
}) satisfies Get<[], UniversalMiddleware>;

// universal Context is automatically applied to `pageContext`
instance.use(createMiddleware(preference)())

NOTE: c.var is currently not available in runtime, but I can easily add it if you need to @fortezhuo

It's currently undocumented because I'm still not sure what the actual user-facing API should look like for it.

Happy to help if you feel like you need a fresh perspective on it.

@brillout Started discussion magne4000/universal-middleware#76

Maybe documentation with more examples will be great for better understanding

👍 You're absolutely right. I'm on it

[brillout]

the "right" way

If the user wants to stay flexible about his server framework choice, then I agree.

If the user loves hono and wants everything to be hono, then I guess the right way is to always use Hono utilities instead of universal-middleware utilities? Will he still be able to deploy anywhere (if that isn't the case then it'd be great if we eventually teach the user about it)?

[magne4000]

If the user loves hono and wants everything to be hono, then I guess the right way is to always use Hono utilities instead of universal-middleware utilities?

I guess so? That would be a good reason to add back pageContext then. I don't really like it, but it kinda make sense, as it doesn't require users to learn about universal-middleware.

Will he still be able to deploy anywhere (if that isn't the case then it'd be great if we eventually teach the user about it)?

I think that if the chosen server can be deployed somewhere, using non universal middlewares shouldn't cause any issue.

[brillout]

I guess so? That would be a good reason to add back pageContext then. I don't really like it, but it kinda make sense, as it doesn't require users to learn about universal-middleware.

I was mentioning this a little bit last time we talked about it: my idea is that once vikejs/vike#1268 is implemented the user will never have to add things to pageContextInit anymore. Because it will include everything. The user will still be able to add initial props to pageContext by using the upcoming +onBoot and/or +onRequest hooks.

So I think we don't need to revive the pageContext() option.

I think that if the chosen server can be deployed somewhere, using non universal middlewares shouldn't cause any issue.

I guess Hono can be deployed anywhere. But Express.js cannot (and/or shouldn't) so maybe we should, eventually, add some kind of warning for Express.js in the future (maybe in Bati).

[magne4000]

[...] add some kind of warning for Express.js in the future (maybe in Bati).

I second that, a "portable" tag (like we have for "bleeding edge") could be great.

[brillout]

"portable" tag

Love it.

[brillout]

NOTE: c.var is currently not available in runtime, but I can easily add it if you need to

Maybe we should systematically add everything 🤔 I guess it's always nice if the user can access everything, otherwise universal-middleware may hinder him.

[fortezhuo]

I think that if the chosen server can be deployed somewhere, using non universal middlewares shouldn't cause any issue.

Thanks for reply. Currently I fallback and use 0.1.x version instead, and I hope using universal-middleware can be set as experimental feature. So user can choose using experimental feature or stay stable

[brillout]

Currently I fallback and use 0.1.x version instead, and I hope using universal-middleware can be set as experimental feature. So user can choose using experimental feature or stay stable

@magne4000 WDYT?

[brillout]

@fortezhuo We will revive the pageContext option.