I feel offended by re-frame's reg-*
API. How is it functional to side effect globally?
A re-frame app is defined collectively by its handlers. As an app boots, calls to registration
functions like reg-event-db
and reg-sub
collectively "build up" an app, infusing it with behaviour and capability.
Currently, this "building up" process involves
progressive mutation of a global registrar
(map) held internally within re-frame
.
Each registration adds a new entry to this registrar
.
How should we analyse this from a functional point of view?
There's three ways to view this:
-
Egads! Say it isn't true. Mutation of a global? Summon the functional lynch mob!
-
We all understand the potential dangers of mutation, particularly of globals but re-frame's design represents a conscious decision to trade off some functional theory for simplicity of developer experience. So, yes, it represents a point in the possible design space with associated pros and cons. But the cons are theoretical and the pros are real.
-
There's no purity problem. As a Clojure program starts, each
defn
(becomes adef
which) happilyinterns
a symbol and function in a map-ish structure representing anamespace
. The lynch mob stays home for that. The pitchforks remain in their rack.re-frame
handler registration is the same pattern - anid
andhandler function
are interned within a map-ish structure (aregistrar
), once, on program load. If you hate on what re-frame does, you should also hate ondefn
. I claim your discomfort only arises because you don't understand how you are creating a virtual machine when you program re-frame
Up: FAQ Index