@kenbier: Just jumping in here, but I would not recommend resetting app state via mount/unmounts. Do that as part of your transaction that does the close: (transact! this '[(dialog/reset-fields) (dialog/close)])

And Untangled/Om do recommend you place the vast majority of your application state in the central global app state database.

Basically, component local state is relatively ok if you don't really care about the intermediate states for history viewing/debugging, or the dynamic interaction proves to be too slow (changing a global app state on a large app while doing rapid graphical animation like during the drawing of a bounding box). One other case is where you want to hold onto things that are not serializable for history viewing (like a js Image object). I plan to add some more recipes to the cookbook that demonstrate some cases.

@tony.kay: that is a much better idea, thanks. mostly we moved away from putting form fields in global app state because a txn on each keypress was causing a lag in render. do you tend to put most of your form fields in app state?

@kenbier: all but the intermediate text field states

@tony.kay: you mean something like local state for individual keypresses, then commit to app state onblur or similar? I was theorizing we could do something like that yesterday when talking about this with @kenbier

yep.

Would be interested to see what that looks like - seems like it'd be good for us, we don't have too many text fields.