Clojurians Log v2
re-frame
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.
Maybe this guide coud help you figure out https://purelyfunctional.tv/guide/state-in-re-frame/
@jacob429 just to add; if you're concerned about timing, dispatch-sync is another tool in re-frame you could consider 😊
When considering initialising your state in re-frame from the form-2 outer function, that is.
@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 👍
@reefersleep I didn't think of the dispatch-sync and form-2 combination. I'll keep that in mind, thanks
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)?
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.
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.
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.
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.
"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.
Yeah but you might as well dispatch an event that adds those init values to the app db with form 2
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)?
Anyways it feels like other components don’t need to know about this form configuration so I would personally use the local state
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.
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: https://github.com/luciodale/fork
I think I'm going to try the local state thingie and see where that leads me 😆
1👍