Different approaches to reactivity

[sid597]

• Get all the nodes once and then render the node component
• Just get the id of each node then for each id create a new component, the component will get the data corresponding to the node
  • all at once say
  • each individual field queries its data

I think the main point is what I want to render when the data changes so if a new node is added do I render all the nodes again? what about updating just a single node among thousand of others.

[sid597]

(defn type-1 []
  (e/client
    (svg/svg
      (for [node nodes]
        (svg/rect
          (dom/props {:x (e/server (watch (:x node)))
                      :y (e/server (watch (:y node)))
                      :id (e/server (watch (:id node)))})
          (dom/on "mousemove" (e/fn 
                                ;; Assume the function Update which takes in db and path to update at and the new value
                               (e/server (update db [:x (:id node)] new-pos))))
          (dom/text (str "This is node "(watch (:id node))))))
      (for [edge edges]
        (svg/line
          (dom/props {:id (str (e/server (:id (:source edge))) "-" (e/server (:id (:target edge))))
                      :x1 (e/server (watch (:x (:source edge))))
                      :y1 (e/server (watch (:y (:source edge))))
                      :x2 (e/server (watch (:x (:target edge))))
                      :y2 (e/server (watch (:x (:target edge))))})
          (dom/text (str "This is edge between " id)))))))
  ;; My understanding of this style:
  ;; Node and edges component are not dependent on each other, no one calls the other to update something
  ;; We update the global data which is the only source of truth.
  ;; This approach is good if the latency is extremly good and db is in the client memory. 
  ;; Reasoning about it is easy we can see the values that are being read and written to in the db and 
  ;; how the client renders it, it is also clear which part is dependent on what and when will it change.
  ;; It would have been very good if this was it, code is simple and elegant, very easy to maintain. 
  ;; But since the latency is not good we have to use some other strategy to make it performant. 
  ;; data model includes 2 seperate maps for storing nodes and edges. Each node stores its x,y, and other properties.
  ;; each edge has its id, source node id, destination node id.


;; Now lets look at some potential solutions or approaches:

(defn approach-1 []
  ;; One type of solution to above problem is:
  ;; Since UI are streaming dag (hyperfiddle statement) and edges are inherently dependent on nodes
  ;; we use this feature to create dependency explicitly
  ;; We change the data model from independent nodes and edges to a hybrid approach where we have both of them independendly
  ;; but each node also knows about its in and out edges. So each node has following Type of data structure. 
  ;; {:x ..
  ;;  :y ..
  ;;  :in-edges {:edge-id {:id .. 
  ;;                      :source-id {:x ..
  ;;                                  :y .. ...}}}}
  ;; 
  
  (e/client
    (let [global-store (get db-dump)
          ;; Above we are asking for one time db values to load into the client
          ;; The data is going to be of the format
            #_{:nodes {:node-1 {:x 10
                                :y 5 
                                :in-edges {..}
                                ..}}
               :edges {:edge-1 {:id "node-1--node-3"
                                :source-id "node-1"
                                ...}}}]
      (svg/svg
        (for [node (:nodes global-store)]
          (let [!x (get (:x node))
                x (watch !x)
                !y (get (:y node))
                y (watch !y)
                !id (get (:id node))
                id (watch !id)
                !in-edges (get (:x node))
                in-edges (watch !in-edges)] 
            (svg/rect
              (dom/props {:x x 
                          :y y
                          :id id})
              (dom/on "mousemove" (e/fn
                                    ;; update the component's local values 
                                    (reset! !x new-x)
                                    (reset! !y new-y)
                                    ;; And for consistency create an update on the server assuming its going to be written
                                    ;; but the cavet here is that we are not dependent on the server value we only read it on
                                    ;;initialisation.
                                    (e/server (update db [(:id node) :x] new-pos))))
              (dom/text (str "This is node "(watch (:id node)))))
           (for [edge in-edges]
             (svg/line
               (dom/props) ;; get all the edge data props here)
               (dom/text (str "This is edge between " id))))))))))
    ;; The issue with this is that I don't know how the edge update will happen. Since the edge is reactively dependent
    ;;on the node's position but each edge (the same edge) is also being created in 2 seperate node instances
    ;;Also this has turned into not elegant and hard to reason about code. 
    ;; Also not clear how new nodes will be created what happens when node's position changes does the edge rerender
    ;; or is replaced by a new one like in functional programming
    ;; But what I like about this approach is the local value updates and dependencies being updated based on the local
    ;;values alone, its very well scoped to the component itself and is easy to reason about on a component level.
    ;; another thing is we don't have to worry about the in-memory structure, the load times if the nodes are too much
    ;; how to subscribe to the big list of elements in-memory. It provides fine grain reactivity on a local level. 
    ;; Having a optimistic update infrastructure would be I think easier to integrate because the values are being updated
    ;;and watched on the scope of each component only. Its not like we have to update a value and then worry about the 
    ;; latency of component update and how to propogate that optimistic update to its dependent components.  ))   
    

