re-frame trace 0.1.12 is out now: https://github.com/Day8/re-frame-trace/releases/tag/0.1.12

^^^ we can spend a bit more time/budget on re-frame-trace so there will be one further release soon (before Christmas) but, in the meantime, we've done this release so people can try it and give feedback .... and, of course, provide PRs for things they'd like to see added. re-frame-trace is pretty usable at this point (although still a work in progress)

We'll run out of time/budget soon and have to go back to money-making stuff. So the window for feedback is now. Give it a go.

Feedback: Please use a dynamic var, not a Closure define, as mentioned here https://github.com/Day8/re-frame-trace/issues/75#issuecomment-343685227

@jeaye we have no experience with React Native so this kind of work will have to be delivered via PRs supplied by others.

We're open to the idea, but just a bit clueless

This request is only for a dynamic var for enabling re-frame-trace, rather than a Closure define.

Oh, I see

React Native experience isn't assumed or required. 🙂

You'd be amazed at how opaque that was request was :-)

Yep, I see how I could've worded that much more clearly.

Sorry about that.

All good

We're keen to help

But you might have to do the PRs

That one would be pretty easy, I'd imagine

Or at least create a clear Issue for Daniel

My assumption is that a Closure define was used to better elide code when tracing is disabled, but it is the one bit of logic that, at this point, is needed to support RN. Do you know of any other reason to prefer a Closure define?

I've got a feeling he might not have got your meaning either

Ahh, right

@mikethompson Daniel and I had a good discussion on the meaning, but it looks like I need to clarify further. 1. The ticket was opened as a request for RN support, which Daniel made clear wasn't going to happen on your end (he and I had a VOIP call to discuss what would need to be done); 2. After hacking changes into both re-frame and re-frame-trace, I was able to prototype a solution which works with RN. One key thing that needs to be done, on the re-frame-trace side, is moving away from the Closure define.

So I bring that up separately here, since it's a bite-sized task that doesn't require RN knowledge.

@danielcompton ^^^

I linked to the ticket only because I provided a list there of the things which need to be addressed in order to support this.

Okay, got it.

Does RN need only this one issue solved, or are there many?

I know the guys over at re-frisk-remote are doing something with it, but I'm not sure what exactly they're up to.

@mikethompson There are two. One logic, one organization. 1. Dynamic var vs Closure define; 2. The UI code needs to be removed from trace.cljs and put anywhere else.

In re-frame, there are two issues as well. 1. js/performance doesn't exist, so it can't be referenced; 2. java.lang.Exception is improperly referenced in a cljc file which is actually compiling for CLJS, just in a macro

@jeaye open up some issues for them on the right repositories and we can take a look. Not too keen on getting rid of the closure define, as it helps a lot for DCE, but there might be other ways around it

Can this be rewritten in a better way?

