Replies: 2 comments
-
Thank you @zecuria for exploring this! The main challenge I see in both options above is that the API to build forms is changing quite drastically. It feels like the developer experience would change for the worse since the API would be more verbose and developers would need to think about more things when building forms (e.g. which form library to use, when to validate fields, etc). We'd also introduce a big hit to all basis users who would need to update all the forms in their apps to the new API when they decide to migrate. I understand though that it would provide more flexibility for advanced forms use cases and would come with full TypeScript support. Looking at the problems we are trying to tackle:
Did we investigate what would it take to add TypeScript support to basis with its current form implementation? I understand it's not a simple task, but if we succeeded, basis users would only benefit without paying the price of needing to migrate all their forms.
Could you explain why are you referring to the current implementation as a hack? Does the API feel too verbose?
Let consumers do what they wish goes against the idea of standardizing how we build forms. If you have a use case that is not supported by basis yet, we should be talking about this rather than letting everyone implement it their own way. Having said everything above, and considering all the forms use cases that I'm aware of, I feel that the main thing that basis is missing is TypeScript. I think we should explore how to add TypeScript support with minimal impact to basis users. |
Beta Was this translation helpful? Give feedback.
-
Locking this since @zecuria has a better proposal. |
Beta Was this translation helpful? Give feedback.
-
Background
Currently the form component has the following issues:
However, the existing pattern does provide:
These are problems that are already solved by existing Form State management libraries such as
Formik
andreact-hook-form
. After explorations and spikes on solutions the following:IMPORTANT NOTE: None of the options will be breaking changes. We will support the existing Basis Form until migration can be completed in all consumers at which point we will deprecate it.
Option 1:
<Field />
In this, we change the internals of
Form
component from basis to usereact-hook-form
. TheForm
will have a different API as shown in the example.Along side this, we will convert all components inside basis to "dumb" components which are only responsible for displaying what they are provided. They will no longer have any knowledge of validation and instead simply display errors they are provided with.
We achieve this by wrapping react-hook-form and expose a common API to allow consumers to be able to easily use it
Example
The new
<Form>
component will internally use react hookPros
<Field />
i.e. separation of concernsCons
<Field />
.type
prop for the correct validation, might be easy to miss if copying / pasting code.Option 2: Consumers use their own state library
In this we still remove
Form
component from basis and convert all components inside basis to "dumb" components. However we don't provide any alternative. Instead we rely on the teams to manage Form state themselves.In order to manage consistency of behavior and error messages documentation and examples will be provided on what
Example (using
react-hook-form
)Pros
Cons
Summary
Currently, the
Form
component while it works for most cases, the upcoming complexities in theHardship Application
and similar forms is pushing it to it's limits. The lack of Typescript is also starting to get painful as our journey continues.The recommendation currently to go for option 2. As this is both simple and provides the most flexibility to the consumer to do what they wish. It is also most consistent with other design systems.
However, there have been some concerns raised about migrations and ensuring that each consumer can raise any and all concerns. As such this discussion has been created to allow everyone to voice their opinions 🙏
Beta Was this translation helpful? Give feedback.
All reactions