This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # aws (10)
- # beginners (76)
- # boot (53)
- # braid-chat (1)
- # cider (80)
- # cljs-edn (3)
- # clojure (65)
- # clojure-belgium (2)
- # clojure-gamedev (2)
- # clojure-nl (3)
- # clojure-poland (1)
- # clojure-russia (39)
- # clojure-uk (14)
- # clojurescript (91)
- # cursive (62)
- # datascript (1)
- # datomic (9)
- # dirac (34)
- # emacs (25)
- # error-message-catalog (8)
- # events (1)
- # hoplon (88)
- # instaparse (1)
- # jobs (2)
- # jobs-discuss (6)
- # lein-figwheel (7)
- # luminus (43)
- # mount (5)
- # off-topic (7)
- # om (28)
- # onyx (61)
- # planck (4)
- # re-frame (27)
- # reagent (3)
- # remote-jobs (2)
- # spacemacs (3)
- # untangled (136)
EVERYONE If you haven't seen this clojureWest talk, it is worth a look: https://www.youtube.com/watch?v=aI0zVzzoK_E
I've probably drunk too much FRP koolaid in the past, but something that would be kind of nice: my component requires two subscriptions, and therefore (if I understand correctly) will re-render if either of them changes. However, I mainly care about one of those subscriptions: I definitely want to re-render if this VIP subscription changes (in which case, might as well grab the second non-VIP subscription), but if only the second non-VIP subscription changes, don't bother re-rendering. Can I express this with re-frame currently?
Instead of doing
(deref r) for the less important ratom, you could use
(swap! r identity) ... an expression which yields the value in the ratom without derefing it, in such a way that the component does not capture it as an "Input Signal".
But if you ever use this technique you have to let out a maniacal, evil laugh. That's the rule.
You could also do this
(_peek-at r) instead of
(deref r). This one only requires a sinister guffaw.
@fasiha: could you please explain your use case? Just interested. Is it for performance gain?
@fasiha: you can capture the state of second subscription on change of first, just write some middleware for handler that updates data for first subscription.
whats the best way to perform something based on the success/failure of a dispatch? i.e redirect after a successful ajax request in a dispatch (from the dispatch caller).
_peek-at is a Reagent thing, not a re-frame thing, it seems like it does the same thing as the evil laugh route with
swap! but merits only a sinister guffaw because it at least is somewhat obvious what you're doing?
@nidu, not sure if this will make sense but: subscription 1 is other players' position, subscription 2 is my own position. I calculate the distance between my own position and each of the other players (requires sqrt and pow and expensive math) to sort a list of player positions closest-to-farthest. My own position changes very slowly relative to other players, so I'd prefer to calculate this expensive list of distances only if another player's position changes. Hmm, that's interesting, for the ultimate in performance savings, I should recalculate the distance only to the player that's changed, not all of them. The way it works now is one or two players' positions will be updated by a handler at a time, so the view will actually be recomputing the same distances over and over again, of players who haven't moved… 😖
(Also my conscience requires me to say: I'm not writing a game, I'm writing a serious app for airplane pilots 😋)
What I think I will do is move the distance-to-self calculation into the handler that updates other players' positions and circumvent this whole problem. A bit of complection never hurt anyone right? Right??
@afhammad: I put the complete call to the re-frame dispatch handler in the AJAX request:
(xhr/send (str "/path/" id) #(r/dispatch [:received-data (-> % .-target .getResponseText)]))
(require '[goog.net.XhrIo :as xhr] '[re-frame.core :as r]).) The
:received-data handler will deal with success/error.
@rasom, after describing it above, I realized that even with that kind of data-capturing re-frame middleware, I'll still be repeating (potentially many) computations needlessly, so I'm just going to move the expensive computation from the view to the handler that initially gets that data.
@mikethompson: I saw your note in #C0620C0C8
if I update that, and use the latest re-frame version 0.7.0, will I get React 15 in re-frame? I see your note in the Reagent github issue, looks like it will 😄
And I'm not sure how to do that https://github.com/google/material-design-lite/issues/778
Anyone ever run into something like this with their
handlers.cljs? Thousands of lines of this repeating:
at clojure.core$reduce.invoke(core.clj:6518) at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2573) at cljs.analyzer$analyze.invoke(analyzer.cljc:2588) at cljs.analyzer$analyze_file$fn__2041.invoke(analyzer.cljc:2838) at cljs.analyzer$analyze_file.invoke(analyzer.cljc:2833) at cljs.analyzer$analyze_deps.invoke(analyzer.cljc:1654) at cljs.analyzer$ns_side_effects.invoke(analyzer.cljc:2492) at cljs.analyzer$analyze_STAR_$fn__1990.invoke(analyzer.cljc:2573) at clojure.lang.PersistentVector.reduce(PersistentVector.java:333)