if I have a mutation 'create-object what's the pattern for transacting 'show-object IFF 'create-object succeeds in creating the object? should I have a post-mutation for 'create-object and transact! 'show-object in the post mutation?

I take it show-object is a server query?

'show-object changes the :current-tab to show the object, and does load-field-action

put that all in create-object

create-object also hits server though, so it's on server response that tab changes

so, if the server denies something, you can throw an error that will trigger a fallback

I assume create-object might fail from server permissions?

ok (transact! [(create-object) (show-object) (tx/fallback)]) ?

tons of ways to do it. Your example is a bit vague

show-object is only transacted in non-exceptional case

no

yes create-object may fail for various reasons

well, sort of

so here's the thing. A single transaction in UI will be sent as single net transaction

so, yes, if you implement it on the server to abort at create-object, then show-object should not happen

in which case fallback may or may not be needed

I would, however, tend to use alternate logic. I would not be showing UI for making the object if it was possible for happy path to deny.

I'd show the object immediately for good user experience

and use fallback to fix things up on the (rare) unhappy path

otherwise you're waiting on the server, which is old-school thinking

hm yah, well for one thing there's server side validation of 'create-object params

so it may reject the user input, and need it to be reentered

i'm integrating with legacy system

OH

ok

yeah, that's the way to do it then

kk, thanks tony

I mean, you could validate the fields as you go (optimistically)

and not do the submit of final object till you're sure it is going to go ok

e.g. those validations could be server interactions

nods something to consider

but as we described it above should work

If there are are any more NYC area folks in here, I’d like to host a Clojure Meetup about Untangled. RSVP here! http://www.meetup.com/Clojure-NYC/events/234676309/

any examples on tempids because todomvc?

docs?

i've read some of the source

I see it's like {:http://datomic.id/foobar 32 }

then I guess that updates the table in app-state, from {:table { :http://datomic.id/foobar { ..}}} to {:table {42 { ...}}}

You should use (om/tempid) at the UI to send temp ids into your mutation

the : is part of our testing library

then return {:tempids {tmpid realid}} from your server mutation.

everything else is automatic

You should use (om/tempid)` at the UI to send temp ids into your mutation ` I don't quite follow, so

(defmethod mutation 'my/mutation [e k p]
{:remote true
:action ???} )

I'm sure todomvc does it this way...

k, looking

yes, :remote true should be sufficient assuming you don't need to modify the AST

https://github.com/untangled-web/untangled-todomvc/blob/master/src/client/untangled_todomvc/mutations.cljs#L13 there is no call to om/tempid

the local action is just to put the data in your db, as normal (including the tempid)

tempid does NOT get called in the mutation!

would cause problems

tempid is called on the UI, and passed as a param OF the mutation

So

(defmethod mutation 'create-object [e k p]
{:remote true} )

then.. in api-mutate

https://github.com/untangled-web/untangled-todomvc/blob/master/src/client/untangled_todomvc/ui.cljs#L123

remember that mutations are called more than once on the client (once for UI, and once for each remote). Tempid returns something diff every time 🙂

The only way we differ from Om Next on this is that we handle the joining together of tempids from the server for you...which you normally have to do manually.

ok so in todomvc (update-in [:todos :list/items] (fn [todos] ((fnil conj []) todos [:todo/by-id id]))) (assoc-in [:todo/by-id id] {:db/id id :item/label text}))))}) the untangled engine automatically finds all references to this 'id' in tables, and links, etc

we don't really differ so much as implement

yep, rewrite of tempids is automatic

anywhere they appear

in app state

nice

you walk the whole of app state?

all you have to do is return {:tempids {...}} from server mutation

yes, we walk the app state...just a clojure prewalk, I think

Ok right on, thanks i'll give it a shot now

In regular Om, you have to say what your ID fields are called...it is an optimization so that migrate is a bit faster. In practice, it really isn't so slow (network delay will be much longer typically)...so we opted for ease instead of premature optimization. We can always work on speeding it up later if it becomes a problem.

For example, mark-n-sweep to remove missing data from responses is optimized by walking the query. We could do similar things for migrate that would speed it up. We really haven't found the need, though.

is this right?

(defmethod api-mutation 'booking2/create
  [env key {:keys [id]}]
  {:action (fn []
             (println "id: " (pr-str id))
             {:tempids {id 42}})})

i'm having issues

is that client or server?

server

my global state gets it's om/tempid replaced with ...nothing...

curiously 'booking2/create shows up in the global app state too

not sure why the mutation symbol would be put into global app state

(defmethod m/mutation 'booking2/create [env _ {:keys [id]}]
  {:remote true
   :action (fn []
             (m/swap-this! env assoc :new-booking-id [:booking/by-id id]))})

(nav-item {:title "create booking #2"
                :onClick #(transact! T [(booking2/create {:id (om/tempid)})
                                        (app/choose-tab {:tab :booking2})])})

is 42 what you are always returning?

yes

im not seeing anything obvious thats wrong

hmmm

got it working,

oO

(nav-item {:title "create booking #2"
                :onClick #(transact! T [(booking2/create {:id (om/tempid)})
                                        (app/choose-tab {:tab :booking2})])})

but `

(nav-item {:title "create booking #2"
                :onClick #(transact! T [(booking2/create {:id (om/tempid)})})

Oo

that looks like a bug

oh, sh* , I might be nuking the state in choose-tab

i thought it would show up in the DIFF at least, but maybe it happen quickly

nuking? thats not a good idea

let me confirm that's it

confirmed

lol >.<

yah choose-tab calls initial-state on the TabComponent

i thought it was a good idea at the time

fresh tab initialized

you can also switch tabs with merely a (om/merge Root {:current-tab (initial-state MyTabComponent nil)}) which is neat

well it sounds like that was the problem

shouldnt you be switching the tab ident to point to the new tab instead?

i am

@adambros is there a snapshot release with your tools ?

i could use a mixin right now

you could probably do a checkouts if you really want it