What’s the “right” way to have sequential reducer dependencies?

like when a reducer only owns a subset of the state and that state gets expanded to the whole thing

I suppose this might just be un re-frame-like design at large

@tel can you give an example ?

@shaym @antishok analogous to the difference between functions and macros IMO.

(and in this case, the functions play the role of macros )

@val_waeselynck: Sure, though it’ll be a toy example. Consider a reducer which owns a bit of state that computes the total number of clicks arriving at some element. And another reducer which is receptive to a clock event emitting ticks every second.

If the real state of interest is the average number of clicks per second then this data must be derived from the other two

so there’s a way to write a function with pseudo types like

smashReducers : (db1 db2 -> db) (db1 ev -> db1) (db2 ev -> db2) -> (db ev -> db)

it is impure, though and must store the internal states for db1 and db2 to “collect" events

only emitting when there’s an update from both… or emitting each time either updates… both forms work

“emitting” here meaning “updating the database"

sorry

anyway, this is a pretty major extension of the re-frame model here

since it heads a lot more toward making the event half of things FRP-like

but I’m just curious what people’s opinions on it might be

my day with re-frame https://github.com/Day8/re-frame/pull/107