Fork me on GitHub
#re-frame
<
2020-07-22
>
Jacob Emcken10:07:55

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.

Jacob Emcken10:07:13

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-himik10:07:26

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 Emcken11:07:17

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 Emcken11:07:41

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-himik11:07:16

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 Emcken11:07:17

"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.

Lu11:07:42

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

Jacob Emcken11:07:28

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

Lu11:07:54

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

Lu11:07:22

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.

Lu11:07:10

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

Jacob Emcken11:07:00

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

👍 3
reefersleep12:07:13

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

reefersleep13:07:58

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

Jacob Emcken14:07:49

@U015631CK4M 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 Emcken15:07:05

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

🍻 3