This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-25
Channels
- # aleph (2)
- # aws (2)
- # beginners (37)
- # boot (23)
- # cider (29)
- # clara (34)
- # cljs-dev (2)
- # cljsrn (17)
- # clojure (230)
- # clojure-dev (47)
- # clojure-italy (11)
- # clojure-nl (2)
- # clojure-poland (5)
- # clojure-russia (52)
- # clojure-sg (1)
- # clojure-spec (70)
- # clojure-uk (73)
- # clojurescript (31)
- # core-async (9)
- # cursive (15)
- # datomic (39)
- # events (1)
- # graphql (1)
- # lein-figwheel (2)
- # luminus (13)
- # off-topic (2)
- # onyx (29)
- # other-lisps (1)
- # parinfer (15)
- # pedestal (14)
- # re-frame (41)
- # reagent (24)
- # ring (4)
- # ring-swagger (12)
- # rum (1)
- # spacemacs (3)
- # specter (1)
- # test-check (13)
- # timbre (9)
- # unrepl (29)
- # vim (5)
@rnagpal > Can someone share a reason for not supporting multiple event handlers for an event ? Simplicity mostly. re-frame tries to provide the primitive operations which can be built on further if you need it. When you get into multiple handlers, there are various tradeoffs. Should they be ordered? Can they be individually removed? What happens when figwheel reloads one of them?
Its all doable, of course, but to handle these various requirements, you have to introduce some further abstractions. And you'd never quite satisfy everyone's needs anyway.
So better for re-frame
to support the simple, primitive thing, and let people build their towers on top of that.
hi, I dont mean to make noise, but please can someone help with this ? I need to abort a http request in re-frame. how can this be done ? I came across this issue: https://github.com/Day8/re-frame-http-fx/issues/3 any ideas ?
Hey @U5CHXVC64 out of curiosity, have you tried to implement it? It looks like you could get away by storing the Xhrio in an atom {:id instance}
then calling abort
when you need
so i generally check if there's inbuilt support, if not i implement it. thanks for this direction. also, kudos to the mic api implementation!
Hey #re-frame'rs, I'm trying out the mic api by reimplementing https://codepen.io/zapplebee/pen/gbNbZE
There's a mic stream, we append an analyzer to it, it produces an FFT.
Now, I have a frequencyArray = new Uint8Array(...)
.
At each frame I'm supposed to update it with the current fft: analyser.getByteFrequencyData(frequencyArray);
I'd like to know what would be a fast way to do this. I tried the naive version: at each frame create the uint array, feed it the fft, turn it into a regular array then turn it into a cljs array. Have a view render the cljs array. It appears to be too slow (the tab hangs when I call the update in the event sub)
@lsenta have you tried profiling it? my guess is that lots of time gets lost in the js->cljs conversion
also it might be useful to try buffering some amount of frames and them convert them all at once, preferably in an async way
@nilrecurring thanks for the advice, I'll probably end up doing all of this in a webworker
I'd rather have the prototype working (not hang) before going for the batching & parallel option
According to https://github.com/Day8/re-frame/blob/master/docs/Solve-the-CPU-hog-problem.md#why-does-a-redispatch-work the browser should not hang but have a very slow framerate, could I be missing something?
There could be some other caveats, if you post some example code we can take a look
But intuitively the throughput the mic gives you is much higher than the throughput of repainting, so the browser just wants to display all of it and it’s not able to
So just dropping some frames might fix it
This method of having renders between redispatches seems trickier than I expected. This will hang:
(defn view []
[:button {:on-click (fn [e] (.preventDefault e) (dispatch [:debug/test-repeat]))}
"Test LOOP"])
(reframe/reg-event-fx
:debug/test-repeat
(fn [{db :db} _]
{:dispatch [:debug/test-repeat]
:db db}))
Does the tab freezes totally?
I'm pushing my code to create a ticket, the code is fine if I use a setTimeout #(dispatch) 20
https://github.com/Day8/re-frame/issues/382 I've linked the code to work with the mic for those interested, it's fluid
is it possible to write an fx-handler (reg-fx) that receives coeffects, instead of just the effect it's registered for?
I was trying to make an effect :api
that would submit ajax requests to the server, but would like to include a session token with the request that is stored in app-db
, or maybe someday local-storage. I have currently implemented it by putting a subscription in the handler, but it seems like coeffects would be a better way to do it
Where do people put their reg-fx
handlers? I see two options:
- (1) In a single namespace like my.project.effects
- (2) Spread across the project. There's my.project.server-http
, my.project.browser-events
, my.project.local-storage
, along with code relating to the implementation of those features
@pesterhazy I will also sometime put them in directly in my events.cljs file if that side effect is only going to be used by the events in said file.
@pesterhazy 2) seems way cleaner to me. We also use fully-qualified keywords to register the handler, which ensures that client code produces the necessary side effects of requiring the namespace, thus registering the fx (`reg-fx` is invoked in the top-level of the impl file)
thanks all. I'd tend to agree and co-locate the effects in the respective namespaces
Good point about the ns-qualified keywords
how does using qualified keywords require the namespace? I thought qualified keywords were mostly independent from the actual namespacing system
They are shader.
I took @jfntn to mean that grouping effects by namespace is useful because you know where to look. But that may not have been what he meant
@shader they do assist in requires because if in namespace foo.bar.waz
I have key ::effect
then I don’t want to type in my event handler :foo.bar.waz/effect [args]
so I end up requiring foo.bar.waz :as waz
in the event handler namespace so they can be ::waz/effect [args]