This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-12
Channels
- # beginners (34)
- # boot (210)
- # cider (16)
- # cljs-dev (65)
- # cljsrn (3)
- # clojars (2)
- # clojure (107)
- # clojure-austin (8)
- # clojure-berlin (10)
- # clojure-brasil (1)
- # clojure-canada (1)
- # clojure-dev (1)
- # clojure-fr (1)
- # clojure-italy (22)
- # clojure-new-zealand (12)
- # clojure-nl (28)
- # clojure-russia (13)
- # clojure-spec (25)
- # clojure-uk (10)
- # clojurescript (109)
- # cursive (18)
- # datomic (44)
- # defnpodcast (1)
- # dirac (4)
- # emacs (2)
- # funcool (1)
- # hoplon (16)
- # jobs (14)
- # lambdaisland (23)
- # leiningen (2)
- # luminus (3)
- # off-topic (7)
- # om (58)
- # onyx (16)
- # proton (6)
- # re-frame (42)
- # reagent (55)
- # ring-swagger (5)
- # untangled (47)
- # vim (9)
@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
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
@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
I do remember a conversation recently about having some kind of on success function client-side as a post mutation
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
right, and the follow on server loads don’t work in your case?
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
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?
gotcha
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