Fork me on GitHub

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


Our logs have this in it: 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


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