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.

thats awesome

forgive the newbie questions 🙂 i just started looking at reframe a couple days ago.

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

so I don't think this is the most elegant solution

what is preventing the event handler from calculating the correct derived data?

don't worry, I'm pretty much a noob myself. I'm 2 months into my first serious re-frame project.

in the land of the blind, the one-eyed man is king 😉

you can actually do the computation inside the event handler as well, I just used an interceptor for convenience.

it's a state syncronization helper.

hm

it sounds like vikeri's use case could be a substantial performance improvement under specific scenarios

if following your pattern

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.

i see. i misread vikeri's message.

(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)?

@notanon this is where signals come in

a signal is a sort of way to hook up subscriptions to other subscriptions

and then the derived subscriptions' functions only run when their inputs change

I tend to re-make in my projects a simple subscription :get-in:

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

but you can use any registered subscription as a signal

not just something that pulls values out of your app state, but other computations

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

is this a 3-arity version of reg-sub? i'm not sure i understand the code

the second param is returning a vector containing the result of calling rf/subscribe?

i must not have gotten to this part of the documentation yet, let me keep looking

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?

yeah, this is the 3-arity version

the first function (second argument) can return either a vector of subscriptions or a subscription

and then the second function receives the values from those subscriptions

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?

it appears it's being deref'd before it's passed in?

correct

think of a subscription as a wrapper around a value that can change

similar to an atom

derefing is basically the act of obtaining its current value

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

Anyway, any thoughts would be appreciated

pretty good comments in the todo-mvc source code https://github.com/Day8/re-frame/tree/develop/examples/todomvc

oh absolutely, it's not a question of being able to use the library

more like I'd like to "give back" on something that i'd have liked to see

and that docs issue seems like something i could help with, but don't want to run afoul of any etiquette (is someone else working it, will it cause too much work if i submit something that doesn't meet the intent, stuff like that)