PatternFly + form library integrations

[nicolethoen]

The PatternFly team is pulled into conversations regularly about choosing/endorsing a third party form library for handling form validation and state management. There have been times which PF has considered creating an integration with a form library and, historically, efforts have been started but have not gotten very far for a handful of reasons.

The primary reason is because PatternFly is a dependency of a few key stakeholder products, especially at Red Hat, which have conflicting opinions about which form library to use. Other project having already committed to a solution and built out complex forms means that making an endorsement would only have minimal impact.

Some solutions considered are:

• Data Driven Forms https://github.com/data-driven-forms/react-forms - does contain a PatternFly integration maintained by Red Hat's HCC
• Formik https://github.com/jaredpalmer/formik - currently there is an experimental, unsupported project to integrate Formik and PatternFly https://github.com/patternfly-labs/formik-pf)
• React Hook Form https://github.com/react-hook-form/react-hook-form - no existing PatternFly integration, but Red Hat's Ansible platform has done some work to integrate react-hook-forms with patternfly

If anyone has any feedback regarding their experience with any of these integrations, we'd love to hear about it!
The PF team has considered writing some sort of handbook to guide products on how to best integrate PatternFly with these form libraries - to share lessons learned, to develop best practices, and to encourage consistency in approach. This would be in lieu of PatternFly officially supporting/endorsing a specific solution or creating/maintaining an integration.

[mturley]

We have also done some work in Konveyor to ease PF integration with React Hook Form. @nicolethoen do you know where I can find the code for what Ansible has done on that? Maybe we can compare and find a single solution to share (via PF Labs?)

One thing I can say based on my experience with React Hook Form so far is that that library is designed to improve the performance of interacting with form fields (particularly text fields where each keystroke is normally a full re-render of the form when using traditional React controlled components) by directly manipulating the DOM elements with refs (sort of circumventing React entirely) by default. This isn't really compatible with how some PatternFly form input components currently operate: they expect to be controlled components where you pass value and onChange, and they don't all allow passing refs where you would need to to use RHF's default behavior (their {...register("myField")} syntax). Fortunately, RHF does provide a <Controller> component you can use to tap into the form state and render a controlled component, which is how we've been integrating with PF (and that's the basis for our reusable RHF input components). However, this does totally defeat the purpose of RHF's default approach; by using the Controller pattern, you are indeed re-rendering the whole component every time the value of the field changes, and you don't get any performance benefit from using RHF.

IMO, this makes RHF not the best fit for PF as currently implemented, but perhaps still better than Formik since Formik's maintenance has been inconsistent ever since its creator got a job at Vercel. (However, now that I take a closer look there has been renewed dev activity there and some new releases, so perhaps Formik is still a good candidate for being the recommended PF integration). RHF remains pretty popular though, so having a well supported integration with it is probably a good idea even if it's a compromised one. We also may be able to change how PF input fields are implemented to get them to be able to be used with RHF's register() pattern, but (and this is my own opinion) that pattern sort of goes against the "React way" and is clunky to use.

As for Data Driven Forms, I haven't used them myself but from what I've seen I'm under the impression that they are too opaque an abstraction and not flexible enough if you want to do custom rendering (similar to the old deprecated PF Table), but that's a first impression that could totally be wrong. They do seem to allow interesting things like driving what the form fields are from a server without much fuss on the UI side. So they may have a lot of value for specific use cases while not being a good choice for a generally recommended form solution.

[jonkoops]

Personally, I don't think it makes sense for PatternFly to build any integrations specific to form libraries, although some guides in the documentation on how to integrate them might be a nice addition.

We're using React Hook Form in combination with PatternFly for the Keycloak project, and the integration work is honestly very light-weight. Except for a few cases I did not feel like there was much trouble integrating these two together.

The main thing that I would advise is to align PatternFly more closely to the native elements that it models in forms. For example, PatternFly 4 changed the signature of the onChange handler, which broke integration with React Hook Form. This meant we had to create wrapper components around PatternFly components to restore the original signature. This was then fixed in PatternFly 5, allowing us to just use the PatternFly components directly.

But this is not the only thing that PatternFly modifies to be different, including but not limited to:

• isDisabled prop, rather than using the built-in disabled attribute.
• isRequired prop, rather than using the built-in required attribute.
• readOnlyVariant prop, rather than using the built-in readonly attribute.
• Rolling it's own form validation rather than using existing client-side form validation of the platform. Including the :invalid and :user-invalid pseudo classes, setCustomValidity() method (see Constrained Validation API).

I think that rather than trying to further integrate PatternFly with React-specific form validation libraries, it would be better effort spent to align PatternFly with the web platform as much as possible. As this would subsequently make it easier for these libraries (also non-React ones) to integrate with PatternFly.