Fork me on GitHub

When following the developers guide, at this point: I see that we are deleting a reference by calling (swap! state merge/remove-ident* [:person/id person-id] [:list/id list-id :list/people]). I’m wondering what if I would like to remove the actual person in addition to the reference? For example if there is a person that is both in the :enemies and :friends lists. What is the idiomatic way of removing this person from the :person/id table as well as from both of the lists under :list/id?


GC is not a concern of Fulcro itself. It can be solved (using standard GC algorithms) pretty simply (see mark and sweek GC, for example), BUT since this is a distributed system and your state is meant to be treated as a database, it isn’t so simple from Fulcro’s perspective…when are you “no longer” using something? When it’s not on screen? Can the user come back to it (and a link be recreated to it?) After all, it is easy to find stuff….so dropping all references isn’t even a good enough test.


So, Fulcro’s opinion is: it’s no longer needed when your code removes it from the database.


just like Datomic, PostgreSQL, and about any other database: GC of entities is not “a thing”.


Also consider how long your app will live, and how likely it is you’ll fill up GB of space in the browser tab…it is highly unlikely, unless your downloading huge reports into the db, that you’ll realistically run things out of space.


Thank you for the answer @tony.kay It’s good to know that GC is not really a problem. I was also interested in looking at it from a graph point of view. So I would like to delete a single node and purely from looking at a graph it feels natural to remove all of its edges as well.


I think a use case would be if this user belongs to 200 lists, if it’s possible to “hard delete” it instead of going through all of the lists.


So, if you write an operation that deletes the actual table entry (node), then I agree something should probably clean up the dangling edges. That is a simple enough data transform in Clojure, but is not an included algorithm in Fulcro itself.


I would not be opposed to such an addition

👍 12