Is there a bodyParser.urlencoded({ extended: true } equivalent in Hono?

[charnould]

Hello,
I'm making my move from Express/node.js to Hono/Bun, and it feels refreshing!
Some stuff are really nice and useful: for example: set()/get()!
But sometimes, I'm struggling...

Consider the simple c.req.parseBody() below:

{
  id: "123456"
  "timeslots[0][start]": "",
  "timeslots[0][end]": "",
  "timeslots[1][start]": "",
  "timeslots[1][end]": "",
  "timeslots[2][start]": "",
  "timeslots[2][end]": "",
}

With express, it is automatically parsed using bodyParser.urlencoded({ extended: true }, and timeslots is returned as an array.

Maybe I'm missing something, but is there something equivalent in hono? Thanks.

[yusukebe]

Hi @charnould!

Thank you for using Hono.

Maybe I'm missing something, but is there something equivalent in hono?

Hono doesn't automatically parse them as an array like Express. Actually, c.req.parseBody() is just a shortcut to manipulate req.formData(), which returns a FormData object:

FormData - Web APIs | MDN

You can use the FormData object directly like this:

const formData = await c.req.formData()
const timeslots= formData.getAll('timeslots'))

I'm not sure if this will give you the result you expect, so please give it a try and let me know if it works or not.

[charnould]

@yusukebe

Thanks for your help. Unfortunately, it doesn't :-)
I've posted a question on Stack Overflow, but current answer looks super complicated for something that was a bodyParser.urlencoded({ extended: true }-away with express.

Don't you think it could be a hono feature?

[charnould]

@yusukebe
I saw your smiley reaction (👀) but don't know how to interpret it 😅...
Is my suggestion a bad idea? Or maybe SO answer looks super-simple to you?
Let me know (if you want, I can close this comment).

[yusukebe]

Sorry.

Current my thought is it's not within Hono's scope. If you want to do that, you can make the shortcut method by yourself.

But, I was thinking it's a good idea to make an "Extended Body Parser Middleware". So, it's no problem to keep this issue still opened.

[joshamaju]

I think you can get the same result by using:

import qs from 'qs';

// ...

const text = await c.req.text()
const data = qs.parse(text);

[krsbx]

@yusukebe is it possible to add qs to hono? Probably like if the user pass the argument to parse it with qs then it will parse it automatically

const body = await c.req.json({ extended: true });

and inside the request.ts we can do it this way

async json<T = any>(parse:? { extended?: boolean; options?: Nonullable<unknown> }): Promise<T> {
    const body = await this.cachedBody('json');
    
   if (!parse || !parse.extended) return body;
   
   const qs = require('qs');
   return qs.parse(body, parse?.options);
 }

we also can create our own implementation of qs instead of relying on it if we want hono not relying to other library/modules

if someone agree with this idea, probably will try to make a PR for it

[yusukebe]

Hi @krsbx,

Thank you for the suggestion. But, the answer is no – we can't add qs nor port it directly.

Firstly, Hono should not depends on external libraries. Secondly, introducing functionality like qs would be more of a "Helper" due to it will increase the amount of code. Nevertheless, if you have a use case that requires its functionalities, you can directly use qs alongside Hono.

[krsbx]

@yusukebe how about if I make a PR where a middleware reassign the json and text function from c.req so it will parse it automatically? I'll try to create my own version of qs

[yusukebe]

Hi @krsbx,

I think it's not good for a middleware to extend the json or text function. Such behavior might lead to confusion among users as they might wonder if functions are being extended or not. With this same reason, other middleware do not add an additional function from Context like a c.someClientMethod().

[krsbx]

@yusukebe, @charnould just made a PR so we can have some sort of qs in hono out of the box in #1389