Hi guys I’m catching up with version 0.0.8 How does one pass parameters to reg-sub handlers?

Or rather, how does one declare them to use them in the handers?

Also, is it possible to pass parameters using the macro sugar or not?

@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?

Does the github projects posh and datsys helps?

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?

this one? https://github.com/mpdairy/posh/wiki/Re-frame-Integration

Yeah

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 reg-event-fx right?

So that way the event handlers stay pure?

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

I designed reg-sub so there's an "input signals" fn

(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?

I have to do a taxi run for a family member

okay, thanks

I'm pretty sure the posh guys would be helpful

And I'm certainly keen to make it happen too

Thanks

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?

Haha...

I am a newbie of clojure and not familiar with datascript, but if you don't mind...

Yeah, I’ll work on something. 🙂

@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.

great!

@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. Even a 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.

@mikethompson thanks Mike, that was helpful!