Well, we want to improve the DX of our form related components, which means we want to have a consistency of APIs, for example <Select /> doesn't have a label API unlike <ColorPicker />, that causes inconsistency between Clay components and different ways of using the API.
We also force compositing with ClayForm which is good at times but bad at others, this is a big tradeoff of flexibility vs agility, we can go in the direction of trying to keep all form related components consistent with APIs for example, provide label, handle OOTB validation in some way that allows it to integrate with form libraries like Formik, required... with the main goal to improve the DX of the components.
The idea here is also to understand how we should do this or we should create something that approximates the composition and improves the DX of the components that deal with the form. The current composition of these use cases means you have to write more and use more components, this can be repeatable in most scenarios and also means more stuff to remember but on the other hand, it means a lot of flexibility, we need to see how far we can provide this flexibility.
The output of this issue is an RFC that we can describe all the nuances regarding this change and the final proposal for it.
Valid discussions on this:
Well, we want to improve the DX of our form related components, which means we want to have a consistency of APIs, for example
<Select />doesn't have alabelAPI unlike<ColorPicker />, that causes inconsistency between Clay components and different ways of using the API.We also force compositing with
ClayFormwhich is good at times but bad at others, this is a big tradeoff of flexibility vs agility, we can go in the direction of trying to keep all form related components consistent with APIs for example, providelabel, handle OOTB validation in some way that allows it to integrate with form libraries like Formik, required... with the main goal to improve the DX of the components.The idea here is also to understand how we should do this or we should create something that approximates the composition and improves the DX of the components that deal with the form. The current composition of these use cases means you have to write more and use more components, this can be repeatable in most scenarios and also means more stuff to remember but on the other hand, it means a lot of flexibility, we need to see how far we can provide this flexibility.
The output of this issue is an RFC that we can describe all the nuances regarding this change and the final proposal for it.
Valid discussions on this: