:create sends the entire containing data structure

[frankiesardo]

I don't know if this is behaviour is intended, but it looks a bit odd to me.
Every time I create a new item om-sync sends the entire list of items to the backend.
This is because the edn message to be sent is extracted from (:new-value tx-data).
Wouldn't it be more sensible to just send the new item every time? I see that we can pick it up from the second argument of the transaction tag, but I'm not 100% sure how this should work if a tag-fn is supplied.

On a side note, I discovered this issue because sending a vector instead of a map is an instant 500 from the ring-middleware and I can't understand why 🔍

[afhammad]

+1

In the line below extracted from the Intermediate tutorial, the new item new-class is being tagged along with :create however it seems to be ignored by om-sync in favour of (:new-value tx-data)

(om/transact! classes [] #(conj % new-class) [:create new-class])

am I missing something?

I was able to do an interim fix by checking if it is a :create in the tx-listen and passing the correct data.

[Peeja]

I just hit the same 500. If I'm reading the code right, it's because wrap-edn-params not only adds an :edn-params key to the request with the parsed EDN data, it also merges that data into the request's :params. If the data is a vector, that merge fails.

It's surprising to me that wrap-edn-params behaves this way (isn't passing the data on as :edn-params enough?), but it's also surprising to me that om-sync sends the whole list.

[GetContented]

I wonder if this is something to do with the way cursors work. I've noticed that when you accidentally put a cursor into a component's content, it renders the entire atom that the cursor is pointing in to.

[gardnervickers]

+1
I ran into this same problem, and ended up with the same solution as afhammad, which does not feel correct. Anyone come up with a more elegant solution?

[afhammad]

I ended up ditching om-sync as it seems to be incomplete and not very flexible. I believe David may have built it as a proof of concept and it served well as that and got me off the ground. I ended up building a similar solution based on tx-listen and borrowed from Flux's "actions" pattern (http://facebook.github.io/flux/docs/overview.html). Feel free to contact for more details.