hyperfiddle 2022-12-26 | Slack Archive

noonian18:12:45

Hello and happy holidays! I'm seeing changes in behavior that was previously working and wondering if I've found a regression. I haven't pinpointed a super narrow example, but what I'm seeing is when I pull data from a map via keyword (i.e. (:some-prop m)) inside photon dom code, the value from the map is rendered multiple times, both in the desired element and also in it's parent elements within the photon defn (until the next client/server boundary possibly). This does not occur if I pull the value out of the map in a let or for binding and only refer to the value as a symbol in the dom code. I was able to reproduce this in the demo_4_chat_extended demo with the following changes, and the rendered behavior (note username "noonian" is rendered twice, once in the <strong> tag and once in the parent <li>) Please let me know if this is user error on my part. As always thank you for your work on photon and there is no urgency on my end for a fix.

👀 1

Dustin Getz19:12:58

pretty sure this is us i will take a look in a few days, team is on vacation and i’m doing taxes

👍 1

Dustin Getz19:12:07

also are you using Photon for anything? i need to know if people are using it so i can make judgment calls about breaking changes as well as communicate idiom changes. i try to stay in touch with everyone who is making something

noonian19:12:04

I have a project I've been using for experiments, but I don't know what the final incarnation will look like and I have not been very consistent working on it (just dusted it off after three weeks without touching it). I plan to deploy it and experiment with some operational things like horizontal scaling with redis for shared state etc. and running stateful services on kubernetes. I'm very excited about Photon but I'm still trying to get a sense of it's sweet spot for target applications so I can make something that takes advantage of it's super powers. I've been trying to follow the src-docs and your scratch namespaces to get a sense of how idioms are developing. I'm just doing this on my own and no one is paying me so I can't commit to making something real. I'd love updates about breaking changes etc. but I understand it's still in alpha and you have to manage your time

👍 1

xificurC08:12:34

Thanks for reporting this! TLDR: This is most likely from 5ba144d094f9ebb4943e88aa4263db1ba933c940 (Dec 7th). We'll check in the new year if we can revert it safely. There are 2 competing forces at play here. Clojurists are used to hiccup, so if they wrote

[:div [:strong (:name e)]]

They'd like that to translate to

(dom/div (dom/strong (:name e)))

. But dom/div is a function (macro), not a data structure. Same for dom/strong. So in (dom/strong (:name e)) the dom/strong macro's first argument will be a runtime string. If we want that to work we have to interpret stringy runtime values as text you want to put into the DOM. So the above code is rewritten to

(dom/div (dom/strong (dom/text (:name e))))

. dom/text puts the text into the DOM and returns nil . If it returned the string then dom/div would see it as the return value of dom/strong and re-interpret it, which would result in you seeing the string twice in the DOM. Now consider this pseudocode:

(let [name (dom/input (InputValue.))]
  (println "Your name is" name)

In this case you want to use the return value of dom/input but not for DOM text injection. The change from Dec 7th wants to make both of these cases work, but as you noticed this isn't completely possible. We're still iterating on a good API.

👍 1

nivekuil14:12:36

have you seen how fulcro dealt with this? scroll up to the NOTE bit from https://book.fulcrologic.com/#_props

👀 1

Dustin Getz17:12:10

react controls don’t return events, in react events are handled through callbacks. in FRP, especially in low level Photon code like implementing fancy controls, we emit events in a pure functional style via the return channel. this difference leads to a syntax collision where string values are ambiguous - is a string an FRP “event” or reactive value to propagate up?or is it dom body innerText.

Dustin Getz17:12:21

i have a proposed style that makes static props explicitly static (no need for runtime check) as well as disambiguates the body text, but we haven’t discussed it as a team yet

Dustin Getz14:12:51

Ok I took a look at https://github.com/hyperfiddle/photon/commit/5ba144d094f9ebb4943e88aa4263db1ba933c940 , i think it should be reverted but I don't dare do it until we're back from vacation due to breaking whatever thing wanted the opposite behavior

Dustin Getz14:12:20

You can revert it locally if you want @U052PH695

Dustin Getz14:12:54

It appears there's an interaction with another change, I was able to reproduce it until this commit from this morning https://github.com/hyperfiddle/photon/commit/6c407cf0b5e96b5475d8c2a6788996ef10e2d2f0 which causes the reproduction to no longer work

Dustin Getz14:12:31

I propose you just pull latest, i think it's sorted. We are revisiting all this stuff soon anyway, none of us are happy with the photon-dom1 impl

👍 1

2022-12-26

Channels