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

so I don't have access to the 'this' anymore

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

ohh, right. I missed the load field action bit

why not just run a follow on mutation/read

that comes from computed

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

https://github.com/untangled-web/untangled-cookbook/tree/master/recipes/error-handling

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.

sure, if you can reproduce it feel free to submit an issue

@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

https://github.com/untangled-web/untangled-server/issues/10

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

@therabidbanana: thanks, I’ll take a look at that when I have some time

@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

oh, sorry @therabidbanana yes the expected behavior is to return a 500

@jasonjckn: yeah our team has found that to be a pain point too

Ethan, talk to me about the problem in person, perhaps I can help

@tony.kay: will do