Fork me on GitHub
#om
<
2017-03-16
>
urbank17:03:08

Is there a way to get the props of a component that gets passed into another component as a child?

anmonteiro17:03:02

@urbank you can probably traverse (om/children this) and try to get om/props for the child you want?

anmonteiro17:03:06

I’m unsure that will work

urbank17:03:40

Yeah, I had tried that, but they aren't components apparently (?), because I got

urbank17:03:41

Assert failed: (component? component)

anmonteiro17:03:02

but they should have .-props, right?

anmonteiro17:03:10

so you can probably hack around it

anmonteiro17:03:34

anyway, what you’re trying to do sounds like an anti-pattern

anmonteiro17:03:44

I’d love to know why you would need such a thing

urbank17:03:25

@anmonteiro Yeah, I probably am doing it wrong. 🙂 I'm trying to figure out higher-order components with om/next. So I'm trying to get the props of the child, because the higher order component is just supposed to provide some lifecycle augmentations. I'd like to get the react key of the child component as well as its style

urbank17:03:08

Specifically I'm trying to make a Draggable component

urbank17:03:51

but the components that I want to make draggable are dynamic

urbank17:03:03

but they have their own :keyfn defined in their om/factory

urbank20:03:08

Does om/computed replace what used to be passed into the function that created a react component via reify?

baptiste-from-paris20:03:14

@urbank looking at the code, it assoc :computed to props

urbank20:03:08

Hm... I see. I suppose a meta component is different than a higher order component. So Draggable is more of a meta component, and should therefore probably get the component factory of the component it's supposed to augment. A factory and props to pass to the factory. I guess that should go in computed

peeja21:03:46

@urbank Generally, a component shouldn't assign special meaning to the props of components that are passed into it, but the pattern you may be looking for is to have an additional component you use to wrap each of the children you're passing in.

peeja21:03:26

That component could accept props that affect the behavior in ways that make sense to the outer component.

peeja21:03:22

What's the correct way to use recursion with a union query? Should [{:A [{:A {:* 1, :A 1}}]}] be a valid query? The parser appears to choke on it.

peeja21:03:42

(Wacky query courtesy of test.check.)

urbank21:03:09

@peeja Right... that's kinda what I'm thinking. However, I imagine there are situations where a meta-component can't be generic if it doesn't have intimate access to the internals of the component it's augmenting

peeja21:03:20

That doesn't sound right to me. I'd posit (abstractly) that if the "meta-component" needs to know the internals of the other component, it can't be generic.

peeja21:03:39

For a Draggable component, for instance, the inner component should only know that it's drawing into a rectangle provided by its parent. The parent (the Draggable component) can then move that rectangle as the user drags it.

peeja21:03:04

It shouldn't have to know how the child works internally to do that.

urbank21:03:55

@peeja The problem I ran into is that if the Draggable component wraps the child in a div and gives the div an :onMouseDown handler to start dragging, the child component doesn't receive any events. So if the child has an input element, clicking it immediately starts dragging the component.

urbank21:03:17

hm... though I suppose that isn't really solved by accessing the childs internals...

peeja21:03:32

Yeah, that sounds like you haven't quite decided what you want the browser to do

urbank21:03:29

I suppose the meta component would have to target a specific element of the child component which would be treated as a "handle" by which it could be dragged. But I suppose that's not really something a higher order component can do, since it would require modifying the child's render function.

urbank21:03:32

This is interesting

urbank21:03:12

I think it searches the dom node of the meta component for an element with the correct class, and only drags if that element is pressed

peeja22:03:08

@urbank Yeah, that seems pretty fishy to me. Two possibilities that come to mind that feel more "correct": a) Accept any mouse event it sees as initiating a drag, and leave it up to the inner component to .stopPropagation any event it wants the Draggable component to ignore, or b) invert the control by having the owner of the inner component and the Draggable (that is, the thing that renders the two of them, one inside the other) give the inner component an event handler for the drag handle and have that handler tell the Draggable to drag.