Yes, there will be a problem, since the db is sent between the app and F. Inspect as transit, I believe. I would just use an atom.

Depends. If it isn’t serializable then the state-atom is the wrong place primarily because of dev mode tooling (like Inspect). It can also cause problems if you ever wanted to use time-travel or state storage (i.e. in LocalStorage for app resume). If you need that data to be available to the UI, AND changes to that data require a UI refresh, then you’re in a little bit of a tight spot (not intractable, just not handled for you). Inspect will technically tolerate unserializable values, as will most of the interals of Fulcro (as long as you don’t let a query traverse INTO something that isn’t a Clojure data structure)….so, you can put them in the state atom if you’re willing to deal with the other limitations. If you need the data changes tied to the rendering refresh, that is probably the easiest course. If this unserializable state is just stuff like referneces to library objects that you use in APIs, just put them wherever. They don’t affect rendering and are not in scope for Fulcro, period. What is an “expensive indexing data structure for a table” that would not be serializable??? Wouldn’t that just be clojure data?

@U0CKQ19AQ > What is an “expensive indexing data structure for a table” that would not be serializable? I guess these are fairly contrived examples, but imagine the index is a big binary blob and is used with bit operations; or a pointer-based data structure that is occasionally cyclic.