Microsoft-ui-xaml: Proposal: Switch from ListView to ItemsRepeater for TreeView

[chingucoding]

Proposal: Switch from ListView to ItemsRepeater for TreeView

Summary

Remove the ListView for rendering the TreeViewItems and use ItemsRepeater instead.

Rationale

Currently the Selection handling is using 2 models depending on the mode. If we would use the ItemsRepeater we could offload that logic onto the existing SelectionModel of the ItemsRepeater.

Scope

| Capability | Priority |
| :---------- | :------- |
| Use ItemsRepeater instead of ListView for rendering the TreeViewItems | Must |

Important Notes

Open Questions

[japf]

Maybe one thing to consider is that could be a breaking change for existing apps. If an app developer is digging the visual tree to fetch the ListView (for example to get a SelectionChanged event) that app would be broken after an update to WinUI that switch to ItemRepeater internally. Maybe this change could go to a new TreeView2 control, but I'm not sure this is nicer longer term.

Also as this seems a rather large development effort, do you see any other benefit other than "making the code cleaner"? That would likely help to implement a proper SelectionChanged event correct? Any other things?

[Felix-Dev]

@japf That TreeView is currently using ListView as a base is an implementation detail and shouldn't be relied on by developers as it is subject to change (just as how NavigationView switched from ListView to ItemsRepeater). If apps will break because of such a switch, then it's because developers made assumptions which they should be aware could be invalid at any point in the future and did not guard against this fact. This is not an issue for WinUI to deal with and no TreeView2 control should be introduced.

Right now, since TreeView relies on ListView for single-selection mode, any bugs in the ListView codebase "bubble up" to the TreeView as well (and might be impossible to fix in the TreeView control itself). ListView itself does have a few bugs right now when it comes to binding the ListViewItem.IsSelected property, for example. As a consequence TreeView is currently suffering from them as well.

To quote the team on why NavigationView was moved over to ItemsRepeater:

Moving to ItemsRepeater will provide us more freedom in implementing future functionality as well as resolve some issues that the control currently has due to the usage of ListView.

[japf]

It the team did this kind of change in the past and was fine with it, that's good to know. The "shouldn't be relied by developers" can be the tricky part as developers are always doing a bunch of assumptions over time :-)

[Felix-Dev]

Raymond Chen's blog is full of these cases where some folks thought themselves clever: "Let's look into the kernel and create some awesome software which unlocks a feature/behavior which is not meant to be public." Turns out the Windows kernel is changing all the time and their software broke. Is it Microsoft's responsibility to guarentee support for this software? No. Did they still do it? Yes, and as such more and more baggage was created over the time in Windows.

With WinUI, we can make breaking changes using semantic versioning and we should make use of that. If a new implementation gives benefits over the current implementation the deciding criterion to not implement it shouldn't be that some software out there relies on an implementation detail never changing. Those devs who felt they had to be "clever" and rely on non-public APIs can still use WinUI then, just not the version which will introduce these changes. If they decide to use such a WinUI version then it's up to them to fix the code relying on undocumented API/implementation details. Their already compiled software won't break as would happen in Windows and thus might force MS to artificially keep support for these software "hacks".

References:

• https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41373
• https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41363
• https://devblogs.microsoft.com/oldnewthing/20051026-44/?p=33613
• https://devblogs.microsoft.com/oldnewthing/20060109-27/?p=32723

[chingucoding]

While it is true, that we do not make any guarantees, and techincally it's the users/developers fault to assume that, i think we still should not just start making breaking changes. Changing the VisualTree is something that is a bit problematic: on the one hand, if people rely on it we introduce a breaking change for them, on the other hand in some areas we need to make some changes to fix bugs.

So we should still not just introduce changes that are unnecessary, because as @japf mentioned, some people may rely on it and we should not start breaking code without a reason.

[mdtauk]

What I think is needed, is more details about what future changes wont be possible with the current ListView base?

We believe there is an effort within Microsoft to create a WinUI/UWP version of File Explorer. This would seem to necessitate some TreeView usage. So is there anything currently in the Win32 Tree Control that isn't currently possible in TreeView, that would require a move to ItemsRepeater?

[chingucoding]

I think most features that would be planned are possible with ListView as well with ItemsRepeater. The main reason for the proposal is the fact that some features seem to be difficult to implement using ListView, but seem to be easy/easier to implement using the ItemsRepeater.

[ranjeshj]

@chigucoding Thanks for filing the proposal. Here are some pros and cons I can think of for switching TreeView to ItemsRepeater and @kaiguo can pitch in more.

Cons

1. This will likely be a breaking change especially for someone who has re-templated the control.
2. Non-trivial amount of work to refactor the control (benefits need to outweigh the cost).

Pros

1. If there is one level with a lot of nodes, currently, once you expand it, those tree nodes will be de-virtualized.
2. Simpler architecture to build on top of nested ItemsRepeaters.
   (a) We can avoid the whole flattening of the tree and dealing with collection changes.
   (b) Shared collection model and avoid the difference between single and multiple selection modes.
3. Ability to customize further.
   (a) customize animations at each level
   (b) customize layout at each level (or even at each node)
4. Build up reusable collection control components for future controls. Most of the components are likely to be reusable for data grid. also.

@anawishnoff as FYI since she is tracking the collections work.

[StephenLPeters]

@predavid for FYI, are you still the tree view PM?