Not sure what you mean. Can you give an example?

I dunno, say you have an app db like:

{:number 0}

(reg-event-db :inc
  (fn [db _]
    (update db :number inc)))

(reg-sub :even
  ,,,)

(reg-sub :odd
  ,,,)

I think this is really a question of whether reagent is capable of this

you can use an interceptor to get state to flow into the DB rather than out

Then the subs could just listen to that new derived state

https://github.com/day8/re-frame/blob/master/src/re_frame/std_interceptors.cljc#L205-L226

I’m not sure I follow

For example, for any event handler that may change the number, add an on-changes interceptor that will write another piece of state

I’m really not chasing any particular use case for this, rather asking about the capability

there’s definitely ways to get around this by storing the evens and odds in other places

but it sounds like there’s not a way to directly do something where a change occurs and you “skip” it based on some logic

Ok. The closest concept I think of is having a dynamic graph, as explained in this talk (Incr.bind instead of Incr.map): https://www.janestreet.com/tech-talks/seven-implementations-of-incremental/

But I think re-frame/reagent only has ".map"

yeah. it’s really getting into things like rxjs and it’s many operators

great, thanks!

Have you found that you miss it? I've thought about it but haven't noticed the pain of not having it yet

I have in the past, yeah

Would

(reg-sub :even
  (fn [db _] (even? (:number db))))

I want :even to over time be: 0 2 4 6

so it will only change when :number is even

your sub will change anytime :number changes and will be true false true false ….

So when :number transitions from 0 to 1, :even will still be 0?

yes

I see. Yep, that's completely out of scope of subs.

@U08JKUHA9 that talk is wonderful

(reg-sub :seven: 

 ;; signal function 
 (fn []  (subscribe [:number])

 ;; computation function 
 (fn [number] 
   (if even? number (dec number)))

It isn't natural, but its possible.

hehe 🙂

that relies on the fact that the previous value can be trivially computed from the current

yeah, it relies on being able to compute the value you want from what's in app-db currently

I think what you want is to have a sequence of arb values

kinda arb

The more re-frame-y way would be to put that sequence in app-db itself. And to manage it via the logic of event handlers

yeah could do that. that relies on keeping some amount of old values in the app-db and managing that yourself, if you don’t want to store an arbitrarily long seq

Or just storing the current :even` and :odd

maybe

means you have to move that logic into events/effects

the way I’ve started thinking about it: what if reagent allowed transducers on reactions, similar to channels

That is the reframe way. We want events to be causal We want subs to calcualte a materialsed view

Your materialised view is a bit on the edge

is filtering not a materialized view?

filtering is

But you aren't doing filtering

Or, you are doing filtering, but you are doing it on history

Which is why it works if you store the history in app-db

I think of those as unit vs "integration", it depends on the specific goal. Testing a complete async-flow was simpler with re-frame-test, but straightforward handlers don't really need it. From a general standpoint, I prefer to unit test the content of the handlers because that's a smaller surface area.

👍