Clojurians Log v2

you mean function? A lambda technically means “anonymous (unnamed) function. When you add the form-config-join to your query, you already get that data denormalized into your component props. There are helper methods in the form-state namespace

There’s a dirty? predicate, if that’s what you mean

Apologies. Yes, I meant function. Also, I meant a function to normalize the dirty fields.

for what purpose

?

I don’t understand what you’re trying to do

Allow me to try again. I am attempting to send data from my form to a remote mutation which takes denormalized data. Is there a fulcro function to transform the normalized data from fs/dirty-fields? Or am I going against the grain here? Should I send the normalized data to the server mutation instead?

The point is to send the normalized diff

From there you have an exact picture of what needs to change in any abstract database:

{[:person/id 1] ; WHICH entity/row is changing
   {:person/name {:before "Bobby" :after "Bob"}}} ; the change to make

[:db/add [:person/id 1] :person/name "Bob"] ; Datomic

["UPDATE PERSON SET name = ? WHERE id = ?" "Bob" 1] ; next.jdbc

the dirty fields, being normalized, handles any form depth, and any possible change you could make to a graph. It is fully general.

So, then, what you need is a function that can translate that into database instructions on the server

For examples of those, see the RAD database adapters (there is one for Datomic, SQL, and even k-v stores).

So yes, your “remote mutation taking denormalized data” is a mismatch that IMO is a terrible idea

The JSON world does save by writing the entire thing…but in a distributed system I think this is a terrible idea. Last write wins means I edit name, and you edit age, but if we both loaded at the same time, but then save at different times one of our saves will ERASE the change of the other person, even though there was NO actual conflict. Normalized minimal diffs are a much better idea, and it blows my mind that I don’t see them used in other systems. In fact, I don’t even know of anyone else that does it (I won’t claim to be the absolute inventor, but when I saw the possibility when I was writing Fulcro it seemed a no-brainer)

But, if you really want the full denormalized props for the save, then you have them. They are the props of your current form 😄

they just are not pruned to dirty. So, in answer to your question, no, there is not a single pre-written function that will give you the form tree in a way that ONLY has the dirty fields. You either have the entire tree (dirty and not) as props, or you have a normalized minimal diff.

That said, since the form state data is co-located with every level of the props, it is a trivial algorithm to write

Makes a lot of sense now. I had a feeling I was going against the grain here. Great explanation.

sure…I think it’s kind of cool how the normalization in Fulcro led to the minimal normalized diff in save which turned out to be a great way to express arbitrary changes for a database, which makes it possible to write quite small bits of adapter code to actually accomplish arbitrary saves to any database tech.

The Datomic Cloud adapter for RAD is under 1000 lines of code. Been using it for years.

The SQL adapter is about the same length…not as well tested or generalized over all sql databases, but still kind of cool

The k-v store adapter is 857 lines