Tree node selection handler

[humbletrader]

Hi,

is there a way to add a handler for tree node selection?

thanks.

[jakezatecky]

Hey there. Selecting a tree node always toggles the check state, so the onCheck handler is always called in that instance. Is this different than your needs?

[humbletrader]

well, I need to treat differently the "check" event and the "node select" event.
Is there a way to make that distinction ? ..... maybe inside the onCheck I can test that ... or maybe you can introduce a new event ? ..

[jakezatecky]

As it currently stands, there is no distinction between selecting a node and toggling its check state. Any selection of the node (with the exception of the expand icon) selects the label, which triggers the check event. This uses the underlying HTML association between <label>s and <input>s:

<label>
  <!-- Hidden checkbox input -->
  <input value="on" type="checkbox">
  <!-- Checkbox icon -->
  <span class="rct-checkbox">
    <i class="rct-icon rct-icon-check"></i>
  </span>
  <!-- Node icon (e.g. file or folder) -->
  <span class="rct-node-icon">
    <i class="rct-icon rct-icon-parent-close"></i>
  </span>
  <!-- Actual node text -->
  <span class="rct-title">My Node</span>
</label>

Clicking the checkbox, its icon, or its title will all propagate to the <label> element, which will in turn toggle the <input> and trigger an onChange handler, which is translated to onCheck in the React component. Having an input within a label was intentionally done to make the underling HTML tags have more semantic meaning, but it also makes it easier for users to toggle a node, as he or she can select the various icons or the name.

When you refer to tree node selection, I can only imagine you mean clicking or touching one of these HTML elements. I suppose something could be added to the library to prevent bubbling to the parent when anything but the checkbox is clicked, but that would cause some additional overhead. I could also pass an event which identifies the click target, and your onCheck handler could make a decision based on whether the title vs. the checkbox was selected.

What specific use case are you trying to solve here?

[humbletrader]

First of all, thank you for your reply.
What I want is :

1. clicking on the text to not trigger the checkbox selection.
2. a way to distinguish between a click on the label and the selection of the checkbox. My application has three different actions for onExpand(), onCheck() and onTreeNodeLabelSelect()

Thanks in advance,.

[jakezatecky]

Native support for this could be added, but it would be a bit of a hack, because we would have to go against the browser conventions in the DOM. I'll leave this open in case someone wants to create a PR.

[jakezatecky]

As a fix for your needs, I will provide an additional parameter for the event target.

[jakezatecky]

Okay, never mind. Your original request for some way to distinguish the referrer is reasonable, but after testing around, it appears that it is impossible to get the referring DOM node across all browsers while still being semantic. One thing I am very big on is trying to be as semantic and standards-compliant as possible.

The key here is we are using the onChange event on the input checkbox and because of that we lose all reference to the original DOM node that caused the event to be fired. This is how browsers handle the event. Normally we have event.target vs. event.currentTarget, but for onChange, they are both the same, and point to the element that has the onChange event attached to it (the <input /> element).

Firefox has an explicitOriginalTarget property for the event, which is exactly what we need, but nothing similar exists for any other browser. It is not a standard property either, so we cannot just use it and assume Webkit and Chakra will later add it. Therefore, we cannot easily get which element triggered this event, without making the label some type of quasi-button, which would not be very semantic.

---

As an aside, I am all for hiding checkboxes and just having an onClick event for each node (where the component is nothing more than a list of clickable nodes, rather than an actual checkbox tree), but having a delineation between a checkbox change event and a label click is not practical or best practices, as it goes against browser conventions.

If you are interested in having a checkboxless tree, then let me know and we can create a separate issue for that. Otherwise, this enhancement appears impossible to implement without breaking HTML standards.