This REPL test page is based on the TreeView Filtering demo, but with added checkboxes.

1. Check an item.
2. Filter the TreeView data, so that the checked item is no longer present.
3. Try to check another item.
4. The TreeView will throw a NullReferenceException.

A possible workaround is to also filter (or clear) the collection that is bound to the CheckedItems parameter of the TreeView.

We have the following scenario:

• a dialog that contains a TreeView
• the TreeView is not expanded, when the dialog is opened, only the root node is displayed
• the children are loaded on demand, when the parent node is expanded
• there is a public async Task LoadChildrenAsync() that loads the children from the source
• the loading operation might take a few seconds

The problem is when you close the dialog before the loading is finished, a NullReferenceException occurs.

System.NullReferenceException: Object reference not set to an instance of an object.
   at Telerik.Blazor.Components.Common.Trees.TelerikTreeDataSource.GetTreeItems(IEnumerable`1 data, Int32 level, String parentIndex)

I am trying to restore the expanded items by programmatically populating the ExpandedItems collection of the TreeView.

I have overriden "Equals" on the model, so the items are not compared by reference but by a unique identifier. The problem is that the TelerikTreeView does not respect this override and does not expand the items.
Other controls with similar features do respect overriden implementation of "Equals".

Reproduction: https://blazorrepl.telerik.com/cSuKkqwu46w4sHaW53.

Checking a checkbox of a on demand-loaded child then collapsing and reopening its parent makes the checkbox disappear.  However, it is still checked in the CheckedItems collection, but just not in the UI.  See this REPL example.  Steps...

1. Expand a top level item

2. Check its child checkbox

3. Collapse the top level item

4. Expand it again

Result: checkbox gone (in the UI)

Hello,

I have a TelerikTreeView with about 2000 items bound to an ObservableCollection (Data). I use SelectedItems, SelectedItemsChanged, SelectionMode multitple and @bind-ExpandedItems.

When my users manually expand the nodes of the treeview, everything is fine and the operation of the treeview works smoothly. Loading UI components based on user selection takes less than 50ms.

As soon as I set the "ExpandedItems" collection from code (according to your treeview demo), the whole treeview operation becomes painfully slow with waiting times of 2 to 4 SECONDS for selection and expansion. Already expanding from code takes several seconds.

As soon as I reset the ExpandedItems from code and collapse the complete tree, the treeview is usable again without delays.

The TreeView has CheckBoxMode="@TreeViewCheckBoxMode.Multiple" and CheckParents="true". Only some checkboxes are checked and there are parent checkboxes in indeterminate state.

When I try to clear all checked checkboxes, the indeterminate checkboxes are not cleared and maintain their state.

ADMIT EDIT:

Initially, this bug report was about unchecking all child items. However, it appears that the opposite behavior exists too - if all children are checked programmatically, the parent checkbox will show as indeterminate. In this case, check the parent explicitly as well.

If the application expands TreeView items programmatically, and then the user tries to select multiple items, an exception will occur.

The issue is a regression that occurred in version 3.0.0. A possible workaround is to Rebind() the TreeView with a small delay after programmatic item expansion.

<TelerikTreeView @ref="@TreeViewRef"
                 Data="@FlatData"
                 @bind-ExpandedItems="@ExpandedItems"
                 SelectionMode="@TreeViewSelectionMode.Multiple"
                 SelectedItems="@SelectedItems"
                 SelectedItemsChanged="@((IEnumerable<object> items) => SelectedItemsHandler(items))" />

<TelerikButton OnClick="@ExpandAll">Expand All</TelerikButton>
<TelerikButton OnClick="@CollapseAll">Collapse All</TelerikButton>

@code {
    public TelerikTreeView TreeViewRef { get; set; }
    public IEnumerable<TreeItem> FlatData { get; set; }
    public IEnumerable<object> SelectedItems { get; set; } = new List<object>();
    public IEnumerable<object> ExpandedItems { get; set; } = new List<object>();

    async Task ExpandAll()
    {
        ExpandedItems = FlatData.Where(x => x.HasChildren == true);

        await Task.Delay(1);
        TreeViewRef.Rebind();
    }

    void CollapseAll()
    {
        ExpandedItems = new List<object>();
        SelectedItems = new List<object>();
    }

    void SelectedItemsHandler(IEnumerable<object> items)
    {
        SelectedItems = items;
    }
    protected override async void OnInitialized()
    {
        FlatData = LoadFlat();
    }

    int TreeLevels { get; set; } = 3;
    int ItemsPerLevel { get; set; } = 3;
    int IdCounter { get; set; } = 1;
    List<TreeItem> LoadFlat()
    {
        List<TreeItem> items = new List<TreeItem>();
        PopulateTreeItems(items, null, 1);
        return items;
    }
    void PopulateTreeItems(List<TreeItem> items, int? parentId, int level)
    {
        for (int i = 1; i <= ItemsPerLevel; i++)
        {
            var itemId = IdCounter++;
            items.Add(new TreeItem()
            {
                Id = itemId,
                Text = $"Level {level} Item {i} Id {itemId}",
                ParentId = parentId,
                HasChildren = level < TreeLevels
            });
            if (level < TreeLevels)
            {
                PopulateTreeItems(items, itemId, level + 1);
            }
        }
    }

    public class TreeItem
    {
        public int Id { get; set; }
        public string Text { get; set; }
        public int? ParentId { get; set; }
        public bool HasChildren { get; set; }
    }
}

Hi.

I'd like to request the ability to set the Enabled property on check boxes in the treeview.

For example, given a tree view with check boxes:

<TelerikTreeView Data="@StorageItems"
                 @bind-CheckedItems="@CheckedItems"
                 CheckBoxMode="TreeViewCheckBoxMode.Multiple"
                 CheckParents="true"
                 CheckChildren="true" />

I'd like to make the tree view read-only so the check boxes appear disabled and the user cannot check-mark or uncheck-mark them.

Thank you.

Per WAI-ARIA 1.2, the "aria-level" attribute, if present, "is an integer greater than or equal to 1".

However, Blazor TreeView uses 0-indexing for the attribute which means that the root item has an invalid (and ignored) aria-level property. This is problematic because the browser will infer the level from the DOM nesting for the root item, but then use aria-level for all other sub-trees, leading to inconsistent levels (in the demo, the level goes 2 > 1 > 2).

The TreeView should automatically update when a change in data fields occur. Changes in the `ItemsField`, `HasChildren` are crucial to be tracked to allow easy manipulation of data in binding to hierarchical data. This request will fulfill the observable collection support of the TreeView.

---

ADMIN EDIT

Changes in the ExpandedField of the element have been previously handled in the TreeView. However, this has been a side effect of incorrect code in our component that was causing performance hit. We reviewed our component and how it could provide better coverage in user scenarios, so here are our steps:

- Implement tracking of data item changes with ObservableCollection, so that we could fully support binding to observable data - click the Vote and Follow buttons on the current page to raise the priority of this feature implementation and to get notified for status updates.



We've been evaluating a major change where the ExpandedItems to be controlled via parameter/state. So, we would really appreciate if you could share feedback whether this change would be good for your project and use case.

- Implementation of ExpandedItems in TreeView to substitute ExpandedField in the collection: https://feedback.telerik.com/blazor/1448095-expanded-items-handling-feedback-requested

We believe that the above steps are the way to go with the maturing of the TreeView component.

A workaround could be reinitializing the Data when you update the property of the item, that will force the treeview to update:

TreeViewData = new List<MyModel>(TreeViewData)

---

After upgrade to 3.0, when expanding a checked tree node, the child items are not checked. Also, if the child items are checked, but the parent is collapsed and expanded again, the checked children are unchecked.

This can be replicated on the online demo.

Hi everyone,

We created this item to request your feedback on how you use the treeview binding with regards to the Expanded state of the nodes.

At the moment, the treeview updates the field in the collection when an item gets expanded or collapsed, and that makes it unique in the suite - the other data bound components do not alter their data source silently, and this is the general pattern we want to follow in order to have consistency across the board.

Thus, there are several approaches we are considering and we want to get your take on how you would find this most comfortable:

• Keep the current situation where the treeview updates the ExpandedField in the Data silently [we would rather change it] - the Data collection gets changed automatically. To control an expanded item, prepare the data source accordingly.
• Use the OnExpand event to get the item and its new state in order to update the collection yourself if needed. If you don't use the field for anything but to control the state of the treeview, you will not need to change anything. To control an expanded item, prepare the data source accordingly when providing it to the treeview. If you will be reusing the same data source with alterations, you may have to handle the event to sync the state between the treeview and the data.
• Use an ExpandedItems collection [we are inclined to go with this approach at the moment] - this will be a collection that you can provide to the treeview separately from its data source, like the selected items in a grid. This will let you avoid an Expanded field in the data (which we believe may not be present in an actual database anyway) and you will be able to use business logic to determine which items to add/remove to that collection, this also includes nested levels, even added through load-on-demand.

Stack trace:

crit: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
      Unhandled exception rendering component: Unknown edit type: 0
      Error: Unknown edit type: 0
          at e.applyEdits (https://localhost:44363/_framework/blazor.webassembly.js:1:15008)
          at e.updateComponent (https://localhost:44363/_framework/blazor.webassembly.js:1:12880)
          at Object.t.renderBatch (https://localhost:44363/_framework/blazor.webassembly.js:1:1704)
          at Object.window.Blazor._internal.renderBatch (https://localhost:44363/_framework/blazor.webassembly.js:1:34784)
          at _mono_wasm_invoke_js_unmarshalled (https://localhost:44363/_framework/wasm/dotnet.3.2.0.js:1:172099)
          at wasm_invoke_iiiiii (<anonymous>:wasm-function[3160]:0x9b33d)
          at icall_trampoline_dispatch (<anonymous>:wasm-function[5777]:0xfe711)
          at mono_wasm_interp_to_native_trampoline (<anonymous>:wasm-function[4607]:0xca81d)
          at ves_pinvoke_method (<anonymous>:wasm-function[3209]:0x9cd40)
          at interp_exec_method (<anonymous>:wasm-function[1120]:0x2598d)
Microsoft.JSInterop.JSException: Unknown edit type: 0
Error: Unknown edit type: 0
    at e.applyEdits (https://localhost:44363/_framework/blazor.webassembly.js:1:15008)
    at e.updateComponent (https://localhost:44363/_framework/blazor.webassembly.js:1:12880)
    at Object.t.renderBatch (https://localhost:44363/_framework/blazor.webassembly.js:1:1704)
    at Object.window.Blazor._internal.renderBatch (https://localhost:44363/_framework/blazor.webassembly.js:1:34784)
    at _mono_wasm_invoke_js_unmarshalled (https://localhost:44363/_framework/wasm/dotnet.3.2.0.js:1:172099)
    at wasm_invoke_iiiiii (<anonymous>:wasm-function[3160]:0x9b33d)
    at icall_trampoline_dispatch (<anonymous>:wasm-function[5777]:0xfe711)
    at mono_wasm_interp_to_native_trampoline (<anonymous>:wasm-function[4607]:0xca81d)
    at ves_pinvoke_method (<anonymous>:wasm-function[3209]:0x9cd40)
    at interp_exec_method (<anonymous>:wasm-function[1120]:0x2598d)
  at Microsoft.JSInterop.WebAssembly.WebAssemblyJSRuntime.InvokeUnmarshalled[T0,T1,T2,TResult] (System.String identifier, T0 arg0, T1 arg1, T2 arg2) <0x3ae01e8 + 0x00046> in <filename unknown>:0 
  at Microsoft.JSInterop.WebAssembly.WebAssemblyJSRuntime.InvokeUnmarshalled[T0,T1,TResult] (System.String identifier, T0 arg0, T1 arg1) <0x3ae0108 + 0x00014> in <filename unknown>:0 
  at Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer.UpdateDisplayAsync (Microsoft.AspNetCore.Components.RenderTree.RenderBatch& batch) <0x3ae0010 + 0x0001e> in <filename unknown>:0 
  at Microsoft.AspNetCore.Components.RenderTree.Renderer.ProcessRenderQueue () <0x387e448 + 0x000f2> in <filename unknown>:0