ui/input no. We have ui/on-submit which is currently unused but I think it still works. You'd (dom/input (ui/on-submit (e/fn ... . You can also copy the pattern from our https://electric.hyperfiddle.net/(electric-tutorial.demo-chat!%43hat)/

I’ve tried a couple of things using dom/input. Previously I had

(e/defn InputSubmit [s F]
  (e/client
   (dom/input (.setAttribute dom/node "value" s)
              (dom/on "keydown" (e/fn [e]
                                  (when (= "Enter" (.-key e))
                                    (let [v (-> e .-target .-value)]
                                      (F. v))))))))

(e/defn InputSubmit [s F]
  (e/client
   (dom/input (.setAttribute dom/node "value" s)
              (ui/on-submit (e/fn [s] (F. s))))))

Here’s a long example — a degrees Celsius to degrees Fahrenheit converter, and vice versa — where the input fields are updated when other input fields are edited…

just making sure you've seen this - https://electric.hyperfiddle.net/(electric-tutorial.tutorial-7guis-2-temperature!%54emperature%43onverter)/

Hah! I had, but I’d forgotten about it. 🙂 I’m trying to set up something where I can make server queries only after the user presses the enter key in an input field. Is there any way to do that? At the moment I’m getting a query on every keystroke.

My dom/input approach has the problem detailed above.

You cannot capture both on-submit and dom/on key=enter, it's one or the other

do not differ from the tutorial

and i think it will work XD

> You cannot capture both on-submit and dom/on key=enter, it’s one or the other I am using one or the other; not both. My example may have been over-complicated. I’ll post a shorter, more focussed example later.

That’s my simpler example, above. This code creates the following: • An atom containing a string. • A watch on that atom. • A ui/button that sets the atom’s value to a random string. • A ui/input that shows the atom’s value. The value can be edited (no need to press the enter key). • A dom/input that shows the atom’s value. The value can be edited (the enter key must be pressed). Note that the values displayed in the ui/input pane and dom/input pane update reactively when the atom’s value changes. Everything works except that after the dom/input has been edited, it no longer updates reactively.

Actually, this isn’t a big problem for me — it’s something that showed up when I was adding code to help debug things.

But if someone can tell me a way to make the dom/input maintain its reactivity after being edited, I’d be interested — it might help me another time when I’m debugging.

I guess deleting the component and recreating it might do the job. Maybe I’ll look into that. Not sure how to do it offhand. It would be nice if there were a simpler fix.

If you change line 43 to @!input-string does it change the behavior at all? eg (InputSubmit. @!input-string (e/fn [s] ...)) Another idea is to change (F. v) to (F v) on line 13 [3] A final thought is to change line 13 to say (reset! !input-string v) instead of working with the (e/fn [s] ..) and relying on the (F. v) to do the trick. A post-script (PS) final final thought is you can maiybe move lines 15, 16 (cljs def, e/def) above the InputSubmit. and see if that changes things. I think suggestion [3] has the highest likelihood of addressing the issue

Thanks, but none of those work and the first two make things worse. 🙂 Are you able to run the code yourself and try out your ideas? (You seem quite interested in this, and it seems to me you would get something out of running the code and fiddling with it. Up to you, of course.)

I’ve fixed it by changing (.setAttribute dom/node "value" s) to (clojure.browser.dom/set-value dom/node s). Yay!

Very nice find

what is the difference?

Before my fix, after typing into the input pane it would no longer update when the underlying atom was given a new value — the reactivity broke. (Excuse my possibly broken terminology.)

Is this by any chance related to the quiz question at https://electric.hyperfiddle.net/(electric-tutorial.demo-system-properties!%53ystem%50roperties)/ where an inline style gets lost? Just wondering because I understand neither and both seem to be reactivity losses.

the answer to the quiz is because the rendering is effectful, the new props overwrite the old props, there’s no stack

(Just seen this…) It took me a while to understand what you meant by “the new props”. Looks like ui/input , via ui/control, is setting new props.

https://github.com/jeans11/demo-rama-electric

idk if this will be helpful for investors, but we made this in electric: https://youtu.be/VTDLTzLeegE?si=xKffkZB_xyBoLVVG

edited version: https://youtu.be/dNIOPXgV53o?si=c7pTFSRRpfoYGQa4

Much older version, but it shows a big benefit of Electric:

We're building http://uxo.ai with Electric (the app itself, not the landing page, check the video).

I also managed to convince my consulting client (a very conservative Japanese corporation) that I can build them an internal tool for visualizing and annotating data for machine learning. Using Electric has made the codebase very compact and the app dynamic, and using XTDB has given us a way to travel back in time to see how predictions looked like for ewarlier versions of the model, which has been very valuable. They're now thinking whether to adopt Clojure/Electric more broadly.