Clojurians Log v2

Yeah, I have to admit, I find the browser API to be good enough for such tasks.

Hello everyone. I might ask a stupid question, so please forgive me. The context of my question is the following: I would like to use the datalog query engine with re-frame. To that end, I turned to datascript. I know that re-posh and posh exists to fulfill that goal and that you can combine them. However, I would like to understand why we could not use the normal re-frame workflow: datascript database are immutable values. So we could store multiple datascript database/structure in our re-frame app-db in a given path (say [:ds]) and apply transaction to that immutable value and replace it. My understanding is that subscription should work as intended as since whenever we modify datascript datastore under the [:ds]` path, there would be reactions computed by the re-frame data flow. I attached some code to display the behavior.

(ns play.core
  (:require
   [clojure.string :as str]
   [datascript.core :as d]
   [re-frame.core :as rf]
   [reagent.core :as reagent ]
   [reagent.dom :as dom]))

(rf/reg-event-fx
 ::init
 (fn [_ _]
   {:db {:ds (d/empty-db {:aka    {:db/cardinality :db.cardinality/many}
                          :name   {:db/unique :db.unique/identity}
                          :friend {:db/valueType :db.type/ref}})}}))
(rf/reg-sub
 ::datoms
 (fn [db _]
   (when (:ds db)
     (d/datoms (:ds db) :eavt))))

(rf/reg-sub
 ::ds
 (fn [{:keys [ds]}] ds))

(rf/reg-event-fx
 ::transact
 (fn [{db :db} [_ data]]
   {:db (assoc db :ds (d/db-with (:ds db) data))}))

(defn app []
  (let [datoms (rf/subscribe [::datoms])]
    (fn []
      [:div {:style {:width "100%"}}
       [:pre {:white-space :pre-wrap
              :word-wrap :break-word}
        (into [:<>] (interpose [:br] @datoms))]])))

(defn mount []
  (dom/render [app] (.getElementById js/document "app")))

(defn main []
  (rf/dispatch [::init])
  (mount))

(defn ^:dev/after-load reload []
  (mount))

(comment

  (rf/dispatch [::transact
                [{:name  "Mickey", :age 32, :aka ["A" "B" "C"], :friend 10}
                 {:name  "Mimi", :age 10, :employed? true, :married? true}]])

  (rf/dispatch [::transact
                [{:name  "Hello", :age 15, :aka ["X" "Y" "Z"], :friend 2}
                 {:name  "World", :age 37, :employed? true, :married? false}]])

  (rf/dispatch [::transact
                [{:name  "Pietr", :age 15, :aka ["X" "Y" "Z"], :friend 2}
                 {:name  "Mary", :age 37, :employed? true, :married? false}]])

  (rf/dispatch [::transact
                [{:name  "Mickey", :age 60, :aka ["A" "B" "C"], :friend 10}
                 {:name  "Mimi", :age 14, :employed? true, :married? true}]]))

So whenever I evaluate the dispatch, I can see the view being recomputed, which achieve the desired behavior. I wonder what would be the drawback?

The ::ds sub couples your views to your data. There's an article about such subs and why they're bad, somewhere in re-frame FAQ I think. Also

(rf/reg-event-fx
 ::transact
 (fn [{db :db} [_ data]]
   {:db (assoc db :ds (d/db-with (:ds db) data))}))

(rf/reg-event-db
 ::transact
 (fn [db [_ data]]
   {:db (update db :ds d/db-with data)}))

Note also that if you can store your data as regular maps and query it as well, then using datascript will definitely have a performance impact, maybe a noticeable one. If you use a lot of subs with EQL (I think that's the name), then they will all be re-run each time db (or (:ds db) if you use layer 2 subs) changes.

Thanks a lot for the advice. My goal was not to have use the query engine for the whole app-state logic, but a few of my views requires queries that are convoluted.

About subs with EQL, I though only subscriptions that were in use in the actual view would rerun?

Say view A uses subs :a, and view B uses :b, if users navigate from A to B, then I thought :a would be disposed and not recomputed?

Right, of course - only the ones that are in use. But all of them. :) Meaning, you cannot have many layer-3 subs. (also correction to the above - it should've been "layer 3 subs") To illustrate my point. Consider you have this map:

{:a {:b {:c 1}}}

Why would that be?

Thanks a lot. I will try to make my experiments. But I think if the value in app-db is immutable, layer 3 should also work! I will run some experiments! Thanks!

Sure, no problem. > Why would that be? When you run an EQL query, you run it on an instance of a database. The result of a query is some data. You cannot reuse that data in place of a database. Of course, you can lay other subs on top of a EQL sub. It's just that those subs won't be EQL ones. Meaning, you can have only a single EQL layer.

Exactly.

Are top level (let [foo @(subscribe [:foo])] ... in components a bad idea? I am pretty sure they are but I don't fully comprehend how automagic efficient rerendering works. If foo changes I'd expect the entire component to re-render, but if it's (let [foo (subscribe [:foo])] ... with @foo in certain places, will only relevant parts of the component re-render?

relevent: https://stackoverflow.com/questions/46176515/clojurescript-re-frame-subscription-dereferencing-dilemma so I guess it's perfectly fine?

It's not about how you manage your hiccup, it's about how you organize components. If you deref a sub in a component, then it will be rerendered each time the sub changes. Unless it's a form-2 component and you deref the sub outside of the render function. And yes, using @(subscribe ...) is absolutely fine.

Hey, just noticed that Re-Frame officially hit 1.0 a couple days ago, so just wanted drop by and say congrats to the team!