This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (9)
- # bangalore-clj (1)
- # beginners (130)
- # boot (6)
- # cljs-dev (8)
- # cljsjs (12)
- # cljsrn (3)
- # clojure (33)
- # clojure-brasil (3)
- # clojure-korea (4)
- # clojure-russia (150)
- # clojure-sanfrancisco (4)
- # clojure-spec (159)
- # clojure-uk (3)
- # clojurescript (100)
- # code-reviews (9)
- # core-async (1)
- # datascript (3)
- # dirac (58)
- # hoplon (8)
- # jobs-discuss (10)
- # luminus (18)
- # om (2)
- # onyx (14)
- # protorepl (19)
- # re-frame (34)
- # reagent (28)
Hi guys I’m catching up with version 0.0.8 How does one pass parameters to reg-sub handlers?
@hjrnunes Not possible to pass params to sugar version So, you'd do it the long hand way ...
(reg-sub :query-id ;; input signal fn (fn [[_ one two] _] ;; <--- destructuring query vector (subscribe [:a one two ]) ;; using values from the query vector ;; query fn (fn [a v] ;; 1st param will be the value returned by the signal ......)) ;; usage (let [val @(subscribe [:query-id 1 2])] ....)
I’m trying to wrap my mind around how to properly use datascript with re-frame. Has anyone done this already?
Posh has an explanation for the old way re-frame did things (and it was hacky as they just assoc’ed the datascript db onto the re-frame.db/app-state atom). I don’t think datsys is using re-frame.
I read the posh article this morning, but have not try it yet. Do you think there are big difference between working with reframe 0.7.0 and 0.8.0?
If so, it’s doing side-effects in the handlers. That’s the old way re-frame worked, right? As far as I can tell, we’re supposed to be injecting the datascript conn as a
cofx, then declaring effects that can happen with it using
reg-fx and then registering effectful events with
I've noticed that. If the old way works, I think it is feasible to change it to use the cofx way. Sorry not have a computer on hand.
@seantempesta I designed with that approach in mind. BUT I've never actually used datascript despite admiring it from a distance, so I've never been sure that plan would work
The next thing to consider, and something I'm a lot less confident about is subscriptions
(reg-sub :query-id (fn [v _] .....) ;; <- returns input signals (fn [?? v] .....)) ;; does the reactive computation
I had always hoped the input signal from datascript (to say that something had changed) could be captured somehow by the input signals function
So some thought was put into this ... in a hand waving way .... but nothing real
Just to be clear that "input signals" function can reach out and wrap anything including an atom or a reaction from anywhere ... including a datascript query looking for certain mutations?
Actually, the last time I chatted with the posh guys, they were looking for help to update their wiki page on how to best use Posh with re-frame. I guess someone’s just gotta give it a shot and then we can discuss the pros/cons to make a best practice?
@seantempesta: If you look at the example of rum/datascript at http://tonsky.me/blog/datascript-chat/ the model is awfully similar to re-frame - I’ve been wanting to look at datascript in re-frame for a while, and there’s 2 potential setup I can think of
- 1st (and less nice) is to add datascript as a layer underneath app-db, and using your app-db as a kind of derived view model from the datascript - this might make sense if you want to store a bunch of denormalized data, and then you transform it into something nice so that your subs and queries on app-db are more straightforward. I’m not sold on this as a general purpose solution as it seems like it might be adding an extra layer for little benefit, but if re-frame is “MVC-like” then this would be more “MVVM-like”, and I’ve kind of liked MVVM in some cases in the past. Might be a dumb idea though. 🙂
- 2nd (and much more integrated) would be to look at how
reg-event-db works and build
reg-event-datascript that injects your datascript state into the events in a similar fashion. I was having trouble figuring out how to do the subscription part, but maybe you can take the info from Mike above and make that work nicely!
Definitely keep us in the loop for how it goes, I expect there are a lot of people interested in how to do it for both datascript and in general.
@shaun-mahood: Yeah, I’m not exactly sure what to do either. The biggest problem seems to be that state can only be injected globally into re-frame. I ran into this issue before when I was trying to use
component to do dependency injection for re-frame. They just don’t play well together.
This is fine when you only have a single piece of state (`app-db`) that’s automatically injected everywhere. But there’s other state I need to manage. In addition to
Datascript, I have a
lunr.js search index that needs to be kept in sync with the datascript db. I also need to search it from re-frame event handlers. Right now I’ve been just directly referencing the instances as global variables throughout my app, and this feels so wrong.
reg-event-datascript function would need to refer to a global variable. This is how
reg-event-db is done in re-frame:
(ns re-frame.cofx (:require [re-frame.db :refer [app-db]] ... ;; Adds to coeffects the value in `app-db`, under the key `:db` (register :db (fn db-coeffects-handler [coeffects] (assoc coeffects :db @app-db))) <------------------ global reference ;; Because this interceptor is used so much, we reify it (def inject-db (inject-cofx :db))
Indeed. But there is only one
app-db so something somewhere is going to need to refernce it. Same for that datascript connection. I believe its okay.