Fork me on GitHub
#untangled
<
2016-08-10
>
tony.kay15:08:18

@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)])

tony.kay15:08:08

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

tony.kay15:08:49

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.

kenbier17:08:41

@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?

tony.kay18:08:16

@kenbier: all but the intermediate text field states

therabidbanana18:08:24

@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

therabidbanana18:08:37

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.