Clojurians Log v2

@tony.kay also take a look at https://github.com/compassus/omify, still in very early stages but it works

@ethangracer if you find anything that’s not working in Omify, I’m more than happy to have a look

@anmonteiro thanks, it’s worked fine for me so far!

awesome

PRs adding docs and examples are more than welcome, I didn’t have time to get to it yet

@anmonteiro this may be a dumb question but what is the use case for omify? We've been able to use vanilla React components just fine in the render methods of our components using js/React.createElement.

@currentoor this was driven by a question from @ethangracer about adding queries and idents to plain React components without having to make wrappers

but another use case is e.g. having the correct bindings and props in a plain React component that receives an Om Next component as children

oh I see what you mean, thanks

0.5.8-SNAPSHOT of U.client updated on Clojars

fixes an initial app state bug I introduced while trying to expand devcards support

Damn you are fast @tony.kay thnx

@tony.kay someone on my team is reporting that transact! this '[(create-object) (on-success-do-something-with-object) (tx/fallback {:action 'on-failure}) when create-object throws exception server-side, on-success-do-something-with-object mutation is still transacted

possible bug?

should I try to reproduce this myself first?

should I file an issue

@jasonjckn I believe that what you’re describing is expected behavior. all transactions in a query except for tx/fallback are sent to the server and dispatched via the mutation method defined in the server-side parser.

If there is a way to specify that a certain mutation should occur on success, it’s not something we built into untangled

om transactions are not atomic, to my knowledge

okay, I thought toni said this worked a while back

but i'm not surprised if what you said is accurate

I do remember a conversation recently about having some kind of on success function client-side as a post mutation

it kind of complicates things

but I can write onsuccess in client logic

e.g. check if object was loaded or not

Hm. have you tried using the server-side parser to re-dispatch? I’m not sure that it’s advisable, but theoretically it’s possible to call (parser env [new-query]), which you could do conditionally in the server’s action thunk

considering that mutations don't have return results this definitely complicates user logic

what I would like to express is simply, create object, switch tab to new object, + error handling

but mutations don't have return results

except via tempids

right, and the follow on server loads don’t work in your case?

another would be: update object, show UI checkmark, + error handling

transact! [(do/something) (untangled/load {:query [:new-data]})]

that doesn't really lend itself to switching tabs to the new object, there's nothing to read server-side in that case

switching tabs is strictly client-side

e.g. untangled/load {:query [:current-tab]} makes no sense

When we do that, we rely on optimistically created objects and switch immediately, but I think you already mentioned you need to wait until creation is confirmed right?

right

gotcha

the use case is show error, or switch tab

not switch tab optimistically, then undo switch tab in error case

anyways it's workable for now by checking tempids in switch-tab , but awkward

what happens to om/tempids if the mutation fails?

do they just stick around?

I think tempid’s just stick around

Pretty sure actually

@jasonjckn @mitchelkuijpers yup, they don’t go anywhere unless you use a fallback to remove them