This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-02
Channels
- # announcements (1)
- # babashka (4)
- # beginners (39)
- # calva (36)
- # cherry (11)
- # cider (23)
- # clj-on-windows (3)
- # clojure (105)
- # clojure-brasil (1)
- # clojure-chicago (3)
- # clojure-conj (8)
- # clojure-denver (4)
- # clojure-europe (18)
- # clojure-germany (5)
- # clojure-hungary (13)
- # clojure-nl (1)
- # clojure-norway (31)
- # clojure-sweden (9)
- # clojure-uk (2)
- # clojurescript (22)
- # core-async (4)
- # cursive (8)
- # data-science (25)
- # datomic (14)
- # devops (1)
- # emacs (9)
- # events (5)
- # holy-lambda (32)
- # hyperfiddle (26)
- # introduce-yourself (2)
- # kaocha (1)
- # leiningen (11)
- # lsp (17)
- # malli (8)
- # off-topic (84)
- # pedestal (4)
- # polylith (2)
- # re-frame (17)
- # reitit (1)
- # releases (1)
- # remote-jobs (1)
- # shadow-cljs (8)
- # sql (4)
- # tools-deps (8)
- # transit (5)
- # vim (1)
- # vscode (1)
- # xtdb (45)
How come there's a special e/for
form? I read through the examples and I couldn't really find any explanation, apart from it being "reactive". But then I'm wondering why the sequence itself couldn't be reactive instead, so that the usual for
, map
, filter
etc could be used?
I'm guessing, looking at https://electric-examples-app.fly.dev/user.demo-system-properties!%53ystem%50roperties, that e/for[-by]
is only necessary at the edges, so it's probably not a huge inconvenience.
I guess so, but couldn't it still implement clojure.lang.ISeq
or whatever's necessary to support the core fns?
e/for
has the same use case as e.g. react keys - efficient (diffed) sequence handling. E.g. if a query returns 10 elements and you mount 10 <li>
s and the next query returns 9 of the same elements you want to reuse the 9 <li>
s you already mounted
re reactive data structures - probably, but then you'd need to convert to this data structure at the edges (reactive-seq (query-system-properties needle))
also note that fine grained reactivity wants you to break collections down to the smallest elements ASAP. Ideally a database would stream changes of your query reactively and you could skip the diffing entirely
the simple answer to why there is a special e/for form is that today the e/for semantics differ from clojure.core/for in several ways - in addition to diffing by react key (arity change), e/for is also eager whereas cc/for is lazy
separately, as to cc/map, cc/filter etc- we retain clojure compatibility, so we are careful to not change the semantics of clojure core operators. map and filter rebuild the list in clojure so they do the same in Electric. They also take clojure lambdas as an argument not e/fn. There are other possible designs, the one we chose is intended to maximize backwards compatibility with clojure so that pre existing macros (like —> , when-not, all still work - including complex macros like missionary)
finally, at some point you start to ask if the data structures themselves should become incremental, which is an open research problem. a lot of reactive language research gets stuck yak shaving here. we chose to use ordinary clojure data structures directly, which means assoc, get-in, etc are all ordinary (not incremental). this is another reason to take the tradeoff we made
Cool, thanks for explaining your considerations @U09K620SG!
(e/defn Main []
(js/setTimeout #(println "here") 1000))
When new’d up, I get
<unknown interop> {: :, :hyperfiddle.electric.debug/type :eval, :hyperfiddle.electric.debug/args (#object[G__78921] 1000), :hyperfiddle.electric.debug/origin #uuid "e2836829-54b0-41fc-8fbe-bb22dd6047fc"}
in reactive (defn Main [] ...) in app/plotly_interop.cljs line 117
in (try ...)
My goal is to refresh charts on a dashboard every n seconds. I looked at e/system-time but that seems to run far more frequently than I need. I only need to refresh every hour
You can truncate e/system-time-ms
to hours. Electric will efficiently work-skip consecutive values.
(e/def system-time-hours "hours since 1970 Jan 1"
(js/Math.floor (/ system-time-ms 3600000)))
Otherwise, (.setTimeout js/window #(…) …)
should work
I want to reinforce what Geoffrey said wrt "I only need to refresh every hour" - this imperative mindset is an anti-pattern. See https://electric.hyperfiddle.net/user.tutorial-backpressure!Backpressure
I’m sure there’s a ton that I don’t understand but, naively, the underlying electric clock is running at 120hz so there is some browser-side CPU work happening pretty frequently even if very little because of the Electric optimizations.
I’m pretty new to UI programming so maybe this is just how things are done in that browser environment
Hi! I’m asking if Datomic can act like xtdb v1 (in term of reactivity)? I mean you get a connection and watch the db snapshot. I don’t know if it’s possible with datomic
Yes it's possible at least in Datomic Onprem, you need to integrate the tx-report-queue API
the impl should look similar to the XTDB version
First try => https://gist.github.com/jeans11/845fdeedbf1257a8a3355d03f6bd4b31
Feel free to update. I didn’t have find a way to use the observe
function like xtdb. Missionary is realy cool!
Post in #CL85MBPEF where Leo will see it and you might get a code review from him 🙂