3 ms·
Shouldn’t the panel’s width be stored on the Panel component, and all items in it should probably just be width 100%, or styled to fit the Panel via CSS. That’s
by runawaybottle 7y ago
Shouldn’t the panel’s width be stored on the Panel component, and all items in it should probably just be width 100%, or styled to fit the Panel via CSS. That’s the last bit of UI state that I’d ever think to move up to the global store.
The dropdown would act in the same way, no? It mostly sets some local state, and your can then derive the data you need from the store (let’s say the drop down was just an on/off filter). But yes, you are right, you would need to think about a way to abstract this out as a data flag and not a ui state flag.
- nine_k 7y agoSpecifically for dropdowns, you usually want to keep their open / closed position in the UI state explicitly, because you want to close an open dropdown when the user clicks on another dropdown. I frankly think that this complexity is not accidental. It is the real complexity of the UI, which is often not realized. All the little things that need thought and, at least once, an implementation.
- pests 7y agoThe original drop down can close itself when it loses focus. No need go into shared state for this usecase.
- T-hawk 7y agoLosing focus is itself a stateful change on a UI element caused by another UI element. It's just that the frontend platform like the browser or OS manages that shared state for you.
- _bxg1 7y agoYes, this is key. There are many cases like this (and CSS pseudo-classes, and the drag and drop API, etc.) where the browser platform gives you convenient ways of avoiding the problem. And certainly, take advantage of those where possible. But they don't eliminate the problem in the general sense.