Hi! I'm trying to run an "after" interceptor:

(def ^:private reorder-after-interceptor (re-frame/after (partial order-questions)))

what should I put inside "order-questions" to update: (:questions db) ??

(update-in questions new-ordered-questions) ??

after the initial ajax load, I need to re-order the ordered-map (:questions db)

Can I register a default subscription? Getting tired of retrieving simple keys from the root of the app-db.

I guess it makes it hard to detect when a particular part of state is updated, and tie it to a component.

@danielstockton not sure what you mean by default, but I’ve got a dead simple subscription for stuff like that, that is ostensibly “what key in a specific path in the db do I want to fetch”

The key being a parameter to the sub

@samueldev That's what I'm looking for, but I only see how to register subscriptions using a particular key.

If you have one subscription doing that, then that's what I'm looking for really

@danielstockton You can give subscriptions arguments, so it wouldn't be too technically difficult to implement such a thing... but you'd lose all the benefits of subscription cacheing, which is why iirc the docs discourage this approach. Still could be reasonable to do it while prototyping.

(re-frame/reg-sub
 ::default
 (fn [db [_ k]
   (k db)))

yeah, the last heading on https://github.com/Day8/re-frame/blob/master/docs/SubscriptionsCleanup.md covers this idea

Thanks @andrew354, thought it might come with some downsides.

The other way that I've thought about would be a macro that generates simple subs.

(make-subs [:a :b :c]) which could expand to:

(rf/reg-sub
  ::a
  (fn [db]
    (:a db)))

...

haven't gotten around to doing so, but that could cut down on a lot of boilerplate

Yeah, still have to explicitly name all the keys though. Nevermind, it's a bit tedious, but at least it's simple.

Hmm, I wonder if you could generate simple subscriptions of this sort from a spec.

so when I'm having an event handler that looks like (fn handler [fx _] (-> (assoc-in fx [:db :foo] :bar) (assoc :dispatch [:not-important]))) I'm getting "no handler registered for effect event"

i thought writing the handlers like them would make them more flexible, but it seems that it's not intended

because fx has information about the current event and just passing it on causes the above error

so is this an anti-pattern?

it seems kind of clunky to explicitly (dissoc fx :event) first

Interesting pattern to pass on the fx with some changes @arne-clojurians. I've generally been destructuring in the arg vector for just the db and returning a map literal. (fn handler [{db :db} _] {:db (-> db (assoc ... But your approach might be useful in certain situtations: is there more than just the db you'd like to pass through?

i have to say i did not actually end up using it yet. it was something i thought of when i started familiarizing myself with re-frame