This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (8)
- # aws (2)
- # beginners (156)
- # boot (163)
- # cider (22)
- # cljs-dev (2)
- # cljsrn (11)
- # clojars (6)
- # clojure (328)
- # clojure-austin (7)
- # clojure-dusseldorf (10)
- # clojure-italy (2)
- # clojure-russia (19)
- # clojure-spec (178)
- # clojure-uk (86)
- # clojurescript (81)
- # cursive (17)
- # datomic (33)
- # funcool (40)
- # hoplon (8)
- # jobs (5)
- # klipse (13)
- # leiningen (1)
- # luminus (21)
- # off-topic (140)
- # om (49)
- # om-next (4)
- # onyx (29)
- # planck (5)
- # protorepl (2)
- # re-frame (58)
- # reagent (2)
- # remote-jobs (4)
- # ring-swagger (16)
- # testing (1)
- # untangled (26)
- # yada (27)
I'm building an app with multiple different demos. Should they all use the same database? (a bit weird since they're "different demos", but all stuck in the same single page application)
@mattly @mikethompson I’m also in need of an elegant solution to accessing subscription values in handlers. Currently doing the hacky
@(subscribe [:key]) in the handler itself… And the alternative, to subscribe in the component calling the dispatch seems cumbersome. The component would have to update each time a subscription changes when it in reality only needs the newest value when the dispatch function is called. Also, since I’m using React Native I dispatch from a lot of places that is not in a component (Callbacks from misc HW functions).
Same here, my current way of handling derrived data requiring computation is through an interceptor. Whenever the source data is updated, my interceptor will compute the derrived data and stick it into my app-db as well.
Would be nice if there's a better way to handle getting derrived data in both events and views but I don't really have any suggestions to offer.....
interesting @akiroz can you ensure the interceptor runs before anything attempts to use the now outdated derived data?
yes, the interceptor has an
:after function that does the computation right after your event handler so it's completely synchronous.
just ensure that every event that modifies the source data has this interceptor injected, I spent almost an hour wondering why my derrived data is out of sync when I added a new event lol
don't worry, I'm pretty much a noob myself. I'm 2 months into my first serious re-frame project.
you can actually do the computation inside the event handler as well, I just used an interceptor for convenience.
it sounds like vikeri's use case could be a substantial performance improvement under specific scenarios
I think performance-wise both methods should be about the same because the computation is done whenever the source data is updated, only difference is that the derrived data is either stored in the app-db or a reactive atom.
(unrelated to above conversation) i'm reading through the re-frame documentation
Each time application state changes, a-query-fn will be called again to compute a new materialised view (a new computation over app state) and that new value will be given to any view function which is subscribed to :some-query-id. This view function, itself, will then also be called again to compute new DOM (because it depends on a query value which changed).
does this mean every fn registered via reg-sub is called anytime anything is modified inside app-db?
using the terminology of the page, ALL intermediate branches (materialized views) of the tree will be recomputed every time anything changes?
i'm assuming at least the leaves (the views) are smart enough to not re-render if their input values are the same (like in reagent)?
so then if I have a subscription f.e.
(rf/subscribe [:get-in [::some-key]]) that subscription will only change when the value at that key changes
then let's say I've got a more specific subscription that involves some degree of computation
the second function here will only get called when the values from the subscriptions in the first function change
and those functions are run only once when the inputs change, and then the resulting value passed to any views or other subscriptions that subscribe to it
the second param is returning a vector containing the result of calling rf/subscribe?
i guess the fn passed in as the third param will only be called when deref'ing the 2nd param's elements return different values?
the first function (second argument) can return either a vector of subscriptions or a subscription
i see, i think. in your example input-value in the 2nd function is the result of the subscribe'ing to :get-in in the first function?
but unlike an atom, the reactive atoms used by reagent and thus re-frame offer a mechanism to tell things when the value changes
yeah that blows my mind. i want to figure out how they're doing that, but for right now i've been accepting it as a black-box
it's part of a general pattern people think of as Functional Reactive Programming or Publish/Subscribe, based on who you talk to
there are differences in the details between those two patterns, but they share a general underlying idea that's useful to understand for this
good afternoon - I'm new to working with re-frame, but I was one of those folks whose mind was melted by the original readme and I've been looking for a place to apply it ever since. While I love the narrative docs, I've been craving some detailed reference-style docs like those discussed in issue 216 (https://github.com/Day8/re-frame/issues/216)
I was wondering about the etiquette for maybe taking a stab at that - I've read the contributing guidelines, but I'm a little gun-shy about starting work on a pull request when I'm pretty green to the project
pretty good comments in the todo-mvc source code https://github.com/Day8/re-frame/tree/develop/examples/todomvc