would it be consider a cardinal sin to store an object with functions inside the app-db?

It would make Mike Thompson very sad . And for good reason, I also think it's usually not a good idea

to give an example, I have a very complicated finite state machine that manages a few slices of state… with the reframe handler methodology, the only place to update the state slice is inside a handler, which leads to somehting like this:

(register-handler
  :something
  (fn [db [val]]
    (let [fsm (get-in db [:uuid :fsm])
         curr-state (get-in db [:uuid :state]) 
         next-state (trigger-fsm fsm curr-state :something val)]
      ({:state next-state :fsm fsm}))))

unless I extract the fsm from somewhere inside the db (`(:fsm db)`), I would have to re-create the machine each and every time a handler is invoked

Hmmm is that an expensive operation?

Well, it’s potentially a memory leak

the way the particular library works is you should create a fsm once, and it maintains a minimal-set of state as a separate entity, allowing you to run a whole bunch of different states through a single fsm

args -> fsm -> __state_object.. in javascript terms fsm.handle( state, “some-event”, args) returns __state__: { previousState: ‘’, handling: ‘’… }

May I ask which library is it? I'm curious now :)

but if you have a state slice and run it through a whole bunch of different instances of a machine, you end up with the state object looking something like __state__: { fsm0: {}, fsm1: {}, fsm2: {} … }

machina.js http://machina-js.org/ one of the most helpful tools i’ve ever used in ui development

this is totally a machina problem, but I was just wondering if there’s a reframe workaround

I don't know, I'd try hard to avoid putting the fsm into the app db, but then ok, you might prefer doing it this way as an optimization. The transitions in the fsm are transformations of the db?

generally speaking, yea. the idea is to ease the difficulty that comes from a complex component that can be in, say, 10 different states, and something different happens on a handler in each state.

you can make a fsm quite easily just in clojure syntax, but this is retrofitting existing js modules anyways

I recently implemented a fsm in a re-frame app... I just store the state in the db, and reconstruct the state machine every time I need it... In the end it's just a map from state to transition fn... 4 or 5 different maps are generated depending on the app state

Oh ok

in fact reframe itself has a pretty cool fsm in the source: https://github.com/Day8/re-frame/blob/master/src/re_frame/router.cljs#L89-L184