This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-11-04
Channels
- # announcements (5)
- # babashka (2)
- # beginners (53)
- # biff (11)
- # calva (5)
- # cider (4)
- # clojure (32)
- # clojure-austin (2)
- # clojure-dev (5)
- # clojure-europe (17)
- # clojure-norway (22)
- # clojurescript (23)
- # core-logic (1)
- # cryogen (1)
- # datomic (1)
- # dev-tooling (7)
- # emacs (6)
- # fulcro (63)
- # guix (1)
- # hyperfiddle (14)
- # integrant (2)
- # lsp (6)
- # missionary (4)
- # nbb (42)
- # overtone (9)
- # reitit (8)
- # specter (3)
- # sql (2)
- # squint (7)
- # tools-build (9)
what might an electric-dom3
look like? i'm designing something similar, would be interested to hear any lessons from dom2
the problem with dom2 is the event handing is imperative, adding latency to the reactjs change callback pattern has really confusing semantics
it’s also plausible that the event side of views should be done in discrete time, which means no network transfer in response to events except at the root of the component tree
that’s my 2c what is yours?
aside from what's blocked by differential electric, are you satisfied with (or at least have no current plans to change) the api?
um a better props syntax would be nice but the requirements are stringent, it cannot damage expressive power
UIx etc. have special considerations in their macros for props delivered as a map literal in the first parameter position of DOM constructors.
But it’s also quite powerful to be able to return props and treat it as a graph node in some cases.
A #props
reader macro?
it’s also plausible that the event side of views should be done in discrete time, which means no network transfer in response to events except at the root of the component treeI think I agree with this; I made callbacks defer their effects by putting them into a global event queue that gets flushed every frame, inspired by https://bevy-cheatbook.github.io/programming/events.html I think it's pretty clean, seems to have fixed the glitches i was seeing by making all the reactive effects happen at known points and also paves the way for split client/server data
Interesting @U797MAJ8M. What glitches were fixed by using an event queue?
changes being dropped etc. probably the same sorts of glitches dustin is referring to with react-style callbacks that they want to get rid of with differential electric, and making multiple watches on an atom; you can only have one reactive system that fully controls when all things happen, you can't mix dataflow/execution semantics or things become impossible to reason about
the problem is more visible in ecs (because it forces you to think explicitly about data dependencies and execution order, i'm bridging odoyle and electric for dynamic reactive state) than frp but should exist in general
idk what glitches you are talking about, the ui4 library has no known bugs or glitches