Closed jotaen closed 3 years ago
On the event handling side there might also be room for simplification: each dialog has its own event name this-and-that-failure
but they are all registered individually. So we could either have a generic operation-failed
event, or we keep the individual event names but bulk-register them.
One additional thought regarding this: the errors could also be caught and handled by the enclosing overlay component. So after catching it “transitions” into the error state. That would give us an interesting opportunity to introduce a “back” button in the error overlay, so it’s more convenient for the user to try again. Otherwise they need to go the “full roundtrip”, i.e. closing the modal, opening the menu, and selecting the menu item again.
We have a lot of repeation and verbosity around the creation of custom events, e.g.
My current stance is that it makes a lot of sense to rely on events for control flow in custom components. Therefore it would be cool if it was easier and more robust to emit them. The event configuration is mostly the same (
bubbles
andcomposed
).