One thing I can think of is to use ::fs/config within the entity and dissoc it from ::fs/forms-by-ident. I think this is the way to do it but not so sure.

GC is not automatic, because there is no way for Fulcro to reliably know when something isn’t still in use. So yes, if you are wanting to be particular about such a thing, you can dissoc it yourself. See https://cljdoc.org/d/com.fulcrologic/fulcro/3.4.3/api/com.fulcrologic.fulcro.algorithms.normalized-state

it has helpers for scanning and removing things, like remove-entity

@U0CKQ19AQ Wonderful! remove-entity is exactly what I need 🙂 Thank you very much!

You mean tempids and new-uuid in RAD? Using https://github.com/yetanalytics/colossal-squuid now because of recommendations in databases.

(including Datomic…and yes I know they say you can get away without them, but they still actually recommend them for values you index and use as IDs, or that correlate with usage over time)

Interesting, but aren’t these based on a MAC address/host + timestamp + a small random value? Does that make the chance of collision rather high if same host generates a lot of UUIDs at the same time?

My understanding of their implementation is that there is a random component (upper bits are time), and a local increment counter for uuids generated on the same machine. So, changes of collision should be pretty small. It’s why I chose this lib instead of uuidv1, which generated things that look way more likely to cause collision for my comfort.

https://cljdoc.org/d/com.yetanalytics/colossal-squuid/0.1.4/doc/readme#implementation

great