Fork me on GitHub
#untangled
<
2016-10-12
>
ethangracer13:10:41

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

anmonteiro13:10:42

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

ethangracer13:10:43

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

anmonteiro13:10:16

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

currentoor15:10:39

@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.

anmonteiro16:10:54

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

anmonteiro16:10:26

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

currentoor16:10:42

oh I see what you mean, thanks

tony.kay16:10:37

0.5.8-SNAPSHOT of U.client updated on Clojars

tony.kay16:10:50

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

mitchelkuijpers18:10:09

Damn you are fast @tony.kay thnx

jasonjckn21:10:22

@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

jasonjckn21:10:44

possible bug?

jasonjckn21:10:51

should I try to reproduce this myself first?

jasonjckn21:10:02

should I file an issue

ethangracer21:10:56

@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.

ethangracer21:10:31

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

ethangracer21:10:36

om transactions are not atomic, to my knowledge

jasonjckn21:10:12

okay, I thought toni said this worked a while back

jasonjckn21:10:20

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

ethangracer21:10:50

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

jasonjckn21:10:58

it kind of complicates things

jasonjckn21:10:10

but I can write onsuccess in client logic

jasonjckn21:10:23

e.g. check if object was loaded or not

ethangracer21:10:31

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

jasonjckn21:10:39

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

jasonjckn21:10:11

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

jasonjckn21:10:18

but mutations don't have return results

jasonjckn21:10:28

except via tempids

ethangracer21:10:04

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

jasonjckn21:10:08

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

ethangracer21:10:31

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

jasonjckn21:10:57

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

jasonjckn21:10:05

switching tabs is strictly client-side

jasonjckn21:10:22

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

therabidbanana21:10:43

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?

jasonjckn21:10:08

the use case is show error, or switch tab

jasonjckn21:10:19

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

jasonjckn21:10:04

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

jasonjckn21:10:20

what happens to om/tempids if the mutation fails?

jasonjckn21:10:23

do they just stick around?

mitchelkuijpers21:10:48

I think tempid’s just stick around

mitchelkuijpers21:10:59

Pretty sure actually

ethangracer22:10:15

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