Jacob Emcken 2020-07-22T10:48:55.040800Z

I'm trying to decide whether or not I should use local state for "a form". My form represents a configuration that can be changed and the effects can be seen live, but I don't want the original conf to be updated until this new configuration is saved. If I choose a different configuration (from a list outside the form) the form should be "reset" with this configuration instead.

Rabie 2020-07-25T02:09:02.063900Z

Maybe this guide coud help you figure out

reefersleep 2020-07-25T12:17:13.071500Z

@jacob429 just to add; if you're concerned about timing, dispatch-sync is another tool in re-frame you could consider 😊

reefersleep 2020-07-25T13:02:58.073200Z

When considering initialising your state in re-frame from the form-2 outer function, that is.

Jacob Emcken 2020-07-25T14:59:49.084500Z

@rnait1977 it is a really good link. I've read it before bugged you peeps and it is part of the reason why I got inspired to look at local state, but thanks 👍

Jacob Emcken 2020-07-25T15:01:05.084700Z

@reefersleep I didn't think of the dispatch-sync and form-2 combination. I'll keep that in mind, thanks

Jacob Emcken 2020-07-22T10:53:13.041100Z

It feels more "right" to use local state. Maybe because it seems easy to init the form with initial state before it renders the first time. But I'm afraid it will be harder to debug (data being outside app-db)?

p-himik 2020-07-22T10:54:26.041300Z

It depends on what you treat as the state of your application. From just the programming perspective you can use both just fine. Even if you don't want to update a specific app-db path until the form is ready, you can just use a different path for temporary data.

Jacob Emcken 2020-07-22T11:01:17.041500Z

In a way this is a followup question from the other day. kee-frame seemed to impose more changes (also a lot of places not related to the code I'm dealing with right now). So I ended up with this local state as an alternative to setting initial state for my form component.

Jacob Emcken 2020-07-22T11:08:41.041700Z

so right now I'm trying to weight pros and cons: • con, I can't use re-frame-x10 to debug local state (if understand it correctly) • pro, I can easily init form right before first render. I don't need logic "outside" the component (i.e. listening for app-db changes with re-frame-async-flow-fx or kee-frame) to make sure the initial state is always ready to go.

p-himik 2020-07-22T11:16:16.041900Z

I don't know what "init form right before first render" means. You can run the same code no matter the approach. It's just that it will be run in different places.

Jacob Emcken 2020-07-22T11:19:17.042100Z

"init form right before first render".... if I understand it correctly it would be using Form-2 which creates a Reagent Atom that a render function uses.

Lu 2020-07-22T11:21:42.043Z

Yeah but you might as well dispatch an event that adds those init values to the app db with form 2

Jacob Emcken 2020-07-22T11:22:28.043300Z

Wouldn't I risk a race condition where the form starts rendering with state in app-db that isn't initialized, when using the dispatch approach (being async and all)?

Lu 2020-07-22T11:22:54.044200Z

Anyways it feels like other components don’t need to know about this form configuration so I would personally use the local state

Lu 2020-07-22T11:30:22.047700Z

Mmm well no because you would store your initial-values and just keep updating them until the save button is hit... then, you can move the saved values somewhere else .. so basically if the component is rendered before the app db has the initial values set, it doesn’t matter because the inputs will be populated as soon as the dispatch function populates the db.

Lu 2020-07-22T11:32:10.049800Z

But I see no point in storing the initial and live values in re-frame.. I’d just use a ratom for that.. that’s the approach I use here:

Jacob Emcken 2020-07-22T11:43:00.050100Z

I think I'm going to try the local state thingie and see where that leads me 😆