This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (3)
- # babashka (64)
- # bangalore-clj (1)
- # beginners (12)
- # calva (21)
- # cider (7)
- # clj-kondo (16)
- # cljdoc (1)
- # clojure (49)
- # clojure-dev (2)
- # clojure-europe (10)
- # clojure-germany (3)
- # clojure-italy (1)
- # clojure-uk (13)
- # clojuredesign-podcast (6)
- # clojurescript (2)
- # code-reviews (21)
- # data-science (2)
- # datomic (3)
- # emacs (20)
- # events (1)
- # fulcro (2)
- # graphql (4)
- # java (3)
- # malli (14)
- # off-topic (45)
- # re-frame (2)
- # shadow-cljs (7)
- # tools-deps (167)
- # vrac (14)
- # xtdb (4)
@yogthos There is a particular situation about the indexes which requires some more thinking.
Supposing that we have a subscriber which is listening for changes in a
:users list at the index
3. Now, there is a change which inserts an element at the index 3 of that list. What should we tell the subscriber?
1. Nothing because it is not the element it was interested in.
2. We tell it about the new value because the subscriber was interested at the value at the index 3 specifically.
The answer to this question depends on what the subscriber wants. I am thinking about having some more options in the
subscribe-on-path function to let the user express exactly what s/he wants in the case of indexes.
But before I do that, I would like to see how the index-based subscriptions are really used by the template (which I did not implement yet), so I will leave it as it is now and will be back on those issues later.
Additionally, when a diff removes or inserts elements in a vector, the indexes of the subscribers in the subscriber-tree need to be updated. Since the subscriber is registering/unregistering via a path, it creates a problem which I will need to solve at some point.
One solution would be to have a index translation table near the
children hashmap which keeps track of the registered key and the current key.
Intuitively, I think that if the element in the template …
1. is accessed via
(-> global :users 3), then the subscription wants that specific index’s content.
2. is accessed via a
for block, then the subscription should track an element’s identity and not its position in the list.
I think in cases where the indices change, the subscription should get updated as well since it's tracking a particular piece of data
I agree, but if the user explicitly want
(-> global :users 3) and we prodive
(-> global :users 4) , s/he won’t be happy.
I think that this issue can be resolved later, when the full stack of Vrac starts to work. We will know more at that time.
Documentation updated - https://github.com/green-coder/vrac/blob/diy-furry/doc/prototype-v2.md
For the graph of compute nodes, here is my (non-optimized) plan: 1. Each compute node’s update function should return a diff. Vrac will use that diff and apply it on the node’s old value to get the new value. 2. Each compute node’s update function should accept (for each of its inputs) a diff, an old value and a new value. 3. Each update function has to be pure.
Thanks to the
subscriber-tree , each node have the list of its dependent nodes. Each compute node should also have the list of its inputs, so it can unsubscribe on them later, even if it sounds like a redundant. I will reorganize/optimize it later.
Maybe I can have a hash-map
dependent-compute-node -> subscribed-path-list next to the
subscriber-tree in each node, to make the unsubscribing simpler.