Is there a reason why a subscription gets only one source (the db or an other subscription)? I have started implementing my first app. I have a subscription :navig-params which provides me URL parameters (which are stored by an event handler in the db). Then I have another subscription :items which provides all "items". Now I wanted to create a third subscription :current-item which would join data from :navig-params and :items to find the item which is selected by the url. But this seams not possible in re-frame. How is this join-Problem supposed to be solved in re-frame? Thank you!

I have some subscriptions that depend very much on the selection in the navbar I solved it like this

(re-frame/reg-sub
  ::middle
  (fn [db]
    (case (:selected-nav db)
      :home [(:selected-nav db) (:transactions db)]
      :bank-employee [(:selected-nav db) [(:employee-iban db) (:transactions db)]]
      :client [(:selected-nav db) [(:login-status db) (:transfer-data db) (:transactions db)]]
      :background [(:selected-nav db) nil]
      [:non "error, should not be possible"])))

I’m not sure if thats a good way, but I like it better than having multiple layers of subscriptions and/or subsribe to the whole state

I try to get everyting a component needs on the same level in the main db atom, but that is not always possible

@witek subscriptions can have as many inputs as needed

There's no limit to 1

(reg-sub 
    :something  
    
    ;; signal fn 
   (fn [_ _] 
        [(subscribe [:blah])  (subscribe [:other])])    ;; signal returns to inputs

    ;; computation fn 
    (fn [[blah other] ...]        ;; two inputs are destructured as first arg
        ... use blah and other))

@witek we don’t provide a way to get access to db and another subscription as an input, because 99.99% of the time, you should just make two subscriptions as inputs, rather than chaining off app-db directly

Whenever app-db changes, all of the subscriptions that depend on it re-run, so you want to avoid having too many subscriptions on the root