Question: form-atoms?

[wuleninja]

Hi guys, and thanks for this library!

I'm quite new in React, and currently looking at solutions for handling forms. I've tried the likes of RHF / Tanstack Form based solutions, but always to find them waaaayyy too boilerplatey.

I've always had Jotai in mind for state management in general - I've been genuinely impressed with the tutorial showing how to dev a kind of Paint app - so I wondered: why not for forms??

But then I come accross this lib, which seems to be the most standard, the "official" one, and this: https://github.com/form-atoms/form-atoms.

Do you have any opinion about the latter? It kinda looks good but I'm less confident in the long run due to it not being officially part of the Jotai project. Do you have any plan to incorporate some of its ideas that make sense?

[barelyhuman]

While I would be biased since I maintain the official one, it would be wrong to say that form-atoms isn't a nice library to pair with jotai.

The goal of this library is to be UI library agnostic and be compatible with Jotai's v2 API which allows you to use jotai with even vanilla javascript.

Though, if boilerplate is the issue, most form libraries will have some form of boilerplate.

We realise this and there's a small effort to use validation libraries as the source of truth https://github.com/jotaijs/jotai-form/pull/30 instead.

Bottom point, you are free to use either form-atoms or jotai-form, if you like the experience of using jotai, it's not hard to write wrapper around atoms to make it easier for later

Hope that helps you in some way

[wuleninja]

Wow thank you for this ultra quick answer, I really appreciate that! I'm really sensitive to the argument of this library being the official one. This is really important. It's not completely clear to me what you want to achieve with #30, I had already ready about it prior to making this issue. What are the missing "type inference hacks", and what challenges do you have with "Mixed and Object schema forms"? Thanks again a thousand times!!

[barelyhuman]

To be put simply, the draft pr works but isn't having the best DX and a lot of information is lost right now.

For example, If you are aware of the library zod then you can write validation schemas like so.

z.object({
  age: z.number()
})

With #30 implemented, we can use that to create a form control atom like so

const formAtom = atomFromZodSchema(z.object({
 number: z.number()
}))

function Component(){
  const { fieldErrors, isDirty, isValid, values, handleOnChange } = useAtomValue(formAtom);

   return <input value={values.age} onChange={e=>handleOnChange("age")(e.target.value)}) />
}

Now the thing is , that's all it can do right now, a single depth object is easy to infer and create a form atom from. The same isn't true for mixed schema that you can create with zod and yup.

For example, if we take the following schema

const nestedSchema = z.object({
  user: z.object({
     name: z.string.required()
  })
})

While this would work, handleOnChange("user")(value) would be all that'd work in terms of a change. Being able to change the value of user.name would be a lot more work for both jotai-form and honestly we don't recommend doing that in jotai but then it's valid in zod hence the 2 pending tasks

[wuleninja]

Thanks for this answer.

I'm not a big fan of changing a relationship's property directly anyway, that's not a very good practice from a REST perspective in my opinion.

[barelyhuman]

But other form libraries support creating nested forms based on property defs and that'd be the immediate next issue if I didn't actually implement it.

An example implementation of the same is something I'm trying out in my projects to see the limitations so that it's easier to reason about later.

Till then, the boilerplate on both form-atoms and this library is very much the same