(reg-sub
 ::last-result?
 (fn [[_ id]]
   (subscribe [::substate id]))
 (fn [substate [_ id query]]
   (get-in substate [:last-result? query]))

afaik the new thing is - because subscriptions are cached, you can do this

(defn some-ui-thing [id query]
  (let [sub-state @(subscribe [::substate id]            
        last-result @(subscribe [::last-result? id query])]
    [:div (pr-str last-result)])

(updated my question)

then your sub is

(reg-sub ::substate 
     (fn [[_ id] ...))
 
 (reg-sub ::last-result
   :<- [::substate]
   (fn [substate [_ id query])
     (get-in substate [:last-result? query)))

unless did I misunderstand the question?

I think my question is, if you still need the two funs, or can the :<- [::substate] syntax also be used with dynamic values?

oh I see

I'm not sure I'm afraid

@borkdude I’be been writing it that verbose way

I wasn’t sure if the “caching” thing was the only good reason for having the separate fn’s

I was wanting to write some sort of helper soon though to make that pattern less clunky.

Where is :<- documented? (Googles does not make this search easy... 🙂 )

@deg https://github.com/Day8/re-frame/blob/v0.10.2/src/re_frame/subs.cljc#L248

Ah, thanks. Nowhere in the docs directory?

Hmm not sure on that one

@deg the docs here: https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md ask you to read through all the todomvc example which includes: https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/subs.cljs#L126-L134

Also, in the API docs: https://github.com/Day8/re-frame/blob/master/docs/API.md if you click on reg-sub, you'll get to what @mikerod pointed to

thanks

I have two subscription, but I’m confused why the second receives a subscription and not the result of the subscription:

(reg-sub
 ::subnav-config
 (fn [db [_ page-id]]
   (subscribe [:dre.search.subs/subnav #_(get-in db [page-id :page/subnav-sub])])))

(reg-sub
 ::subnav-visible?
 (fn [[_ page-id]]
   (subscribe [::subnav-config page-id]))
 (fn [config _] ;; config is a subscription here, why?
   (:subnav/visible? @config)))

(get-in db [page-id :page/subnav-sub]) evaluates to a keyword: :search.subs/subnav

Maybe (subscribe [::subnav-config page-id])) returns a subscription of a subscription?

hmm, it doesn’t matter when I replace the expression with a keyword literal

@borkdude that's the low level way of chaining subscriptions

@danielcompton Then why does this work without deref?

(reg-sub
 ::last-result?
 (fn [[_ id query]]
   (subscribe [::substate id]))
 (fn [substate [_ id query]]
   (get-in substate [:last-result? query])))

Isn’t that the same?

sorry, can you explain the question more? Not quite following

In the latter example ::last-result?, the second function receives the result of the subscription, not the subscription itself

But in my first example ::subnav-config and subnav-visible?, I have to deref config

subscribe returns a Reagent Reaction. If you use a single computation function (which used to be the only way to do this), and call subscribe, you are returned a reaction that you need to dereference.

re-frame provides an additional sugared version of reg-sub where you can provide a second "inputs" function. This function does subscriptions and (normally) returns reactions. When your computation function is run, re-frame derefs all of the reactions returned by the inputs function, so you don't need to.

In your case, ::subnav-config is returning a reaction, which is then wrapped up in a parent reaction. If you want to do a subscription like that then it should be dereferenced before returning

As a general rule of thumb, you shouldn't need to be doing any dereferencing inside a subscriptions computation fn or inputs fn, because re-frame does all of the necessary work for you. You just write functions that take data and return data (or return reactions in the case of an input fn)

> which is then wrapped up in a parent reaction why?

oh I see

normally you would return a plain value and now this value is wrapped in a reaction, like every value

so I should write:

(reg-sub
 ::subnav-config
 (fn [db [_ page-id]]
   @(subscribe [:dre.search.subs/subnav #_(get-in db [page-id :page/subnav-sub])])))

This also works, but maybe it comes down to the same:

(reg-sub
 ::subnav-config
 (fn [db [_ page-id]]
   (subscribe [:dre.search.subs/subnav #_(get-in db [page-id :page/subnav-sub])]))
 (fn [val [_]]
   val))

oh it doesn’t work, because when I add the second function, the destructuring of the first function breaks

I’m not sure if I can get access to the db when I use multiple functions. Can’t see an example here: https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/subs.cljs

So, to rephrase my question, if I use something like this:

(reg-sub ::some-sub
  (fn [...] (subscribe ...))
  (fn [res] (:foo res)))

@borkdude you can have multiple subscriptions

at the same time so:

(reg-sub ::some-sub
  (fn [...] [(subscribe [:db-one]) (subscribe ...)])
  (fn [[db res] _] (:foo res)))

your signal fn can return a vector of multiple subscription “signals”

you can include a “db” one there

I don’t typically need the root db though, you may just want a subs accessor on some part of it

However, in your question I’m a bit confused which of the 2 functions you want the db to passed to

The first one

The signal returning fn (don’t know correct term here I don’t think) it takes the same arg vec as the subscription

So I think you may just want to structure a bit differently

Yeah, usually you shouldn't be accessing DB directly

except for top level subscriptions

as any change to DB will cause everything depending on it to rerun

So usually you would have a subscription returning the parts of app-db you want, and then depend on that

What I’m doing: I have a subnavigation component that can have specific behavior per page. I want to have a subscription per page that this subnavigation component subscribes to.

This subscription tells the component if it should be visible, etc.

E.g. “if the number of search results is 0, the subnavigation component should not be visible"

so I want the visibility to depend on things, instead of setting it manually

and these “things” are different per page

hence a subscription per page