Encapsulating state within the components seems to be a bad idea #529
barrycenter
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'll start by saying I work primarily in Vue and I don't know what design patterns are useful in React or other libraries but I find that it's problematic to be encapsulating the states solely within the components. It severely limits how we can use the data and largely precludes us from meaningfully interacting with it. It is not reactive when values change externally nor do we have the ability to modify the values programmatically. So, while we have a great deal of control over styling with Tailwind, and it's stated that we'll get keyboard and accessibility controls, we lose almost all of the control of the flow of our interfaces.
For example, in a navbar, I can't update the menu open/close state but there are many times when external factors should be able to change the state. For example, if a user clicks a link elsewhere on a page I may wish to close all the nav menus while the page navigates elsewhere, or close the left-hand menu when the right-hand menu is opened, or when the user navigates to another button on the same navbar, or even when a modal is popped open from an entirely external process like an automatic logoff.
I also can't block the closing of the menus if a user clicks a currently disabled button or otherwise should not allow the menu to close, such as a verification alert. So, we need a disallowClose option there as well.
If I need to manage all these details by making things static, then I'll lose all of the automatic behaviors that are expected to be added by the accessibility and keyboard controls. I don't want to have to explain to stakeholders why the accessibility and keyboard features work only in the simplest of circumstances but don't work elsewhere in an app because it's in some black box components which I have little control over and would need to replicate in whole elsewhere. If I end up having to write it elsewhere then I don't need to import Headless UI.
Perhaps we should be passing in a HeadlessState object with a reactive readonly value for the boolean open state and a method for changing that state. Then we can do whatever we want with that object. We could extend it to add menu items, we could override the function to add criteria to closing, or store it in a Composition API datastore so it can be accessed throughout our app. You could set the Component to create a default a generic object to manage the internal data if it's not passed in and even provide the boolean through the slot for backwards compatibility if you like.
Beta Was this translation helpful? Give feedback.
All reactions