How to do fieldlist "partial successful" form subission (v1)?

[EmilEinarsen]

I want to be able to perform a multi create, where the user can add and remove items as needed, utilizing getFieldList, form.insert, form.remove.
Submitting this form could have three outcomes:

• All errors -> Show errors
• Partial success -> Show errors, and remove successful fieldList items.
• All success -> Reset form

How do remove successful field items, while showing errors?

---

I tried a couple of approaches for this:

1. Hiding fieldList items

Didn't work since hiding field elements didn't effect the fieldList items.

const fieldsetSchema = z.object({ name: z.string() })

const formSchema = z.object({
	items: z.array(fieldsetSchema).nonempty(),
})

export const action = () => {
	/* ... */

	if (/* all errors */) {
		return json({
			result: submission.reply({ fieldErrors, formErrors }),
		} as const)
	}

	if ((/* errors and success */) {
		return json({
			result: submission.reply({
				fieldErrors,
				hideFields: successIndices.map(i => `${fieldName}[${i}]`),
			}),
		)
	}

	// All success
	return json({
		result: submission.reply({
			resetForm: true,
		}),
	})
}

2. Reseting with failed items as defaultValue

Didn't work since reseting the form doesn't allow errors.

/* ... */

export const action = () => {
	/* ... */

	if ((/* errors and success */) {
		return json({
			result: submission.reply({
				resetForm: true,
				fieldErrors, // Need to add this here
			}),
			defaultValue: submission.reply({
				hideFields: successIndices.map(i => `${fieldName}[${i}]`),
			}).initialValue,
		)
	}
	
	/* ... */
}

export default function Component()  {
	const actionData = useActionData<typeof action>()

	const [form, fields] = useForm({
		defaultValue: actionData?.defaultValue || {
			items: [{}],
		},
		lastResult: actionData?.result,
		/* ... */
	})
	
	/* ... */
}

3. Remove successful fieldList items

Track the indices of the successful fieldList items and form.remove them. Didn't work since this removed the errors.

/* ... */

export const action = () => {
	/* ... */

	if ((/* errors and success */) {
		return json({
			result: submission.reply({
				fieldErrors
			}),
			hiddenIndices
		)
	}
	
	/* ... */
}

export default function Component()  {
	const actionData = useActionData<typeof action>()

	/* ... */
	
	useEffect(() => {
		if(!actionData?.hiddenFields) return
		for (const index of actionData.hiddenFields)
			form.remove({ name: fields.items.name, index })
	}, [actionData?.hiddenIndices])

	/* ... */
}

4. Manually hide successful fieldList items

Track the indices of the successful fieldList items and don't render them.

/* ... */
const fieldsetSchema = z.object({ name: z.string() })

const formSchema = z.object({
	items: z.array(fieldsetSchema.optional()).nonempty(), // fieldsetSchema is optional to allow the hidden fieldList items
})

export const action = () => {
	/* ... */

	if ((/* errors and success */) {
		return json({
			result: submission.reply({
				fieldErrors
			}),
			hiddenIndices
		)
	}
	
	/* ... */
}

/* ... */

export default function Component()  {
	const actionData = useActionData<typeof action>()

	/* ... */

	const items = fields.items.getFieldList()
	
	// don't render item indices included in actionData?.hiddenIndices
	/* ... */
}

The last approach ended up working, but feels convoluted.
Personally, I like the first approaches the most since it feels like it should be supported by the API.

[edmundhung]

This doesn't sounds like a common pattern to me. Would it be better to have each item an individual form so you don't have to deal with partial success but just a list of forms that are either success or failure?

The hideFields options is a workaround to deal with sensitive data you don't want the server to send back to the client (e.g. password) and have no impact on the client. I would expect the 3rd approach to work as well. Can you share more details?

[EmilEinarsen]

Yeah, now that you mention it, approaching it like multiple forms instead of an formList makes a lot of sense.

However, the reasoning behind doing a "bulk create" is to only have a single submit button and to reduce the number of requests necessary.

Is there a way natively/accessibly trigger multiple forms with one submit button?

[EmilEinarsen]

Approach 3 seems to have a couple of issues:

1:
Using form.remove seems to empty the fieldList items after the index.

Example w/ video

ex. fieldList of 4 items. The user removes index 1 with `form.remove`, which causes index 2 and 3 to be empty.

screencast-localhost_3001-2024.01.25-22_41_08.webm

2:
form.remove, form.insert causes the form error state to disappear

Example w/ video

1. Submit leads to error state. Click `form.remove`, `form.insert` causing the fieldList to change. The error state is lost 2. Submit leads to error state. One fieldList item is successful and removed with useEffect and `form.remove`. The error state is lost

screencast-localhost_3001-2024.01.25-23_07_55.webm

[edmundhung]

The first issue is caused by a bug on how key for nested fields are derived. If you are not using the reset or update intent at the moment, you can try overriding the key to undefined like this:

<input {...getInputProps(fields.something, { type: 'text' })} key={undefined} />

I will try to get this fixed tonight.

For the second issue, I am not sure about the issue when you insert a new item. But I notice the errors printed below is wrong when you remove:

At 0:26, the error object looks like this:

{
  "emails[0]: ["No Type selected"]
}

But if you refer to the initialValue, your form structure looks like this:

{
  emails: [
    { email: '...', type: '...' },
  ],
}

If you expect the error to be populated on the type field, the error object should look like this:

{
  "emails[0].type: ["No Type selected"]
}

You can probably fix this by adjusting how you set the error with fieldErrors.

[EmilEinarsen]

Cool, I'll take another look at the implementation once the fix is in.

Thank you for taking the time to look into my case. I'm loving the experiance of developng using Conform, and it's only becoming better and cooler with everyday.

---

The error message being on the emails[0] is intentional since it's from an external BE and I'm not always sure what field it belongs to.
In the example it was a "fieldset level error".

When mapping the errors I try to be as specific as possible and bubble up to the form otherwise.

response.errors.forEach(value => {
    const index = fieldsets.findIndex(fieldset => mapResponse(fieldset, value))
    
    const fieldsetError = mapError?.(value) ?? {}
    fieldsetError.message ||= value.message ?? 'Unknown error'
    if (fieldsetError.fieldName)
        fieldErrors[`${fieldName}[${index}].${fieldsetError.fieldName}`] = [
            fieldsetError.message,
        ]
    else if (index === -1) formErrors.push(fieldsetError.message)
    else fieldErrors[`${fieldName}[${index}]`] = [fieldsetError.message]
})

Might the error be removed because of a similar key bug on <fieldset {...getFieldsetProps(props)} >?

<FormProvider context={form.context}>
    <Form method="POST" {...getFormProps(form)}>
        <ul>
            {records.map((props) => {
                const fieldset = props.getFieldset()
                return (
                    <li key={props.key}
                        <fieldset  {...getFieldsetProps(props)} >
                            <div className="grid gap-x-4">
                                <Field name={fieldset.name.name} label="Name" /> // fieldset field error
                            </div>
                            
                            <ErrorList errors={props.errors} id={props.errorId} /> // fieldset error
                        </fieldset>
                    </li>
                )
            })}
        </ul>
        <FieldList.AddItem
            addButtonProps={form.insert.getButtonProps({
                name: fields.records.name,
            })}
        />
        
        <ErrorList errors={form.errors} id={form.errorId} /> // form error
        
        <Button  type="submit">Create</Button>
    </Form>
</FormProvider>

[edmundhung]

v1.0.0-rc.1 is out with a fix for the key issue.