@brthrjon Ahh, you asked for slider and I read scroller. So my comment is useless, sorry.

Cheers @mikethompson, I'll look at that .

re-frame is currently on the first page of hacker news thanks to "jdnier"

upvoted 🙂

hey guys, anyone know if I could control the return value of dispatch-sync in an event? I need to use the window.onbeforeunload event handler to check if a form has unsaved data in the app-db before the user leaves my page.

The problem is that the onbeforeunload handler needs to be sync or the window will just close before I can check the app-db in a re-frame event.

did you try it?

dispatch-syn should work because it sync

what do you mean "if I could control the return value" ?

@akiroz dispatches do not have a return value AFAIK. I would just dereference a subscription after the dispatch-sync, that is totally synchronous

But while you’re at it, if you use the @(subscribe [:form-vals]) you don’t even need the dispatch-sync

@andre no, I haven't tried it yet. according to MDN, the onbeforeunload handler function is suppose to return a string....

@nilrecurring Oh cool, that should work just fine 🙂

@akiroz BIG DISCLAIMER though: dereferencing subscriptions if you’re not in a view, even if it’s the easiest way in some cases, cuts the “reactive cycle” (as you’re bypassing the view), so it’s not advised and it feels a bit hackish

I usually do that because it works just fine

But there’s an ongoing discussion on this here: https://github.com/Day8/re-frame/issues/255

yeah, I know it's a bit of a hack... but I really don't have much of a choice because of the imperative nature of this API. 😞 my other solution would be to access re-frame.db.app-db directly which seem much worse...

Naturally, I must sternly caution against this using all the gravitas I can muster. But ... I'd also note that some have used track from reagent with subscriptions

Generally they dispatch from within the track to make something happen

Or so I'm told

How is it better/worse/different from @(subscribe)?

The subscribe inside of a track and then when it fires, they dispatch something

Uhm

But akiroz’s usecase requires a synchronous lookup in app-db

So no dispatch needed. I believe the dispatch-sync was happening only to peek into the db from there.

Hi. I am still not grokking the subscription model in re-frame. When I am in a form-1 view and have a let binding at the top like this: (let [data (deref (rf/subscribe [::update-event]))] ;; return some view here, including calling sub-view with data does it make a difference whether I deref in the let binding or when calling the sub-views?

@ska other than that the type of the bound variable in the let binding will be different, no

@mccraigmccraig so the subscription will work in either situation?

@ska yes - either should be fine

So, when my view function is called (since this is form-1 it's the render fn, I take it) it will return a new vector on every call and thus break the fast equality benefit that we get from our persistent data structures. Doesn't it? Since the subscribe is just inside a defn it can not know anything about the stuff around it.

@ska yes, the fn is the render fn, and it will return a new vector on every call - but it will only get called when the data it depends on changes (i.e. when the value of the subscription changes)

@mccraigmccraig That looks like a miracle to me. The render fn only gets called when some data it uses in its function body changed. Ah, well, I guess I need to read the sources of re-frame eventually. And maybe it is just too late for today.

@ska the magic line 😄 - https://github.com/reagent-project/reagent/blob/b65afde4d7ac4864d7e355acdc16977cb92afa3c/src/reagent/ratom.cljs#L130

@ska If it helps to know, the subscribe is cached -- I had the same question (if I'm understanding your confusion) a week or so ago

is there a standard place (e.g. config.cljs) to put effect handlers (i.e (reg-fx...))?