Re-frame Effects VS Coeffects
2019 August 13
When I first started using
re-frame, I was a bit confused about what
effects and coeffects are, or, what
They both seemed to relate to the “Side Effects” (or “Effects”) functional
programmers dislike. It was hard for me to distinguish them.
Before you read on, if you’ve never came across re-frame’s official documentation or the cljdoc page, please start there. They are fantastic resources. However, if you find yourself need some more examples or direct comparisons to help you understand them, please read on.
Two types of side effects
Out of the box,
re-frame comes with the mechanisms to update the
application state. When your application needs to cause a side effect
on the application state, you only need to write
to register your event handlers. The side effects that operate
on the application state is well-managed. There’s very little
confusion about them, so this article will not focus on those side effects.
The two types of side effects we are focusing on are the
fxs and the
cofxs. These two types
represent things that are not a part of the application state,
- Third-Party APIs
- (Other external resources that are not deterministic)
The differences are:
fxs are pushed by an event, whereas,
cofxs are pulled by an event.
- Push data to a database
- Push data to localStore/cookie
- Push data to a third party service
- Push message to
- Pull data from a database
- Pull data from localStore/cookie
- Pull data from a third party service
- Pull current datetime from browser
- Pull a random number
js/Promises that fetch data?
The solution is to think of this as a push side effect, or
dispatch [:fetch-data] -> do-fx [:promise-fetch-data] -> dispatch [:data-fetched %]
This ends up with two event handlers, one effect handler, and no coeffect handler.
I doubt this is the best way because I wish I can just have one
- Effects push,
- Coeffects pull,