The way Re-frame works, almost all of your application logic is represented with immutable tuples and maps (called "events" in Re-frame jargon). The parts that can't be represented this way, i.e. need to access the DOM, are moved to the edges of the codebase and are called "effects" and "coeffects". In practice, 80-90% of your application code can be represented as events, while the remainder becomes effects and coeffects. Your application logic is effectively a finite state machine and you can unit test all of it.
The visual part of Re-frame is handled by reagent, which is a minimalist React wrapper that represents React components as pure functions, JSX as built-in Clojure data structures literals (hiccup), and state transformations using Clojure's idiomatic atom data structure. Re-frame builds on top of this base, by enforcing that a single atom (called db) holds all of the state and providing a DSL to create cursors into parts of it.
Like most things in Clojure, Re-frame's initial setup is not a straitjacket and you can swap out the state atom with e.g. an in-memory datalog database using posh/re-posh and make the data retrieval completely declarative too.
The visual part of Re-frame is handled by reagent, which is a minimalist React wrapper that represents React components as pure functions, JSX as built-in Clojure data structures literals (hiccup), and state transformations using Clojure's idiomatic atom data structure. Re-frame builds on top of this base, by enforcing that a single atom (called db) holds all of the state and providing a DSL to create cursors into parts of it.
Like most things in Clojure, Re-frame's initial setup is not a straitjacket and you can swap out the state atom with e.g. an in-memory datalog database using posh/re-posh and make the data retrieval completely declarative too.