How to handle multiple forms schema on the same route [REMIX]

[Joseamica]

Hi, on the same route, I'm managing to add, update and delete, my schema validates if the name, type, currency, and id are not empty on add and edit, but on delete, i don't need that values, i need only the id to delete, how i manage different schemas?

  const [form, fields] = useForm({
    id: 'menus',
    constraint: getFieldsetConstraint(menuSchema),
    lastSubmission: fetcher.data?.submission,
    onValidate({ formData }) {
      return parse(formData, { schema: menuSchema })
    },
    shouldRevalidate: 'onBlur',
  })

schema:

  const menuSchema = z.object({
  id: z.string(),
  name: z.string().min(1).max(20),
  type: z.string().min(1).max(20).optional(),
  currency: z.string().min(3).max(3),
})

[edmundhung]

You can make the id field optional and set a custom name / value on each buttons. When user click on these button, it's corresponding value will be added to the formData which you can access on your action:

async function action({ requset }) {
  const formData = await request.formData();
  // The name can be anything. `operation` is just an example  
  const operation = formData.get('operation');

  // ... parse formData as usual
}

function Example() {
  return (
    <form>
      {/* ... */}
      <button name="operation" value="add">Add</button>
      <button name="operation" value="edit">Edit</button>
      <button name="operation" value="delete">Delete</button>
    </form>
  );
}

[justintoman]

Could/should this be done with conform.INTENT instead? Or is that not what that's for?

Also could a zod union work here?

const AddSchema = z.object({
  operation: z.literal('add'),
  ...
});

const EditSchema = z.object({
  operation: z.literal('edit'),
  ...
});

const DeleteSchema = z.object({
  operation: z.literal('delete'),
  ...
});

const SchemaUnion = z.discriminatedUnion('operation', [
  AddSchema,
  EditSchema,
  DeleteSchema
]);

async function action({ request }) {
  const submission = parse(await request.formData(), { schema: SchemaUnion });
  switch(submission.value?.operation) {
  ...

I tried this and couldn't get it to work if I used conform.INTENT because I guess that's a special key, but if I used something else (like operation) for the union discriminator then it seems to work.

EDIT: I forgot about fetchers 😅 First time diving back into Remix in a while, and I forgot the action data will be on the fetcher, so I don't have to do this crazyness.

Only weird bit is the lastSubmission.

const actionData = useActionData<typeof action>();
const lastSubmission =
    actionData && 'value' in actionData && actionData.value?.operation === 'change-password' ? actionData : undefined;

That code is kind of a pain, and it doesn't seem to narrow the type, though that doesn't matter because I'm just passing it into useForm. I tried messing around with extracting it to a function but the generics were too tricky for me. Feels like I'm making it more complicated than it needs to be, but I'm new to the library so there's probably something simpler.

[justintoman]

Looking back at this, I really wish you could use conform.INTENT for this because of the behavior where it removes from the form submission value.

I've gotten in the pattern of making my API functions accept the same type as a the form so I can do stuff like createThing(submission.value); and I don't want the intent to be included with that. So the way conform parsing works is perfect for this!

But I believe using conform.INTENT would prevent that field from working as a discriminator in a zod discriminated union, which is annoying because you don't have access to submission.intent until after you parse, which requires a schema, which you can't know until you get submission.intent. Plus, it's kinda weird to manually get it out of formData because then you have to check if it's a string.

const intent = formData.get(conform.INTENT)

// check that intent is a string manually
if (typeof intent !== 'string') {
  return json('Invalid submission', 400);
}
  
switch(intent) {
  case 'foo': {
    const data = parse(formData, {schema: FooSchema});
    ...
  }
  case 'bar': {
    const data = parse(formData, {schema: BarSchema});
    ...
    

Any plans for making this part of @conform-to/zod? I'd be happy to contribute.

[edmundhung]

Using either conform.INTENT or a custom discriminator is pretty much the same. As you mentioned, the major difference on using conform.INTENT is that it would be removed from the formdata before it is parsed by the zod schema, that's why it couldn't be identify on a discriminated union. But you can still achieve something similar by preparing a schema creator to the parse function:

async function action({ request }) {
    const formData = await request.formData();
    const submission = parse(formData, {
        schema: (intent) => {
            switch (intent) {
                case 'add':
                    return z.object({
                        // add schema,
                    })
                case 'edit':
                    return z.object({
                        // edit schema,
                    });
                default:
                    throw new Error('invalid intent')
            }
        },
    });

    // ...
}

Also, zod ignores unknown fields by default. I don't see there is any real benefit of using conform.INTENT in this case.

[edmundhung]

Thinking about this again. It might be best using a discriminated union here as it would be possible to narrow down the type with a simple switch case.

const schema = z.discriminatedUnion('type', [
  z.object({
    operation: z.literal('add'),
    // ... add fields
  }),
  z.object({
    operation: z.literal('edit'),
    // ... edit fields
  }),
  z.object({
    operation: z.literal('delete'),
    // ... delete fields
  }),
]),

async function action({ requset }) {
  const formData = await request.formData();
  const submission = parse(formData, { schema });

  if (submission.intent !== 'submit' || !submission.value) {
    return json(submission, { status: 400 });
  }

  switch (submission.value.operation) {
      case 'add':
          // ... add logic
          break;
      case 'edit':
          // ...edit logic
          break;
      case 'delete':
          // ... delete logic
          break;
  }
}

function Example() {
  return (
    <form>
      {/* ... */}
      <button name="operation" value="add">Add</button>
      <button name="operation" value="edit">Edit</button>
      <button name="operation" value="delete">Delete</button>
    </form>
  );
}

[adaboese]

Shouldn't this be based on intent?

[jmaldon1]

Main issue I see with this approach is that any custom error messages need another if/else tree

const schema = z.discriminatedUnion('type', [
  z.object({
    operation: z.literal('add'),
    // ... add fields
  }),
  z.object({
    operation: z.literal('edit'),
    // ... edit fields
  }),
  z.object({
    operation: z.literal('delete'),
    // ... delete fields
  }),
]),

async function action({ requset }) {
  const session = await getSession(request.headers.get("Cookie"));
  const formData = await request.formData();
  const submission = parse(formData, { schema });

  if (submission.intent !== 'submit' || !submission.value) {
    if (submission.payload.type === "add") {
      setErrorToastMessage(session, "Error adding.");
    } else if (submission.payload.type === "edit") {
      setErrorToastMessage(session, "Error editing.");
    } else {
      setErrorToastMessage(session, "Error");
    }
    return redirect(".", {
        headers: {
          "Set-Cookie": await commitSession(session),
        },
      });
  }

  switch (submission.value.operation) {
      case 'add':
          // ... add logic
          break;
      case 'edit':
          // ...edit logic
          break;
      case 'delete':
          // ... delete logic
          break;
  }
}

function Example() {
  return (
    <form>
      {/* ... */}
      <button name="operation" value="add">Add</button>
      <button name="operation" value="edit">Edit</button>
      <button name="operation" value="delete">Delete</button>
    </form>
  );
}

[mfo-fluxer]

I'm doing something similar but using useFetcher<typeof action>for multiple different forms on the same page.
What would you suggest I return inside each of the switch cases? I need e.g. a name returned on add, but something else in different cases (operations).

Let me know if my question is unclear 😃