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 :<http://datomic.id/boo|datomic.id/boo>
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} )
is correctthen.. in api-mutate
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})])})
doesn't workbut
`
(nav-item {:title "create booking #2"
:onClick #(transact! T [(booking2/create {:id (om/tempid)})})
doesOo
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
:loading:
you could probably do a checkouts if you really want it