Hi, Q: I have a mutation that triggers a server side mutation that creates a new entity, now I'd like to use that new ID to perform a navigation (using routers). I'm not quite sure what the idiomatic way is. My current approach is to use a m/with-target to put the new ident somewhere in e.g. a :ui/nav-to location in the DB and trigger a next mutation that reads this value, both performed in PESSIMISTIC transaction. Does this make sense or is there a better approach?

Note: the mutation hits a graphQL API server-side (not clojure)

@thomasmoerman that is exactly right for f2. In f3 you will also be able to use an ok-action in the mutation to do the next thing, but the idiomatic way in f2 is to use pessimistic transactions so that the 2nd mutation can read the results in state of the first. If you want to get the “early access” ok-action, you can use pessimistic transactions from incubator, which work with f2.

@eoliphant I generally try to avoid that at the UI layer, but that is the way js works. There is technically nothing wrong with it. I’m on the fence about “how far” to move the I/O away from the UI. Certainly I would avoid doing the callback mess in the UI itself, but once you’re at the mutation layer I think there are good arguments that could be made for putting your complexity there and not adding another layer. That said, if it primarily a network API that’s been wrapped for consumption, then a remote can make a lot of sense.

ok, thanks for the input @tony.kay it’s been a bit of a toss up lol, ‘in the mutation’ is simpler gets it out of the UI, but does sorta break the standard model. I’ve a couple of these I need to deal with, I think I’m going to try mutations in one, and remotes in anther for a bit to get a better feel for the tradeoffs. Strictly speaking they’re all network (Amplify, Stripe, Contentful, etc)

@eoliphant one possible interesting way to solve this in the future, would be to have one local pathom parser, delegating parts of the impl to the server (if you have one) and could integrate all those services as resolvers/mutations

today just the subpart delegation is not easy, but you could use 2 networks, one for the server, one local pathom to deal with integrations

How do I "undo" a mutation, in case that remote fails? I tryied to add a response-middleware that assocs :error :middleware-failure. It turned the remote red in inspector, but no "undo" magic 😞

Why does fulcro use macros instead of hiccup (data structures) for HTML?

https://github.com/fulcrologic/fulcro-developer-guide/blob/master/DevelopersGuide.adoc#but-does-it-have-x

that answers the “can I use hiccup syntax”, but not the “why does fulcro use macros” @tony.kay 😛

I don’t answer why questions anymore…too tired. look in chat history for the dozen or so times it has been asked

just use what you want

I’ll attempt to answer the “why” then: Fulcro delegates all rendering concerns to React itself, and only abstracts over managing data. Using a DSL like hiccup would require an “interpretation” step converting the data-structure to React createElement calls. Using macros Fulcro can generate those calls directly