Clojurians Log v2
untangled
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
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