4. Re-frame specifics
• Uses single store for data-model (similar to
idiomatic redux application)
• Provides events to handle data-model
changes
• Provides subscriptions for efficient data-
model querying
5. Re-frame flow
Asynchronous actions from
“outer world” are modelled
as events changing the app
state.
Subscriptions (reactive
queries) on the app state
provide data input for React
view functions
6. Anatomy of an event
• Takes data-structure (map) of
so called co-effects
representing everything
needed at the input
• Returns data-structure (map)
of effects, which represent all
side effects (state changes)
caused by the event
7. Anatomy of an event
• Events are meant to by
dispatched by asynchronous
actions (like on-click button
listener) and are put on FIFO
queue for further processing.
• Each time particular event is
being processed, fresh co-
effect map for event handler
function is created and after
effect map result is produced,
distinct effects are
“translated” (eq side effects
being performed)
8. How to screw up ?
• Obviously, one starts with
good intentions
• What about the great idea of
generic, re-usable events ?
• Seems very neat and
completely harmless in case
like example on the right
20. Final points
• Using functional language with functional framework
doesn’t automatically mean you can’t screw up hard
exactly where FP is supposed to help you (problems
with state)
• Use events as very high level vocabulary to describe
inputs to your system, don’t try to make them generic
to facilitate code re-use, functions are there for that
• Almost all of the “nice” properties of imperative code
can be achieved using functional combinators, just
don’t be afraid to use them