Fork me on GitHub
Geoffrey Gaillard01:05:37

@pesterhazy I found out what was going on. The problem was comming from the MaterialUI TextField component that trigger onChange instantly, before the key composition. (I don't know why yet). By setting a :value @my-text-atom the component was re-rendered instantly, breaking the key composition. I found a workaround covering my needs: I assign an :id "my-id", use :defaultValue instead of :value to this TextField and in the onChange handler :

(fn [event new-value]
  (-> (.getElementById js/document "my-id")
       (aset "value" (.. event -target -value)))
  (swap! my-text-atom new-value)) 
Really dirty… not proud at all 😇 but it does the job until I find a cleaner way. So it was not really a reagent problem but my needs here are maintream, so maybe someone else will search the Slack archives for something similar.


@ggaillard the thing to remember is that reagent does some special tricks to make input fields work


one particular problem is that because reagent batches updates, sometimes typing is too slow


that's for controlled components though - by not using value you're using an uncontrolled component, which works differently


anyway, reagent's tricks probably need to be applied to 3rd party input fields, like the one from materialui


one thing that people have tried is to use force-update to make keystrokes be registered immediately


I haven't heard about your particular issue before


it seems weird that keys are registered separately (I guess as unicode composed characters?) - is that on linux?