[Suggestion] Form improvement

Hi,
to my point of vue Redwood Form implementation could improve verbosity and separation of concerns.

Isn’t it possible to wrap Label, Input and FieldError in the same component ?

Also, Isn’t it possible to Let the Higher Form make validations with external validation functions that keep business (or technical) validation logic (or wording) in a separated place ?
For this purpose, I’ve made a POC library (caution : very very disgusting code ^^) that try to respond to that needing : https://www.npmjs.com/package/react-form-lib

It would be great if Redwood supported a feature like that in the future to writing a form without have to add or insert some extra logics in it.

to explain my propos :

actual form like this :

<Form
	onSubmit={onSubmit}
	validation={{ mode: 'onBlur' }}
	error={error}
	formMethods={formMethods}
>
	<FormError
	  error={error}
	  wrapperStyle={{ color: 'red', backgroundColor: 'lavenderblush' }}
	/>
	<Label name="email" errorClassName="error">
	  Email
	</Label>
	<TextField
	  name="email"
	  validation={{
		required: true,
		pattern: {
		  value: /[^@]+@[^.]+\..+/,
		  message: 'Please enter a valid email address',
		},
	  }}
	  errorClassName="error"
	/>
	<FieldError name="email" className="error" />
</Form>

would become more readable (wrapped) and maintenable (separated) :

<Form
	onSubmit={onSubmit}
	validationRules={externalValidationFunctionByInputName} //<== see below
	error={error}
	formMethods={formMethods}
>
	<FormError error={error} />
	<FormItem
	  type="TextField"
	  name="email"
	  label="The Email"
	  sublabel="Only support redwood domain mail ;-)"
	  ...whatever
	/>
		<input /> //(or custom <Input/> component)
	</FormItem>
</Form>

Here the validation could be performed by Form component itself and FieldError rendered in FormItem if errors exists.

externalValidationFunctionByInputName :
It is just a declarative object to reference all validation rules by declared field name in Form. the benefit is a better maintenability of a big application with a lot of forms.

{
  email: [ //<== the "name" of the field
			{
				key: "email_empty", //<== the key of the rule
				message: "email is empty. Please enter it.",
				isValid: (value) => (isNotEmpty(value))  //<== this function is used by Form to validate field and render FieldError component if needed
			},
			{
				key: "email_invalid", 
				message: "email is not valid. Please enter it.",
				isValid: (value) => (matchAnyPattern(value)) 
			},
			{...etc}
		],
  otherFieldName: [
	{otherFieldFirstRule},
	{...etc}
  ]
}
1 Like

Hi @zb2oby and welcome to the Redwood community!

I have to say that as someone who tries to use forms as little as possible, any DX improvement is welcome … if I can avoid a form I try to or use a third party service (newsletters signups, Stripe payment forms, etc).

I have to say that I have not seen something like:

	<FormItem
	  type="TextField"
	  name="email"
	  label="The Email"
	  sublabel="Only support redwood domain mail ;-)"
	  ...whatever
	/>

before – is this implementation a take on something else?

One consideration I have is that “business logic” validation here is done 100% client side – and would still need to be replicated on the api side to prevent the service or handler from executing based on invalid data. This is also the case with the Redwood forms of course.

Also, might you be able to implement a redwood component called FormItem that wraps the input and adds a label, etc?

Let’s try to get the community in on this – especially those who use forms more than me.

Cheers.

Hi,
Thanks for replying

This implementation is inspired and i think is a mix between formik and ant-design implementations (https://ant.design/components/form/)

Indeed, business logic need to be replicated on backend like any service should.
This implementation is just trying to centralize all frontend validation logics to better maintenability.

Of course i could try to implement a Redwood component like this in the coming weeks if i find the time.

we stay in touch ^^

1 Like

Sounds good!

By the way, Redwood forms relies on react-hook-form

So that may give you some history around its design.