Clarity: Disable checkboxes in tree view

[demus]

Select one ... (check one with "x")

[ ] bug
[ ] feature request
[x ] enhancement

Expected behavior

Add the ability to disable checkboxes in tree view. Currently as far as I can tell they cannot be disabled.

[vivek203]

Do we have an update on this issue?

[ScottyTarvan]

This is really needed, please can you take a look. Thanks.

[typhoon1978]

Hi all, any update about this? I think it's something really needed !!!

[mathisscott]

@youdz ^

[youdz]

Not part of the refactor at the moment, but I believe it should be fairly straightforward to implement right after it. Since our API is now entirely based on per-node bindings, adding a [clrSelectable] input to nodes is quite easy, unless I missed some side-effect.

This could be good for @Jinnie to take soon after the new tree is merged in (any day now). 👍

[ps37]

@youdz I will be happy to make the contribution by adding a new input to the tree node.

[youdz]

That's perfect, then I suggest you check out our coding guidelines.

For a well-defined feature like this that shouldn't take many lines of code, you don't have to use a topic branch. Just write the feature as a single commit (including unit tests), and submit a PR against master. 👍 Thanks!

[ps37]

I have a doubt regarding the use case:
-Should disabling a parent node disable all of its child nodes?

-if so, if we disable a parent node and dynamically enable it again, should all the child nodes be enabled again without honoring the disabled input set on a child node?

For example, if dynamicBoolean is set to false initially and then later set to true, should the child node A-2 node get enabled or be disabled?

<clr-tree-node [clrSelectable]="dynamicBoolean">
    A
    <clr-tree-node>
      A-1
    </clr-tree-node>
    <clr-tree-node [clrSelectable]="false">
      A-2
      <clr-tree-node>
        A-2.1
      </clr-tree-node>
    </clr-tree-node>
  </clr-tree-node>

[vivek203]

If a parent is disabled, all its children should be disabled too.
If all the children of a parent are disabled, the parent should be disabled as well.

In the case of dynamically changing parent/children, the local condition should be given higher priority than the parent policy.

In the above case, if the dynamicBoolean is false, the parent and all its children are disabled regardless of the clrSelectable of the children.
if the dynamicBoolean is true, all the children are enabled but the ones with clrSelectable as false should be disabled.

So a child is enabled if both the parent and the child itself are enabled(or empty by default).
A child is disabled if either the parent or the child itself is disabled.

[ps37]

@youdz I think the input for this task should be [clrDisableSelection] instead of [clrSelectable].

Because... for example, a tree node can be set to the selected state initially using the [clrSelected] input. However, the un-selection of the node can be disabled.

Using [clrSelectable] as the input name for disabling the selection is a bit confusing in this case because it is selectable but the un-selection is disabled. This is also the opinion of a few other people I asked around at my workplace.

Please refer to the GIF below. Please notice how the un-selection on disabled tree nodes disabled until they are enabled again.

[youdz]

I'm going to try to answer some of your questions.

Should disabling a parent node disable all of its child nodes?

In eager trees, yes. In lazy-loaded trees, no.

If so, if we disable a parent node and dynamically enable it again, should all the child nodes be enabled again without honoring the disabled input set on a child node?

Let's address each case individually:

• Parent disabled + child disabled: no problem
• Parent enabled + child enabled: no problem
• Parent enabled + child disabled: the parent is enabled and the child disabled. If the child was disabled only because the parent was, and not because of an input received, then the child should become enabled again. If the child does have a disabled input, then it stays disabled.
• Parent disabled + child enabled: this is the actual problematic case, because it's inconsistent. In this case I would respect all the inputs I receive, even if they lead to silly behaviors (a disabled parent that can still be modified by changing its child). We can't do better if the app gives us inconsistent constraints.

In the case of dynamically changing parent/children, the local condition should be given higher priority than the parent policy.

See my note above about parent disabled + child enabled, I agree with this but it can give inconsistent states.

[youdz]

I think the input for this task should be [clrDisableSelection] instead of [clrSelectable].

I think [clrDisabled] is the right name. I agree that "Selectable" isn't good if a node is disabled but already selected.

[gnomeontherun]

I'm going to close this as stale. We haven't been able to invest time into the feature to figure out how to solve the statefulness issues. This is likely something we can support through the Core implementation and that is where new features will be going from here on out. We appreciate the contribution effort and look forward to supporting this through our web component implementation.

[github-actions[bot]]

Hi there 👋, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.