> to add a battery of named fns that can also act as layer-3 subs and refer to those in an event handler Exactly this.

Not entirely related, but my app-db is split into two parts - domain data and app's state. The latter I query with a bunch of get-in calls, usually wrapped in appropriately named functions. The former I query with a single function, because the data is normalized.

thank you

I've also found the domain/ui split useful.

Esp for domain data have been looking into datascript, datahike and the like for flat storage and datalog querying of data. So far its obvious that posh/re-posh should be avoided as the query analyzer is significantly slower than the queries themselves (e.g. see https://github.com/athensresearch/athens/pull/665). Otherwise havn't made many conclusions so far. I'm considering if async cofx/interceptor chains should be supported for datahike-like use-cases but I'm not sure thats even a sane idea yet.

I like the signal graph and would like to keep its properties (i.e. recomputation only when necessary). Having fns that grab data from deep within the app-db run a bit counter to this

have tried posh, but found it a bit too much effort