This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-06-02
Channels
- # announcements (11)
- # babashka (3)
- # beginners (54)
- # cherry (1)
- # cider (11)
- # clojure (28)
- # clojure-europe (1)
- # clojure-norway (4)
- # clojure-sweden (3)
- # clojurescript (40)
- # community-development (3)
- # cursive (12)
- # datomic (2)
- # emacs (6)
- # hyperfiddle (12)
- # missionary (14)
- # off-topic (13)
- # overtone (10)
- # re-frame (13)
- # releases (1)
- # ring (2)
- # specter (11)
- # tools-deps (7)
How would one debug app-wide instability of the dom? I can see evidence of things changing and I can guess where the instability is created, but I'd like an analytical way to nail down dom flashing.
Here's a macro that we use defensively in a lot in our CRUD datagrid stuff:
(defmacro ignore-pendings [x]
`(let [!x# (atom (e/snapshot ~x))]
(try (reset! !x# ~x) (catch hyperfiddle.electric.Pending ~'_))
(e/watch !x#)))
The problem is Electric v2's pending semantics are poorly defined and leak tons of accidental complexity. We surprised ourselves that in our more complex apps not even we can accurately predict what Electric forms will throw Pending and what the behavior will be
the interactions between e/for and client/server transfer inside the body of an e/for is a key place where Pending typically shows up unexpectedly
Addressing this is the last big thing we're working on in Electric v3, which at it's core is a redesign of e/for
and building collection awareness into the network runtime. In v2, e/for is implemented as userland hacks which is a primary source of pain in v2 apps
Cloned my Electric BraaiSim app to another laptop and am getting this error for a dom/link
I was not seeing before:
ERROR hyperfiddle.electric: #error {
:cause $Property_expr_4 is not defined
:data {:hyperfiddle.electric.debug/trace [{: :, :hyperfiddle.electric.debug/type :eval, :hyperfiddle.electric.debug/fn {}, :hyperfiddle.electric.debug/args [[#object[HTMLLinkElement [object HTMLLinkElement]] :rel "stylesheet"] <exception>],
Here is the Electric bit:
(e/defn Main [ring-request]
(e/client
(binding [dom/node js/document.body]
(dom/link
(dom/props {:rel "stylesheet" :type "text/css" :href "/braai.css"}))
(braai/Braai.))))
Could it be caused by a JDK version difference? Maybe something that only shows up in dev mode?I have not seen this. Please can you confirm the starter app works
I can confirm the electric-starter-app works just fine on this late-2019 MBP16, but I am still getting this error in my project after removing the dom/link
element.
If I remove the dom/link
that causes it, the error just moves to the next component. The error is in https://gist.github.com/theronic/2a8a4bff400aef72719bb5152bbd7392. I left a comment with the Electric component that has the dom/props causing it. The app works but sone of my touch events are broken, presumably due to the missing props.
I thought it was maybe caused by data-attributes in dom/props, but I removed them all and it still throws for simple (dom/props {:draggable true})
.
I switched JDKs and double-checked Clojure versions. Issue still occurs on this machine, but not on my M3 Macbook.
Very weird error 😕 Can’t dev on this machine (my other machine’s screen is broken).
Any ideas what I can check next short of wiping the machine?
When deploying a new version of my app to http://Fly.io (built on Electric Starter App), I get the following error:
5.600 Checking out: at b32ac98df7d7ec87f225d47354671be172ffa87e
6.661 Error building classpath. Failed to read artifact descriptor for org.clojure:clojure:jar:1.12.0-alpha5
6.662 org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.clojure:clojure:jar:1.12.0-alpha5
Could be a Maven access issue on Fly, or maybe the alpha artifact is not available? Trying with newer alpha Clojure now.Hmm, same error when using org.clojure/clojure {:mvn/version "1.12.0-alpha12"}
This resolved after a few tries. http://Fly.io issue.