re-frame 2019-07-10 | Slack Archive

metehan09:07:09

hi, i need some expert view about how to apply time changes in a reagent project. now i am making an app to track orders. orders should be delivered in 30 minutes. and in my view I am listing orders and remaining minutes. so every minute render must be updated. my idea is updating DB every order, every second, so in if there are 60 orders waiting 60 minutes 216.000 rendering operation will occur. it doesn't feel like correct approach. but is it ?

p-himik09:07:02

I would dispatch something like [:check-order-times] that updates some relevant flags in the DB for the orders taking the time into account. The event handler would find the next time when it needs to update some properties given all of the times and would :dispatch-later itself given the required delay.

p-himik09:07:44

Oh maybe I misunderstood you, given your edit. In this case, don't run N updates (N is the number of orders). Just run 1 update with N operations in it every second.

metehan09:07:28

thank you i didn't know dispatch-later exist. btw are there side effect to update the db very often?

p-himik09:07:06

Well, the subscriptions will be re-evaluated. Make sure you use layer 3 subscriptions where appropriate to not redo costly computations that don't change their value: https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md#the-layers

metehan09:07:15

thank you for your help ^^

p-himik09:07:46

No problem.

metehan09:07:50

*every second render must be updated

Daw-Ran Liou14:07:08

Hi, I have question regarding effects/coeffects. My application’s log-in flow is: 1. user submits credentials -> 2. server responds -> 3. app updates db and dispatch an effect to change the page. For step 3, I have an event handler to do this. My question is on step 1 and 2. The action seems to be both an effect and a coeffect. I’m making a effect to the server, yet the response from the server is a coeffect to my step 3. What do you suggest to implement this flow?

knubie15:07:05

I think the response from the server would be an argument to the 3.

knubie15:07:10

Have you seen https://github.com/Day8/re-frame-http-fx ?

Daw-Ran Liou15:07:06

Thanks, I just did! Now I see the :on-success and :on-failure handlers. It makes a lot of sense.

👍 4

Daw-Ran Liou15:07:49

To answer my own question, I guess it’s unnecessary to think of injecting arguments with coeffects. A chain of event-fx handlers to pass down results should be just fine.

PB16:07:26

Hey All. I have just moved from lein to deps.edn. The app is happy and working, however, re-frame 10x is no longer working. I think it's because I am not properly specifying the closure-defines and preloads inside of my dev.cljs.edn. Can anyone give guidance here?

{:dev
 {...
  :extra-deps
  {...
   day8.re-frame/tracing-stubs {:mvn/version "0.5.1"}
   day8.re-frame/re-frame-10x {:mvn/version "0.3.3"}
   }}}

;; dev.cljs.edn

{:main ...
 :extra-preloads [day8.re-frame-10x.preload]
 :extra-closure-defines {"re_frame.trace.trace_enabled_QMARK_" true
                         "day8.re_frame.tracing.trace_enabled_QMARK_" true}}

p-himik17:07:03

Maybe it's more for my own education, but what is this dev.cljs.edn file?

p-himik17:07:48

Ah, it must be Figwheel, right? I have moved to deps.edn as well, only I've also switched from Figwheel to Shadow-CLJS. Works quite good, for what it's worth.

p-himik17:07:44

Judging by https://github.com/bhauman/figwheel-main/blob/master/doc/figwheel-main-options.md all of the flags apart from :main must be entered as metadata.

PB18:07:50

It appears that specifying a lot of those as metadata breaks everything

rgm22:07:04

what happens if you say just :preloads and :closure-defines ? Otherwise it looks like it ought to work

rgm22:07:43

here’s a dev.cljs.edn for figwheel-main and re-frame-10x that works for us: https://gist.github.com/rgm/a099f297ae128f2dbd507319d3d50b60

2019-07-10

Channels