Standard: Add IItemProperties, IEditableCollectionView and associated types

[dotMorten]

The IItemProperties and IEditableCollectionView in System.ComponentModel namespace are really great for describing data on ICollectionViewSource to handle dynamic datasources, where you don't have a pre-defined class to encapsulate a datamodel. For instance when dealing with generic data from any database table. It also avoids the need for reflection, as the IItemProperties provides the PropertyInfo you otherwise would retrieve through reflection.

These interfaces are useful for generating UI dynamically based on dynamic data models, for use with for instance DataGrids, form entries etc. By having your data collections implement these interfaces, specific platforms can use these interfaces to generate a UI for the data.

Doc references:

• IItemProperties
• IEditableCollectionView
• ItemPropertyInfo

[weshaggard]

Moving this to corefx as I think it is more about adding them to .NET Core then to .NET Standard. Once they are in .NET Core we can consider them for a future version of the standard if necessary.

[weshaggard]

Issue moved to dotnet/corefx #29386 via ZenHub

[dotMorten]

@weshaggard It's more problematic that they aren't in UWP and Mono than .NET Core where these things are used for generating complex UI. This is all about describing your data models, which typically are written as .NET Standard assemblies.

[weshaggard]

We can track getting them added to .NET for UWP in corefx as well. We cannot really add things directly to .NET Standard they need to be in the concrete platforms first so lets work on that aspect first.

This is all about describing your data models, which typically are written as .NET Standard assemblies.

Also keep in mind that one solution may be to write a .NET Standard based library to expose these types that way they can still be used by other .NET Standard libraries but they aren't necessary part of .NET Standard itself.

[dotMorten]

Also keep in mind that one solution may be to write a .NET Standard based library to expose these types

That's not very useful for the control library ecosystem. Let's say DataGrid for a bunch of different platforms can use the same data model from a bunch of different 3rd party libraries. Sure it works on a single isolated case where you own all the packages but it doesn't work in the broader ecosystem.

[terrajobst]

You're both right. So far, we haven't spent a great deal of describing how we're going to evolve .NET Standard. That's largely because we didn't have to (.NET Standard 1.x modeled what was already there, only projected onto a linear versioning scheme as opposed to portable's multi-Venn-diagram profile while, .NET Standard 2.0 was defined as the intersection of .NET Framework and Xamarin).

But I agree with @dotMorten that we need a process that is focusing on evolving .NET Standard from here, rather than individual repos. But as @weshaggard hinted at: practically speaking it's much easier to add new APIs as NuGet packages that target the .NET Standard. We've recently done this with the compatibility pack. In this particular instance I'm not sure that this would be helpful though as presumably these types would need to be recognized by the UI frameworks. And in UWP this means code gen changes or changes to the underlying WinRT layer. Tracking them in CoreFX doesn't necessarily facilitate that.

For now, I'm OK with tracking requests for porting in CoreFX because that's where all the issues are at the moment. But I do believe we need a tracking mechanism here as well, which I'll need to propose.