@serce: do you mean you have a list of [A B C], and you want to create three reactions: one to A, one to B, one to C, or you want to create three reactions that react to the whole list?

@kauko: I mean i have reaction that react to whole list (reaction to [A, B, C]) and i want to create list of reactions to each item ( [reaction to A, reaction to B, reaction to C])

Hmm, maybe you could use wrapon each item in the list, and deref that in each reaction?

Though I'm not sure how wrap works since the original list is already a reaction

(let [list-of-reactions (map-indexed (fn [index item] (reagent/wrap #(get @list index) #(swap! list assoc-in index %))))

Something like that? 😮

Looks interesting, thanks, i will look into it.

wrap returns atoms though, not reactions

So maybe that's not what you want

hi all. What are "reactions" in reagent? Sounds like an intriguing concept, can't find any docs on it anywhere... Something akin to event handlers?

You can look at it as a value derived from some other value, that will be calculated and then cached for as long as any reactive "thing" inside it's body will not change.

cached in the same atom at some other path?

Internally to a reaction.

You can think of a reaction as a ratom, that changes over time based on it's inputs (ratoms or other reactive things inside the reaction body).

Has a state mutable field, just like the ratom - https://github.com/reagent-project/reagent/blob/master/src/reagent/ratom.cljs#L337

ok, starting to make sense now... trying to imagine a use case: I could use a reaction to make a computed/derived "view" of the app-state atom - something like that?

Yeah

For example

(reaction (sort-by :date (:appointments @state))) would return you a sorted view of your data

That's re-sorted only if @state changes.

and i could use such a view as a basis for a component's state, instead of the component having to do all of the traversal/transformation of the app-state itself...

clever

Though in this case means that if you do for example (swap! state :patients conj new-patient) this will also trigger re-sorting

Since this ratom changed.

In that case you would probably want more granular reactions, like say

(def appointments (reaction (:appointments @state)))
(def sorted-appointments (reaction (sort-by :date @appointments)))

This should make the sorted-appointments re-sort only when appointments actually changed.

At least that's how I understand the behaviour is. If I'm wrong then please do correct me, don't want to spread misinformation.

@peterbak: if you take a look at re-frame it's the basic conceit behind it

There are subscriptions which create reactions

And you base your components on those subscriptions.

thanks a lot @jaen, I get it now

No problem. Hopefully I didn't get too much wrong xD

Feel free to play around with that by yourself so you can get a hang of it.

Also

i been using devcards to wrap my head around reagent.. makes for a fun learning experience

re-frame wiki has nice articles about reagent internals - https://github.com/Day8/re-frame/wiki

Basically a must read.

ok, will read

Especially the one on difference between reagent component form types.

functions-returning-hiccup vs higher-order functions vs create-class something?

anyway, reading through re-frame docs now

thanks

Yep, that.

If you have a handle on it already then it's probably less helpful

But documents the differences and gotchas really nicely.

i see

the clarity of ideas in re-frame is blowing my mind

Yeah, it is pretty great. I didn't exactly get it until I re-implemented it by myself, but when you catch on you can appreciate the thought behind it.

IMO something like re-frame but with datascript and relay-like queries as the data layer instead of a single ratom would be awesome.

...so, something like om.next but simpler

tighter integration with the server side in the form of relay-something-rather seems like a logical next step, since i bet that 95%+ of apps built with re-frame talk to some remote api and fetch some data

Yeah, something like om.next just with a reagent view.

anybody else ran into the following error with re-frame: ANALYSIS ERROR: Referred var reagent.impl.batching/do-later does not exist on file null, line null, column null looks like a jar version mismatch between reagent and re-frame?

argh, looks like figwheel cached something somewhere. Running 'lein cljsbuild once' fixed it. weird.