This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-18
Channels
- # announcements (2)
- # babashka (35)
- # beginners (59)
- # calva (17)
- # cider (3)
- # clerk (7)
- # clj-kondo (21)
- # cljfx (9)
- # cljs-dev (76)
- # clojure (98)
- # clojure-austin (3)
- # clojure-brasil (1)
- # clojure-europe (11)
- # clojure-gamedev (4)
- # clojurescript (14)
- # consulting (7)
- # cursive (6)
- # datascript (4)
- # datomic (12)
- # emacs (18)
- # events (2)
- # graalvm (9)
- # humbleui (3)
- # hyperfiddle (18)
- # jobs (4)
- # missionary (12)
- # nextjournal (2)
- # nrepl (7)
- # off-topic (31)
- # practicalli (2)
- # rdf (6)
- # releases (2)
- # scittle (10)
- # xtdb (9)
Hi! CodeMirror and ProseMirror have some built-in capabilities for collaborative editing. But as far as I'm aware, both are strictly client-side Javascript libraries. Electric doesn't have the "client side only" limitation. Has anyone tried using Electric to provide reactive network behavior collaborative editing with CodeMirror or ProseMirror? https://codemirror.net/ | https://prosemirror.net/
collab editing demo: https://prosemirror.net/examples/collab/#edit-Example (two tabs)
I think a CRDT is the right approach for this, I don't see any obvious benefit in reimplementing the CRDT with Electric
i.e. https://marijnhaverbeke.nl/blog/collaborative-editing.html - the core patterns here do not come for free with Electric
Right, the merge logic is not trivial at all. It probably makes more sense to solve that in Electric userspace. Different Electric might have different persistence layers, and might need different kinds of editing interfaces.
Hi, still very new to electric but really liking it. I'm wondering how to go about doing the following.
I want to click a button on the client that initiates a "stream" of random numbers, with some time delay between them, and eventually terminating.
below the button i want a dom element to show the random numbers, accumulating them as they arrive.
I have it working with e/watch
and e/def
and an atom
#?(:clj (def !x (atom [])))
(e/def x (e/server (e/watch !x)))
...
(dom/div
(dom/button
(dom/on "click"
(e/fn [e]
(e/server
(future
(dotimes [_ 10]
(let [n (rand-int 100)]
(Thread/sleep 100)
(println (swap! !x conj n))))))))
(dom/text "button"))
(e/for [n x]
(dom/text (str n " "))))
But in the "real" version of this i want to start many such short lived processes on the server that should stream their updates to the client. I'm wondering what's the Electric way to create an "anonymous" flow on the server (without e/def) and stream the results to the client.
I think I've been slowly making progress towards understanding enough to do this, reading electric source code and refreshing my missionary knowledge, but if anyone has a quick example in the meantime that'd be greatWe're calling this "progress" (i.e. a button that has a progress indicator while it downloads something)
The current ui4/button can kinda do this but there is an impedance mismatch, it wasn't really designed for that. We've learned a LOT since throwing that together and this is part of the current active workstream to rebuild the UI namespace
Here is a hacked together example of a button with progress under the current ui4/button
I make no claim that this is idiomatic, it surely will evolve, just giving you something that works today
It is almost certainly "bad" - the natural way to model this is to have the button's reactive callback return a sequence of reactive values, but unfortunately the button has some weird semantics on that callback, we're taking a look at it like tomorrow
I ran into a similar case when I want to run an electric function on a callback and the function involves network calls/delays that could cause it to outlive the callback fn's lifecycle. I've been using this pattern of having a atom-wrapped boolean to signal when to do something and changing that in a callback. It doesn't read well but it gets the job done
(e/defn Foo []
(let [!do-thing? (atom nil)
do-thing? (e/watch !do-thing?)]
(when do-thing?
(SomeElectricFn.))
(dom/div
(dom/button
(dom/on "click"
(e/fn [e]
(reset! !do-thing? true)))
(dom/text "do the thing")))))
the ui4/button's "callback" will terminate and unmount after the first non-Pending value is seen, which Leo flagged as a terrible idea many months ago
to be clear, dom/on
is the actual thing that sucks