[RFC] - Similar Forms component to remix-forms

[paulm17]

To understand what remix-forms provides, please take a look at the following below...

Website (examples): https://remix-forms.seasoned.cc/
YouTube demo: https://www.youtube.com/watch?v=IN-TElTkVmU
Code: https://github.com/SeasonedSoftware/remix-forms/blob/main/packages/remix-forms/src/Form.tsx

My fork for BlitzJS: https://github.com/paulm17/remixForms

---

I'm raising this RFC because I think the current form system should be replaced with a similar form system as to what remix-forms provides for Remix.

I've been using Blitz since before Sept '20. I've always found the current form system could be much better. It's good now, don't get me wrong... anyway when I saw what the guys over SeasonedSoftware came up with. I was blown away. 😄

Since I was using RHF already, I immediately went over their code and forked what I could. The following is what I've been able to do:

Minimal example:

More form items example:

A complete example:

(click to see the video)

---

Why this method.

1. It saves time needing to develop many default components.
2. It allows overriding their own components with UI components from Mantine, Chakra, custom components. Easily.
3. It exposes many base functionality from RHF like watcher.
4. In its simplest form. It saves a lot of boilerplate. But when more customisation is required, it has that functionality to expand for different use cases.
5. It's easier than working with RHF in it's original state.
6. With a UI lib like Mantine. Creating complex forms is now very easy compared to before.
7. Exposes zod schema.

Potential pitfalls

However, there are some caveats to this approach.

1. I don't know whether React Final Forms or Formik would be able to adopt a similar approach. I am 90% sure they will be able to. But I am not 100%. I am not familiar with either of them.
2. There is no interoperability with data (I forget now why this is though 😓). I've been waiting to see what the guys come up with first.
3. Some type issues, which I haven't been able to fix.
4. The guys over at SeasonedSoftware have waned on the project 😬. So expect this to be a fork and ownership.

Thanks for taking the time to read. 👍

[flybayer]

Nice, thanks Paul! I think it's a great idea to improve our forms setup after 2 years. And this approach does look promising

[danielweinmann]

Hey, @paulm17! This is SO cool!

I haven't had the time to dig into Blitz 2.0 yet, but it's on my R&D goals to do so, and now that you're trying to bring an approach inspired by Remix Forms to it, it becomes even more interesting! The philosophies behind Blitz and what we're trying to accomplish at Seasoned are very aligned 💪🏼

Yes, we have temporarily waned on the project, mainly because we're focused on using the library as much as possible before we add to the APIs. One of the reasons we could come up with good APIs so far is we had a lot of time to feel the pain points of our previous stack before creating new abstractions.

That said, if you have a clear idea for new abstractions, we'd love to talk and see if we can build them together. Maybe even see if we can share a low-level abstraction layer between the Blitz and standalone Remix versions.

cc @gustavoguichard

[carlosbensant]

Beautiful, @paulm17! That would be great!

I can say we can achieve the same Form layout with formik but unfortunately it looks like formik's no longer maintained and as they said I wouldn't either use an abandoned library to create new projects.

I am reviewing your fork and it's looking great, I haven't used react-hook-form myself yet on a bigger project, but I'll give it a check.

[datner]

I've written and re-written this comment like 5 times now, thinking of good flexible api is hard 🥴

anyways, the following pop up

1. add support for hooking to a mutation natively
2. add effect to form lifecycle like onSuccess, onError, onSubmit, onResubmittion and so forth
3. add a less verbose method of creating plug-in or custom component for fields
4. complicated behavior (the one supported by Controller and FieldArray)
5. support for non-form forms, for example, an interactive ui that hides the fact you're filling a form

I wrote a few possible apis that support all or some of these requirements, but I always find myself overcomplicating and creating boilerplate code, or just not being elegant enough.

Maybe I'm just reaching for the stars, but at the very least I think we should take advantage of the "nativeness" of this form handling and interop it with other moving parts from the blitzjs family for a better DX at the cost of being opinionated..

[jhonnymichel]

I took a look at the repository today and I'm gonna start using it together with the team I lead on a freelance project using Blitz. Currently we use Formik and we have a bunch of custom components and my objective is to understand what are the gains versus using Formik, specially for custom stuff.

On a first look, it's very clear that a lot of boilerplate can be saved for more basic stuff. but in my experience, I think in most of the situations we'll have to be in control of the rendering of the Fields, even if for layouting reasons only (ie spreading the fields across multiple columns). so I want to experience the benefits I can still gain using Remix Forms.

Initially I like it a lot that I don't have to import multiple components and I'm a fan of the render props pattern. If using custom components is easy enough with this fork of Remix Forms, potentially adopting this is a win-win situation.

I'll get back once I get to use more of it, but I'm excited about trying it.