3

I'm working on a TreeView component, and I find myself writing a whole lot of code to circument a rather simple problem arising from the use of React-DnD.

Case in point: when navigating the tree view with the up and down arrow keys, the node that should be selected is not always the successor or predecessor on the same level. For example, when moving up and the same-level predecessor is open and has children, usability dictates (to me at least) that the predecessor's last child should be selected (or actually, the last visible descendant), since that is visually the immediate predecessor of the previously selected node.

The problem occurs when trying to determine if the predecessor's descendant (let's call it the "target" node) is open or closed. That information is being maintained in the target node's state.

And that's where the problem is: the component I created to represent the nodes is wrapped by a React-DnD DragSource. But while the wrapping mechanism of React-DnD gives transparent access to a wrapped component's properties, that is not the case for its states: DragSource exposes its own states, but does not give access to the states of the component it wraps.

Combined with the fact that the wrapper intercepts callback refs of wrapped components so as to pass its own instances instead of the wrapped ones, that means that I simply cannot access the open/closed state of my nodes, even thoughn I know exactly where they are positionally. (And actually, I did have this working perfectly before I started using React-DnD.)

How can I deal with this situation? Could this be a bug or oversight of React-DnD, or is there a way to get access to the wrapped component that I don't know of?

Note: there seems to be a method to access the wrapped component, but the doc states that that is intended for testing.

Brian Burns
  • 20,575
  • 8
  • 83
  • 77
JPNotADragon
  • 2,050
  • 2
  • 25
  • 31
  • I have exactly the same problem with Spring fromReact-Motion. I'm trying to bind mouse event to the components wrapped in Spring. In most examples you get to the child nodes through refs in parent so you can just bind the id with the mouse event listener function. I can think of a few workarounds for that but none of them are pretty. Did you come up with something good? – konrad Sep 28 '15 at 07:36
  • @konrad: I'm not sure you are having the same problem. From what I've seen, React-DnD's wrapping mechanism passes the events through just fine; it's only the wrapped objects themselves, and more importantly their state, that become inaccessible from the outside. – JPNotADragon Sep 28 '15 at 11:18
  • @konrad: To answer your question though, no, I haven't found a good solution to this. I get the impression that this limitation is intentional to enforce React's top-down data flow. I think React *wants* us to write that "whole lot of code" rather than take shortcuts that go against its grain. – JPNotADragon Sep 28 '15 at 11:25
  • there's no problem with passing events per se, more with clean easy way of referencing the proper component with its props/methods through `refs` from (now grand-) parent when there's a middle man like Spring. The docs suggest using the round trip through a store or custom events outside of parent-child relationship. In my case I eventually used the Spring wrapper itself for my needs but I can easily imagine that you actually need get two levels down so the question remains valid. – konrad Sep 28 '15 at 14:32
  • Why isn't the open and closed state of the node a `prop`? – Kyeotic Nov 30 '15 at 18:29
  • @tyrsius: I haven't pursued my explorations of React. Your question is a valid one though, but I'm not sure I can remember the real reason right now. It seemed to me that open/closed is, purely from the meaning in English, a state rather than a property. – JPNotADragon Nov 30 '15 at 22:16
  • I think English and React might disagree here. State, as far as components are concerned, is generally *internal* information. The open/closed bit of a node is public, and should probably be a prop – Kyeotic Nov 30 '15 at 23:26

0 Answers0