This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # aws-lambda (2)
- # beginners (48)
- # boot (231)
- # capetown (1)
- # cider (35)
- # cljs-dev (25)
- # cljsrn (74)
- # clojure (273)
- # clojure-austin (2)
- # clojure-berlin (5)
- # clojure-hk (1)
- # clojure-poland (1)
- # clojure-russia (50)
- # clojure-spec (63)
- # clojure-uk (58)
- # clojurescript (51)
- # cursive (5)
- # datomic (39)
- # defnpodcast (3)
- # dirac (13)
- # editors (6)
- # emacs (3)
- # hoplon (86)
- # jobs (2)
- # lein-figwheel (1)
- # liberator (3)
- # off-topic (10)
- # om (113)
- # onyx (34)
- # protorepl (29)
- # re-frame (2)
- # reagent (8)
- # remote-jobs (1)
- # ring (4)
- # test-check (42)
- # untangled (31)
- # yada (2)
So I wrote a mutation using load-field-action, I need to transact on this
(transact! 'this' [(my-mutation)]) for load-field-action to work its magic, now i've realized I need to transact! this mutation from a parent component
what's the canonical move to make here (1) move away from load-field-action? (2) use om next index to locate the component (3) ??
@jasonjckn: I recommend taking a look at the OmNext or Untangled tutorials about passing callbacks to child components using om/computed props.
@jasonjckn: I’m not completely understanding. If
my-mutation has a load-field-action inside of it, that means it is loading’
[:some :query] within its action thunk from the remote. is that right? why do you need to transact from the parent component? you’re in the scope of a mutation, so the only way to re-render the parent is to tack a follow-on read onto the load-field-action
I think passing down the mutation in
om/computed is a trivial way to solve this. But @ethangracer is right, you could also use follow on reads.
that’s what I’m trying to clarify — I’m not sure this is solvable with
om/computed because it has to do with remote loads
more precisely a second mutation/read (as opposed to a follow on in the first transaction).
Is it expected that an exception during a read request from the /api endpoint will swallow all exceptions and return 200 OK with no data? Seems like a bug - should at least have a non-200 status?
@therabidbanana: no, exceptions that aren’t in the untangled format should be returning 500 errors
Our logs have this in it: https://github.com/untangled-web/untangled-server/blob/master/src/untangled/server/impl/components/handler.clj#L73 but the response is 200 OK, so I guess I'll see if I can get a good test case and log a bug for it/fix it.
@ethangracer: So I have TabUnion which aggegregates my tabs, X, Y, Z UI components, the X tab aggregates SearchResults UI component, I have a my-mutation that does load-field-action on :search-items field of SearhResults UI component. so load-field-action requires that the env map has SearchResults for :component key, and [:search-results <identifier>] for :ref key. So that mutation must be transacted on SearchResults UI instance
@ethangracer: most of my transact! are done from within the render function of SearchResults so it works fine, but I also now realized I need to transact! my-mutation from the TabUnion (parent of SearchResults)
if I transact! my-mutation on this (the TabUnion instance) that won't work because :component and :ref won't be set correctly for load-field-action
so how should I solve this? one way would be to change my-mutation to load-data-action, not sure if that's the canonical way
So it does look like sometimes a 200 gets returned, at least in the setup I put in the cookbook. Is the expected behavior to return a generic 500 message?
@jasonjckn: I have a similar situation where I want to load a field in one component from another. And yes, instead of using load-field, I’m using load-data-action and providing the fully-qualified query. not sure there’s another way around it, but its not a solution I’m a huge fan of.
so I don’t think there is a more canonical way, but if you find another approach I’d be interested in hearing it
@ethangracer: the only other solution I can think of is using om index to locate the component and transact on this, or similar sort of location logic in the mutation
@ethangracer: it's also kind of annoying when you want a child to transact on it's parent too, similar story, except in that situation the parent can pass itself via computed props to the child