For my personal experience I wouldn’t use re-frame to store input values.. I put together some lines of code to leverage both reagent and re-frame without storing the local inputs in the global state.. feels unnecessary .. you can use the function set-values to set the inputs from outside a field component https://github.com/luciodale/fork

@UE35Y835W interesting, that seems like a big problem though, because you loose all the benefits of one global app-state

E.g., it is pretty common for there to be more than 1 way to set some piece of data

So if I were to do it with a function, for example, I'd need to maintain a list of all refs for each piece of state, then call a function on all those refs anytime there was a change triggered from outside the text component. Seems bad

You would update directly the local state and the component picks it up automatically.. that’s how it is done

Maybe a good way would be to just use a reagent/atom, but then also reset that in a lifecycle method when appropriate. Then you get the perf, but also the global app-state

If your component is unmounted the local state is reset automatically :)

along with only updating the global-state with on-blur

Hm, are you suggesting managing react-keys or something? Because otherwise I can't rely on the component getting re-mounted

Both it and the other component triggering an update to its state may be mounted at the same time

What is exactly your use case?

You have an input being set by itself and another input?

yea, but the other thing is more like a button, not another text input

I think the lifecycle thing I was talking about will work though

Yes, I agree you should store it in an ratom.. this is a perfect use case for the lib I linked.. but feel free to implement some logic yourself :) .. I don’t think you need to manage any lifecycle at all.. you can simply pass the derefed atom as a param to an event whenever the user submits or leaves the view

(defn foo []
  [fork/fork {:initial-values
              {"input" ""}}
   (fn [{:keys [values
                set-values
                handle-change
                handle-blur]}]
     [:div
      [:button 
        {:on-click #(set-values {"input" “hello”})
        “Click me”]
      [:input
       {:name "input"
        :value (values "input")
        :on-change handle-change
        :on-blur handle-blur}]])])

It would be as simple as this :)

hm, I think that will make the rest of the app a little less convenient. I will paste what I have in mind soon, sec

I just today wrote a component for work that debounces on-change, and uses a couple of local atoms to track the state in between on-change fires

@U4YGF4NGM I was just doing that yesterday, it sounds like it’s a common problem

I ended up using an r/atom to track local content and a normal atom for the timeout object. The local content is cleared whenever the input loses focus, so “external” values (from the global state) can be rendered instead when the global state changes

https://gist.github.com/stathissideris/040f61f9b819a47cbab032fc995a9eb0 (sui is semantic UI react)

@U050AACJB interesting approach. Do you get a 'flash of old content' when tabbing out, though?

this is very new, so not well tested yet, but I didn’t notice that. By the time I tab out, the content should have propagated to the global state, so why should I see the old content at all?

it looks like it clears the local ratom before the debounced dispatch

E.g., , start new field, keep typing continuously (no 300 ms break), then tab out. I'd expect to see the field flash back to initial state "" for debounce duration before it shows the new value

I tested this and you’re right, there is a flash, but not to the initial state (`""`) but to some previous shorter string that the user typed

oh it’s worse than I thought, longer debounce timeouts uncovered a bug…