This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-15
Channels
- # admin-announcements (3)
- # architecture (2)
- # beginners (54)
- # boot (85)
- # braveandtrue (8)
- # cider (21)
- # cljs-dev (56)
- # cljs-site (5)
- # cljsjs (15)
- # cljsrn (9)
- # clojars (4)
- # clojure (99)
- # clojure-austin (1)
- # clojure-russia (36)
- # clojure-spec (53)
- # clojure-uk (29)
- # clojurescript (161)
- # datomic (8)
- # hoplon (3)
- # immutant (48)
- # jobs (1)
- # jobs-rus (1)
- # leiningen (10)
- # om (23)
- # om-next (1)
- # onyx (22)
- # parinfer (3)
- # planck (13)
- # protorepl (8)
- # re-frame (46)
- # reagent (2)
- # remote-jobs (1)
- # respo (1)
- # specter (5)
- # testing (12)
- # untangled (50)
- # yada (13)
@mikethompson: with the new reg-fx
effects handlers, how would one implement an effect that has no parameters or values required ? e.g. mount-root
as an effect ?
(reg-event-fx
:auth
(fn [{:keys [db]} [_ response meta]]
{:db db
:mount-root nil}))
Hmm. I didn't envisage any) effect handlers having no data. So that's a good question.
I guess nil is good enough?
Looks odd though
Are you sure you don't want to add a parameter 🙂
Indeed it does look odd 🙂
The string id of the mount element ?
😆 not a bad idea, solves the problem by providing something. Might come up again though ? Surely there are effects that have no data ?
All the ones I've created so far have had data
@mikethompson: Document.exitFullscrean()
? To be honest, I had to think pretty hard to come up with a side-effecting web api that doesn’t require some kind of data so maybe effects requiring data is a reasonable proposition.
Okay, we'll run with nil
in those cases at the moment
I'll add something to the docs. I'm currently work on them. Uggh
In 8.1 we'll have to focus on coming up with the best possible set of builtin effects
:thumbsup: sounds reasonable, thanks.
on a related note, do you think its is reasonable to make all effects fx handlers ? e.g. mount root element, start router, set route, cookies set/delete, injecting css etc.
There's a trade-off. On the one hand, you can get away with doing it the non-pure way. On the other hand, it will hurt your testing story. And your event replay story (related to debugging).
So it depends where that balance falls for you
effort vs reward
I'm was initially surprised to see mount-root-element in there. But actually that's probably quite reasonsable.
Yeah I wasn’t expecting it either until I got to the porting effort, and in code it seems to make sense.
https://github.com/Day8/re-frame/commit/af5a1898c859ba116b4b94cd7fc87f6722ea62b4
looks good :thumbsup: thanks.
what is the recommended way to publish fx handlers ? like our cookie handler ? do we just publish something on https://github.com/SMX-LTD/re-frame-cookie-fx ?
Yes, I'm thinking that we'll create a Wiki page where people can add theirs to the list of publically available effect handlers
Ok sounds good, thanks.
@mikethompson: just looking at interceptor.cljc
implementations and wondering how to write the equivalent of log-ex
from the debugging event handlers wiki page these days ? looks like an interceptor no longer calls the handler fn so cannot try/catch ?
Yeah, Interceptors don't allow for try catch.
I'll have to look at that page to remind myself
Oh that's right. That's from the bad old days when exception stacks were lost when an exception was rethrown.
So not really required any more
Your usecase?
Oh I didn’t realise it wasn’t really required anymore. My bad. Thanks! 🙂
Hi Mike, I've been playing a bit with async-flow-fx and I have a quick question. I set up a simple test case where I'd expect the :do-Y event to dispatch, but it doesn't. I only get as far as seeing the :success-X effect occur:
(reg-event
:do-Y
(fn [db]
(println "reg-event :do-Y has fired")
db))
(reg-fx
:success-X
(fn [val]
(println "reg-fx :success-X has fired")))
(reg-event-fx
:do-X
(fn [{db :db}]
(println "reg-event-fx :do-X has fired with db" db)
{:db db
:success-X nil}))
(defn boot-flow
[]
{:first-dispatch [:do-X]
:rules [{:when :seen? :events :success-X :dispatch [:do-Y]}]})
(reg-event-fx
:boot
(fn [_ _]
{:db db/default-db
:async-flow (boot-flow)}))
Any clues to my misunderstanding?success-X
needs to be an event.
async-flow is about events
You seem to have success-X
effects
So the idea is that you dispatch the do-X
event and there will then be either a success-X
event or a fail-X
event
clj
(reg-event-fx
:do-X
 (fn [{db :db}]
  (println "reg-event-fx :do-X has fired with db" db)
  {:dispatch [:success-X]}))
But on a side note, I tried implementing forward-events-fx instead, and came across a different problem. I have a function (from the re-frame template) that handles setting the active panel. I've made it effectful so that I can listen for when my app has finished loading. The idea is that if w:
(reg-event-fx
:unqueue
(fn [{db :db}]
; Finally redirect the user
db))
(reg-event-fx
:set-active-panel
(fn [{db :db} [_ active-panel panel-params]]
(if (:fetching-assets? db)
{:db (assoc db :queued {:active-panel active-panel
:panel-params panel-params})
:forward-events {:register :abc
:events #{:finished}
:dispatch-to [:unqueue]}}
{:db (assoc db :active-panel active-panel
:panel-params panel-params)})))
When I run this, re-frame throws an error for each subscription that would otherwise be updated on the view:
> core.cljs:3679 re-frame: no effects handler registered for: :active-panel . IgnoringAnyway, thanks again for the help. In the future if these basic questions come up would you prefer that I post them to stackoverflow instead?
Why is it wrong to call subscribe inside a reaction? This is stated in question 2 in the FAQ, https://github.com/Day8/re-frame/wiki/FAQ but it isn't explained.
hi guys, I’m wondering what’s the current thinking re. url routes. ATM I’m using the routes to drive navigation e.g. push a url to history and the url dispatcher calls re-frame dispatches accordingly which go do their thing. It seems to be working fine for now, but it’s not clear whether it will scale for more complex paths. Furthermore, I’m pushing the urls straight from the views i.e. not using dispatch. The only alternative I can think is to dispatch a url push event, handler then pushes url to history, url matcher dispatches more events accordingly. Any suggestions?