feat: Conform Validator Middleware

[uttk]

Added a validator that allows validation using conform.
Although the processing content is highly abstract and does not do much, it can increase the affinity with Hono RPC.

[changeset-bot]

🦋 Changeset detected

Latest commit: 8775f57

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

This PR includes changesets to release 1 package

Name	Type
@hono/conform-validator	Major

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

[yusukebe]

Hi @uttk !

Cool! I've tried it the feeling of usage is good. Also, It's great the implementation is simple. Before I review the details, I would like to know @chimame 's thoughts.

[chimame]

Before I write my thoughts, let me first say thank you.
This middleware will be very important for Hono to use Form with JSX. I am grateful for creating such a great middleware. 👍

If I were to create this middleware, I would create it with the same interface. I'm glad we're on the same page.

import { conformValidator } from '@hono/conform-validator'

conformValidator((formData) => parseWithZod(formData, { schema })),
// parseWithZod or parseWithYup or parseWithValibot

This allows middleware users to choose which Validator to use to validate form data, and makes it possible to validate form data with minimal code.

The process of returning errors is defined by the user each time, but how about a method to customize it by allowing an optional hook function to be passed as the second argument of the conformValidator function, just like other validators? If there is no hook function, a process to return the default error content defined by the middleware is necessary.

middleware/packages/valibot-validator/src/index.ts

Lines 48 to 60 in e488b9f

	if (hook) {
	const hookResult = hook(result, c)
	if (hookResult instanceof Response || hookResult instanceof Promise) {
	return hookResult
	}
	}
	if (!result.success) {
	return c.json(result, 400)
	}
	const data = result.output as InferOutput<T>
	return data

Also, although it may be limited to React, I think it would be a good idea to return the Conform SubmissionResult type, that is, submission.reply(), to the client to pass server-side errors to the client's form data.

const submission = c.req.valid('form')

if (submission.status !== 'success') {
  const res = c.json({ success: false, result: submission.reply() }, 400)
  throw HTTPException(400, { res })
}

[uttk]

@yusukebe @chimame

Thank you for reviews !

The process of returning errors is defined by the user each time, but how about a method to customize it by allowing an optional hook function to be passed as the second argument of the conformValidator function, just like other validators?

The optional Hook function is a great idea !
I would definitely like to implement it !

If there is no hook function, a process to return the default error content defined by the middleware is necessary.

As for the behavior when the hook function is omitted, I think it would be best to perform only validation, as with the current process, to prevent unintentional transmission of confidential information to the outside.

Also, I think error handling should be done carefully and should be implemented by the implementer himself, rather than leaving it to another library.

[uttk]

Hi @yusukebe .

I added hook option to conformValidator(). There is room for discussion regarding error handling and what happens when the hook is omitted, but I think the basic processing has been implemented.

cc: @chimame

[chimame]

Thank you for the great implementation.

I think that when there is a validation error in Conform, the default behavior should be return submission.reply(), as stated in the Conform documentation. If users of the middleware want to change this behavior, I think it would be a good idea to use the Hook function you implemented.

https://conform.guide/#the-gist

I think it would be best to perform only validation, as with the current process, to prevent unintentional transmission of confidential information to the outside.

I was thinking about what kind of assumptions you made in your opinion. I thought that this might be the case depending on the validation schema implementation of middleware users, but if that's the case, I think the same thing could happen with existing validation middleware.

I would like to respect your opinion, so I would like you to tell me in what kind of situations this could occur. I think it will also be useful for yusukebe's decision-making.

[uttk]

@chimame

I was thinking about what kind of assumptions you made in your opinion. I thought that this might be the case depending on the validation schema implementation of middleware users, but if that's the case, I think the same thing could happen with existing validation middleware.

That's true.

On second thought, I realized that since the other validator middleware already returns error responses by default, it would be more natural for this middleware to match the behavior.

I would like to modify the default behavior so that if a validation error occurs, the default behavior is to return an error response.

Thanks.

[uttk]

Fixed it.

[chimame]

Thank you for thinking about the API design together with me.

I think there's no problem with this implementation of the API for this middleware. Since it handles FormData, I wonder if we can make good use of hono/validator's FormData processing.

@yusukebe
I think there's no problem with this as a middleware design, so would you mind reviewing it in detail?

[yusukebe]

@uttk Great! I'll do it.

[yusukebe]

Hey @uttk

I've left some comments. Please check them!

@chimame Thank you for your reviews!

[uttk]

@yusukebe

Thank you for reviews!
I guess I was able to fix the issues you pointed out.

[yusukebe]

Hi @uttk

Thank you for some fixes. I've left two comments. There will be last. Check them!

[uttk]

@yusukebe

Thank you for your kind review.
I have corrected it.

[yusukebe]

LGTM!

[yusukebe]

@uttk @chimame Thank you!

Let's gooo! I'll merge and release it.