Retrofitting a legacy SPA to use a functional architecture
Retrofitting a legacy Om
SPA to use a functional
● I’m Manuel Rivero (@trikitrok).
● I’m a member of Codesai.
● I collaborate with BCN Software
Developers BCN and
● One of my clients is
Monitor where we
develop a SPA using
Regardless of what we discover, we
understand and truly believe that
everyone did the best job they could,
given what they knew at the time,
their skills and abilities, the
resources available, and the
situation at hand.
Declarative Effects pattern
● Business logic is comprised by pure functions
● They receive coeffects and return effects
● Injecting the values coeffects track and interpreting
effects to actually perform side-effects are done by
sth else (the language run-time, a framework, etc)
● At any point in time, app state results from
reducing over all events dispatched in the app
up until that time.
● The combining function for the reduce is the
set of registered event handlers.
● We extracted from re-om the code that was
independent of any view technology.
● It might be used as the base for creating
frameworks similar to re-om for other view
technologies, like for example rum, or used
directly in Clojure projects.
● Delegates to reffectory for the event-driven
system withs effects and coeffects.
● Adds subscriptions that work with Om
Thanks to re-om we could start
carving islands of pure functional
code inside our SPA’s imperative
This introduced some sanity in our
code base and made its development
● GreenPowerMonitor for open-sourcing re-om and
● André Stylianos and Joel Sánchez, and the rest of our
colleagues at GreenPowerMonitor
● re-frame project, a really wonderful way of writing SPAs, on
which re-om is heavily inspired
● Francesc for introducing me to ClojureScript and re-frame