(defn approach-2 []
 ;; Another approach is to get the db-dump on start just like in approach-1 and do all the
 ;; actions on this in-memory global state
 ;;But the issue is how to represent this in memory, such that we can acheive fine grained reactivity I suppose 
 ;; all of it is going to be atom in the global store 
 ;; What I don't like about it is that now I have o have some sort of optimistic update infra. Once we have that infra
 ;; we have to update the client side gloval values optimistically and watch it. I think this would create a little (maybe)
 ;; bit more latency (not sure if this would be noticable though) 
 ;; This might be a practical approach that would work for small graphs, easish to understand and reason about.
 ;; What I don't like is having 2 sources of same infrastructure where the client side infra is to be hacked together
 ;; by me and is not going to be as good as the server infra. its like me implementing my own db in frontend. 
 ;; I am not sure if this type of architecture would be frp style anymore, looks more of hacked together. It makes 
 ;;me think if using hyperfiddle using this would even make sense. Hyperfiddle is about streams, signals, reactivity
 ;; watching and then updating values, treating ui as streaming dags. 
 ;; This architecture makes me feel not in line with it line with streaming architecture of hyperfiddle, missionary and rama   .
  (e/client
    (let [global-store (get db-dump)
          ;; Above we are asking for one time db values to load into the client
          ;; The data is going to be of the format
          #_ (atom {:nodes (atom {:node-1 (atom {:x (atom 10)
                                                 :y (atom 5)
                                                 :in-edges (atom {..})
                                                 ..})})
                    :edges (atom {:edge-1 (atom {:id (atom "node-1--node-3")
                                                 :source-id (atom "node-1")
                                                 ...})})})]
      (svg/svg
        (for [node (watch (:nodes @global-store))]
          (let [x (watch (:x node))
                y (watch (:y node))
                id (watch (:id node))]
            (svg/rect
              (dom/props {:x x
                          :y y
                          :id id})
              (dom/on "mousemove" (e/fn
                                    ;; update the in memory values
                                    (reset! global-store [:nodes :id :x] new-x)
                                    ;; update on server for next time and data persistence
                                   
                                    (e/server (update db [(:id node) :x] new-pos))))
              (dom/text (str "This is node "(watch (:id node)))))))
        (for [edge (watch (:edges @global-store))]
          (let [id (str (watch (:id (:source edge))) "-" (watch (:id (:target edge))))
                x1 (watch (:x (:source edge)))
                y1 (watch (:y (:source edge)))
                x2 (watch (:x (:target edge)))
                y2 (watch (:x (:target edge)))]
            (svg/line
              (dom/props {:id id
                          :x1 x1
                          :y1 y1
                          :x2 x2
                          :y2 y2})
              (dom/text (str "This is edge between " id)))))))))
          


(defn approach-3 []
  ;; not going to write code here because I don't know how to write it, but I have an approach in mind which I know
  ;; parts of how to implement. 
  ;; I am thinking of making a universal client side stream/signal and add listeners to that stream. 
  ;; The listeners would be responsble for updating client side and server side values. In my head this is elegant solution
  ;; Assume every client side event from any component is listened to and then put on the global stream with some metadata
  ;; like (:update some-position) and then there are watchers of the global stream that sample the stream at some rate. 
  ;; Say a node component is listening for updates to :x value and it sees (:update [:node :id :x]) after some inquiry 
  ;; determines that this is of use to him then uses it. There can be another listener that update the server value 
  ;; But this server listener accumulates say 50 such events and only update the last one of these 50 i.e discarding 49 values
  ;; to not overwhelm the db but also update it at right cadence to facilitate collaboration. 
  ;;   .
  ;; 
  ;; Now thinking is it any different that using a global in-memory value like in approach-2??    .)
  ;; Example this is how I listen to "mousemove" event using missionay:
    (defn el-mouse-move-state> [movable]
      (m/observe
        (fn [!]
          (let [sample (fn [e]
                         (! (do
                              (.preventDefault e)
                              [(.-clientX e)
                               (.-clientY e)])))]
            (.addEventListener movable "mousemove" sample #js {"passive" false})
            #(.removeEventListener movable "mousemove" sample)))))


    (defn el-mouse-move-state< [movable]
      (->> (el-mouse-move-state> movable)
        (e/throttle 1)
        (m/reductions {} [0 0])
        (m/relieve {})
        (m/latest (fn [[cx cy]]
                    (let [ctm (.getScreenCTM movable)
                          dx  (/ (- cx (.-e ctm))
                                (.-a ctm))
                          dy  (/ (- cy (.-f ctm))
                                (.-d ctm))]
                      [dx dy])))))
   (new (el-mouse-move-state< dom/node)))

;; Maybe this can be abstracted out to write to a more gloval sstream, but the more I think this seems like 
;; me implementing the approach-2, there seem to be some similarities.