Re-frame Effects VS Coeffects
When I first started using
re-frame, I was a bit confused about what effects and coeffects are, or, what
cofxs are. 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
reg-event-db, 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
effects and the
fxs and the
cofxs. These two types represent things that are not a part of the application state, such as:
- 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
fx. For example:
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
:fetch-data coeffect handler.
- Effects push,
- Coeffects pull,