Fork me on GitHub
#hyperfiddle
<
2022-08-05
>
Dustin Getz17:08:19

We are rolling back our guidance about how inputs should work. We originally said we wanted inputs to return a reactive value. We have changed our minds (for now) and want you to use a React-style callback with local state for inputs, like this:

(let [!filter (atom "") filter (p/watch !filter)]
  (dom/div (dom/text filter))
  (ui/input {::dom/type       :search ::dom/placeholder "java.home"
             ::ui/input-event (p/fn [e] (reset! !filter (:value dom/node)))}))

reedho01:08:21

Curious why is that?, pros and cons on each impl explanation woud be very helpful. Is there doc for basic concept or technical background to read on ? I would like to help to improve doccumentation, but surely i will need much guidance first.

Dustin Getz01:08:58

it was not adding anything and it was causing two problems: 1) making it difficult to use the reactive value from input in a position above the input itself as in this example; 2) when the callback transfers to the server, we want the Pending exception to be thrown from inside the button context so the button can disable itself while the transfer is pending and this forces us to use the callback pattern

❤️ 1
Dustin Getz01:08:02

i have a plan for docs, i am setting up a Logseq repo for people to submit PRs to. also i may move this slack community to discord so i can add logger bots and eval-bot

🙏 1
reedho01:08:14

Yeah that would be great.

Peter Nagy07:08:28

wouldn't this example work with a reactive return value? Something like (dom/div (dom/text (ui/input ...))). Is ui/input returning something useful now? 2) isn't very clear to me, maybe if there was a side-by-side example.

Dustin Getz18:08:22

Unserializable reference transfer exceptions are now silenced and logged, i.e. (p/client (let [x (p/server (type 1))])) is no longer fatal, we transfer nil. Here's a real user story:

(p/client
  (ui/input {::ui/input-event (p/fn [e]
                                (p/server
                                  ; attempted unserializable reference transfer
                                  (d/transact! !conn [{:task/description (p/client (:value dom/node))
                                                       :task/status      :active}])
                                  #_nil))}))
the trailing nil is no longer necessary, Photon will transfer nil and log: 14:01:42.047 DEBUG http://h.p.io [qtp966786773-115] - Unserializable reference transfer: datascript.db.TxReport@b532aeb3

Peter Nagy07:08:09

is this for convenience? Isn't this against the fail fast principle? I guess there's a difference when you're running a query (want a return value) or a command (you want to side effect and don't care about the return value). In clojure this distinction isn't important on the API level, but here, for unserializable values you get an exception and in the command case it's just noise. Is that the problem you're trying to solve here?

👍 1
Peter Nagy07:08:01

I'm only worried about the case where you want a return value but due to user error you return something unserializable and get nil on the other side. Seems like it might cause a debug hunt. Could/should this be solved on the API level? E.g. p/server-command never transfers a value across the wire

Dustin Getz10:08:05

p/server! is an interesting idea, we will consider it

Dustin Getz10:08:36

in all the examples i've built, transferring a reference is always accidental unless you have defined a transit handler for it in which case it will succeed. so we want to do the right thing by default without requiring the user to remember to write (do … nil). and it does log

Dustin Getz10:08:49

there are other possible approaches too, for example a security layer that outright forbids accidental transfer of things like connections, databases, and certain qualified kw attributes (which even if serializable can contain secrets)

Dustin Getz18:08:37

If you want certain ref types to transfer you can add a transit handler of course

Dustin Getz19:08:55

We broke hot code reloading in master, ETA on fix is monday, sorry

👍 1
👀 1
Adrian Smith11:08:16

Any update on this? I think I tried editing a demo yesterday, shadow injected but my dom elements didn’t change

Dustin Getz09:08:20

refresh page manually

Dustin Getz09:08:49

i don't think we got to this issue yet, it's coming

👍 1