This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-13
Channels
- # babashka (5)
- # beginners (52)
- # biff (11)
- # brompton (5)
- # calva (2)
- # cider (7)
- # clojure (80)
- # clojure-europe (3)
- # clojure-finland (1)
- # clojure-nl (3)
- # clojure-norway (1)
- # clojure-uk (3)
- # clojurescript (15)
- # conjure (4)
- # core-async (9)
- # cursive (3)
- # datahike (38)
- # datascript (1)
- # datomic (7)
- # duct (9)
- # emacs (4)
- # fulcro (11)
- # graalvm (21)
- # honeysql (5)
- # lambdaisland (1)
- # leiningen (1)
- # news-and-articles (1)
- # off-topic (8)
- # react (42)
- # reagent (6)
- # reitit (11)
- # shadow-cljs (62)
- # specter (1)
- # spire (2)
- # sql (1)
- # tools-deps (12)
- # vim (5)
alright, here’s been my big WIP for the last month or so: https://github.com/Lokeh/serenity still WIP but is actually pretty close to being release worthy IMO
TL;DR it’s like reagent’s ratom/reaction lib, but a little more disciplined and setup to one day interop with a Concurrent Mode-like scheduler
what do you think of resuming being disabled in react? For me this feature was the biggest pull to it, without this, I am not sure async rendering is really worth it even.
I haven’t looked at the latest stuff w.r.t. async rendering pausing/resuming in React
This is fantastic, I like it. I was expecting to have an immediate desire to shift the api, but it matches really nicely with how something like this should look. I'll have to dig in to how this works with react and local state, but this is exciting!
Is a sink just an action in reaction to a source changing? Any reason to not support add-watch instead of a specific api?
yes, a sink is an object that represents an action in response to a source or signal changing
I’ve based a lot of the underlying mechanics of the library on an OCaml library called Incremental, which has separate “observers” that are distinct from computations
While I like your aesthetics, I think it's better to learn less things and copy the language's existing pieces.
one benefit (I think) is that this simplifies garbage collection and cutting off computation of nodes
once a sink goes out of scope and GCd, it can then automatically dispose itself and all connected signals
harder to do that with signals because they potentially have many different connections
but maybe it doesn’t really matter and it would work with add-watch too, it’s all just theory
the other nice think about sinks is that they are always a leaf in the fully connected graph
so imagine you had a utility that drew a graph of all the nodes that were connected to the thing that is causing your component to re-render
since you have a sink, you can hand it to that utility and be guaranteed to only see the part of the graph that your component depends on
actually, that would probably work with signals too since I separate edges to the node and edges from the node...
You could do that watch key as well, the distinction is reification through key or reification through var.
yeah, i guess it feels a little weird to have add-watch / remove-watch be side-effecting, in that adding or removing watches may cause a signal to come alive or go dormant
and having specific nodes that are only for side-effects pleases my pure FP architecture astronaut sensibilities
@lilactown do you envision this being used in a let or in a global? Thinking wrt to react
the primary use case I would expect w.r.t. React is to have serenity sources for things like remote data caching; state that you need to live completely outside of the component tree
so you might have some sources/signals/sinks that are def
ed at the global level, but then inside of components you could use a hook like:
(def dbA (s/source ,,,))
(def dbB (s/source ,,,))
(defnc my-component []
(let [data (use-signal #(merge @dbA @dbB)) ;; dynamically creates a new signal and subscribes to it
,,,]))