You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This library was initially built in an opinionated way. Currently, this library depends on VueJS and Headless UI libraries. While this is a VueJS library, and so it is required, the Headless UI dependency may prevent adoption and reduce usability for some applications.
Headless UI provides the ListBox implementations for single and multiple selections. There is also a TODO about selecting and implementing a Date Picker component. This begs the question, which one do you pick?
I am proposing that we simplify this library by using all native controls for the fields but allowing implementers to use whatever control they want, whether that is Headless UI, Bootstrap, or some other library, through component slots. This should provide the most flexibility for end-users and reduce the potential churn of feature requests to support different component libraries.
For applications that are ok with using native form controls but just want some simple styling control, we can also provide style properties so that custom CSS classes can be provided.
I suggest targeting this new approach for a 1.0 release.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This library was initially built in an opinionated way. Currently, this library depends on VueJS and Headless UI libraries. While this is a VueJS library, and so it is required, the Headless UI dependency may prevent adoption and reduce usability for some applications.
Headless UI provides the ListBox implementations for single and multiple selections. There is also a TODO about selecting and implementing a Date Picker component. This begs the question, which one do you pick?
I am proposing that we simplify this library by using all native controls for the fields but allowing implementers to use whatever control they want, whether that is Headless UI, Bootstrap, or some other library, through component slots. This should provide the most flexibility for end-users and reduce the potential churn of feature requests to support different component libraries.
For applications that are ok with using native form controls but just want some simple styling control, we can also provide style properties so that custom CSS classes can be provided.
I suggest targeting this new approach for a 1.0 release.
Beta Was this translation helpful? Give feedback.
All reactions