Fork me on GitHub

@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: 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


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


Are you aware of any way to work with the native arrays & make the tab not hang?


I'd rather have the prototype working (not hang) before going for the batching & parallel option


According to 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"])

  (fn [{db :db} _]
    {:dispatch [:debug/test-repeat]
     :db       db}))


I thought I'd get 100% CPU usage AND the browser would stay responsive


Does the tab freezes totally?


Yea, even the developper console, I have to use the chrome task manager


to kill it


I'm pushing my code to create a ticket, the code is fine if I use a setTimeout #(dispatch) 20

lsenta08:07:05 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.


otherwise I opt for (2)


@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


so is there a way to use coeffects in an fx handler?


or do I have to stick an interceptor in all of my reg-event-fx calls?


@shader they do assist in requires because if in namespace I have key ::effect then I don’t want to type in my event handler [args] so I end up requiring :as waz in the event handler namespace so they can be ::waz/effect [args]


It makes sense; I didn't realize until after the previous statement that ::alias/name expanded the alias


Yeah that's what I meant @kasuko