Fork me on GitHub
#re-frame
<
2017-10-04
>
genekim02:10:56

@anantpaatra Hahaha! Awesome! 🙂

ilevd07:10:24

Hi, I need run an event before other event, should i dispatch two events in my view? Or there is another solution?

jvuillermet07:10:03

@ilevd Are you familiar with reg-event-fx and the dispatch effect handler here ? https://github.com/Day8/re-frame/blob/master/docs/API.md#built-in-effect-handlers

jvuillermet07:10:16

Also what kind of event are you trying to run before the other ?

ilevd07:10:03

I read docs twice, but it's too big to remember) Yes, I heard about reg-event-fx. Not sure that dispatch event handler will be useful. I have 3 different events (3 buttons), and I need dispatch the event to modify db before each of 3 events run, as I understand dispatch effect handler run after. Maybe the best solution will be to simply add 1 function and run it in these event handlers

ilevd07:10:48

Oh, dispatch-sync looks good for that, but not recommended

jvuillermet10:10:18

you could have an interceptor I think

jvuillermet10:10:28

so you could write

(reg-event-db 
        :button3 
        [before-buttons]
        (fn [db v]
             ....

ilevd04:10:53

An interceptor can be useful, thanks!

karlstefan10:10:37

Is it bad to have nested subscriptions?

curlyfry11:10:58

@karlstefan Do you have an example of what you mean?

mikethompson12:10:24

@ilevd as a general rule I wouldn't have a view do multiple dispatches in response to a user action. The re-frame philosophy is that events are "the language of the system". They represent intent, generally user intent. When a user clicks on the UI, they don't have two intents. They have just one. And there should be an event to represent that intent. And the event handler for it, should encapsulate your app's response.

mikethompson12:10:26

So, i guess I'm saying that your event handler should be the thing to do two further dispatches ... if it were necessary.

mikethompson12:10:25

But be careful don't confuse "a dispatch" with "a function call". You may well need to call two functions when processing the event ... but do you really need two dispatches?

mikethompson12:10:46

@karlstefan I'm also a bit confused by what "nested subscriptions" means. But perhaps this will help ... https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md

isak16:10:18

by nested subscription, I'm guessing @karlstefan means a subscription which depends on another subscription. The API goes out of its way to support this, so no, it is not bad

dgr20:10:56

Is anybody else noticing that “lein new re-frame” is throwing a null pointer exception?

DROBERT4-M-M0FU:clojure drobert4$ lein new re-frame fighello
java.lang.NullPointerException: null
 at clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.new$create.invokeStatic (new.clj:81)
    leiningen.new$create.doInvoke (new.clj:57)
    clojure.lang.RestFn.invoke (RestFn.java:425)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.core$apply.invokeStatic (core.clj:650)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.new$new.invokeStatic (new.clj:204)
    leiningen.new$new.doInvoke (new.clj:134)
    clojure.lang.RestFn.invoke (RestFn.java:439)
    clojure.lang.Var.invoke (Var.java:388)
    clojure.lang.AFn.applyToHelper (AFn.java:160)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.core.main$partial_task$fn__5932.doInvoke (main.clj:272)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.core.main$apply_task.invokeStatic (main.clj:322)
    leiningen.core.main$apply_task.invoke (main.clj:308)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:328)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
    leiningen.core.main$_main$fn__5998.invoke (main.clj:401)
    leiningen.core.main$_main.invokeStatic (main.clj:394)
    leiningen.core.main$_main.doInvoke (main.clj:391)
    clojure.lang.RestFn.invoke (RestFn.java:436)
    clojure.lang.Var.invoke (Var.java:388)
    clojure.lang.AFn.applyToHelper (AFn.java:160)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.main$main_opt.invokeStatic (main.clj:314)
    clojure.main$main_opt.invoke (main.clj:310)
    clojure.main$main.invokeStatic (main.clj:421)
    clojure.main$main.doInvoke (main.clj:384)
    clojure.lang.RestFn.invoke (RestFn.java:482)
    clojure.lang.Var.invoke (Var.java:401)
    clojure.lang.AFn.applyToHelper (AFn.java:171)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.main.main (main.java:37)

lilactown23:10:04

is there a way to refresh the app-db?

lilactown23:10:51

I'm running figwheel, and changed the (def default-db ...) that is used to initialize the state of my app

lilactown23:10:15

but even dispatching [:initialize-db] is not updating to the new value

lilactown23:10:09

and actually, I notice that when I (println my-app.db/default-db) in my cljs repl it prints the old state 😕