Fork me on GitHub
#re-frame
<
2015-08-16
>
tel02:08:50

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

tel02:08:13

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

tel02:08:30

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

val_waeselynck08:08:51

@tel can you give an example ?

val_waeselynck11:08:41

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

val_waeselynck11:08:00

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

tel13:08:07

@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.

tel13:08:39

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

tel13:08:28

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

tel13:08:31

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

tel13:08:18

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

tel13:08:41

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

tel13:08:55

“emitting” here meaning “updating the database"

tel13:08:20

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

tel13:08:46

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

tel13:08:11

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