This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-07
Channels
- # announcements (10)
- # architecture (25)
- # babashka (5)
- # beginners (95)
- # calva (1)
- # cider (3)
- # clerk (16)
- # clj-on-windows (41)
- # clojure (64)
- # clojure-europe (7)
- # clojurescript (9)
- # deps-new (2)
- # graalvm (25)
- # honeysql (3)
- # hyperfiddle (19)
- # malli (1)
- # meander (5)
- # music (1)
- # nbb (1)
- # off-topic (54)
- # rdf (10)
- # releases (2)
- # shadow-cljs (12)
- # tools-deps (41)
Interesting article that seems to mirror many of the comments made regarding functional effect systems from https://clojurians.slack.com/archives/C7Q9GSHFV/p1692205629281279?thread_ts=1692205629.281279&cid=C7Q9GSHFV https://www.1a-insec.net/blog/19-reactive-signal-and-build-system/ Particularly the end where the author is looking for the name of the algorithm Also > I feel that this algorithm may be adapted to work across multiple machines.
Yeah I've since had the thought that it would be cool to be able to persist a expression / node to disk via some kind of protocol
I think this is how you might build a database out of electric? Again more unrigorous shower thoughts ¯\(ツ)/¯
What would be the idiomatic way to structure the following workflow, • User uploads a file from electric to a ring handler via POST • Handler puts the file into a queue for processing • It takes around 5 to 10 seconds to process the file • Result is saved to postgresql db How would I go about notifying electric when pipeline is done processing so I can update the results div. Previously for a similar problem on another project I kept an atom on the backend and watched that from electric for changes but this seems like it is not scalable since an update will cause all clients to redraw their div including the ones that did not initiated computation.
perhaps the client attaches a uuid to the POST request, and your post handler carries the ID along and puts the ID in the global atom at the end, the client watches the global atom for their ID
the atom can contain a set of IDs and the client can disj their ID from the set when done
you can also use a missionary discrete flow instead of an atom if you want to get advanced
> perhaps the client attaches a uuid to the POST request, and your post handler carries the ID along and puts the ID in the global atom at the end, the client watches the global atom for their ID I already carry a UUID on the POST request but with this scheme when the atom is updated would this not trigger a update to all clients watching the atom? causing all clients to redraw their components instead of just one. Am I missunderstanding updates or can a client watch for partial changes to an atom? i.e changes only for the UUID?
ok, by "client" we really mean the connected client's backend, so the e/server side
watch the atom from e/server and check if the id is in the set from e/server
by client I mean each distinct browser session, so 10 users with 10 browsers all watching the same atom (defined on the backend clj side not in a electric file.) I watch this atom for changes from electric. When atom updates would this not notify all 10 browser session to update themself but only 1 of these will require a change?
something like this:
thanks I'll set this up, just to make sure I got the mechanics of this right, (if ((e/watch !bus) id)...) latest value of !bus still gets transferred to all browsers/sessions right?
use println to try it out and confirm
asking to get a better understanding.. it doesn't get sent to all clients because of this bit that filters by id in the e/server block, right?
((e/watch !bus) id)(e/def msgs (e/server (pad 10 nil (e/watch !msgs))))