Fork me on GitHub
#untangled
<
2016-07-27
>
jasonjckn00:07:34

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

jasonjckn00:07:52

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

jasonjckn00:07:24

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) ??

gardnervickers13:07:43

@jasonjckn: I recommend taking a look at the OmNext or Untangled tutorials about passing callbacks to child components using om/computed props.

ethangracer15:07:55

@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

mahinshaw15:07:26

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.

ethangracer15:07:40

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

mahinshaw16:07:37

ohh, right. I missed the load field action bit

mahinshaw16:07:09

why not just run a follow on mutation/read

mahinshaw16:07:16

that comes from computed

mahinshaw16:07:11

more precisely a second mutation/read (as opposed to a follow on in the first transaction).

therabidbanana16:07:53

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?

ethangracer16:07:28

@therabidbanana: no, exceptions that aren’t in the untangled format should be returning 500 errors

therabidbanana16:07:54

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.

ethangracer16:07:17

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

jasonjckn19:07:06

@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

jasonjckn19:07:53

@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)

jasonjckn19:07:28

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

jasonjckn19:07:56

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

therabidbanana20:07:03

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?

ethangracer20:07:54

@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.

ethangracer20:07:26

so I don’t think there is a more canonical way, but if you find another approach I’d be interested in hearing it

ethangracer20:07:01

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

jasonjckn20:07:01

@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

jasonjckn20:07:49

@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

ethangracer20:07:06

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

ethangracer20:07:41

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

tony.kay20:07:09

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