[grayrest]

> Doesn't some state belong in the component itself? Certainly there are cases where this makes sense, right?

It depends how pure you want to be. The app I'm paid to write is in clojurescript and follows the convention of keeping almost everything in the global state. The main things I'm missing is focus and cursor state in text fields. The main benefit to doing this session recording and playback. I capture every point of non-determinism in the app as an event so I get full fidelity playback from recorded event streams.

It's more work than just keeping things locally or using two-way bindings but the code to handle the sort of things you'd keep in internal state is simple so handling the events is just registering the cross-app generic handler for the event. I designed the system for capture and replay but the main benefit turned out to be that when something goes wrong I generally know the source of the problem immediately even if I didn't write the code.

To use your menu open/closed as an example, I click on the preferences menu and it doesn't open. I look at the log and don't see `[:preferences/toggle-dropdown-menu :open]`, the problem is that something's eating the mouse event and I have to walk the component hierarchy. If I do see the event, I dump the app state and look in `:preferences :dropdown-menu` and see that the value is `true` instead of `:open` so my handler is broken. If the value is correct, the problem is either in the component itself (click another dropdown and see if it works) or in the computed value chain I'm using to feed the data into the component. For everything but the mouse event, I know by convention which file and function contains the relevant code and they're almost all 5-10 lines of code. Here's what the handler would look like:

    (rf/handler :preferences/toggle-dropdown-menu
      (mw/path preferences-path)
      (mw/set-value :dropdown-menu #{:open :closed})