CompositionCollectionView, a composition-driven collection view with fully customizable look and behavior

[arcadiogarcia]

While WinUI and the Community Toolkit provide a decent variety of ---View controls that can display their children using a particular layout and interaction model, all of them are relatively rigid and don't give the user full control over how the items are animated and positioned in the screen, nor provide a model for adding gestures and interactions to them (aside from forking the control).

Meanwhile, when a developer needs to animate an object along a complex path, do input-driven animations, or express motion in terms related to other ui element; expression animations and the ExpressionBuilder in the toolkit are a great tool. However, if a developer wants to position a collection of elements using expression animations and update those animations in response to changes in the model, each of them will need to write their own code to manage the animations and update them when the model changes every time or when it is a pretty generic problem. Not having to maintain personal helpers for this code would already be a win but even more importantly having a "standard" way of expressing these composition driven layouts and gestures would result in lowering the bar for reusing view code, potentially allowing developers to consume layouts and gestures developed for other projects / by other people.

This is a proposal for a new collection/layout control, tentatively named CompositionCollectionView, which instantiates, hosts, manages and destroys a collection of UI elements that match the provided Source collection (as many other ----View controls), but also allow consumers to have full control over the animatable composition properties of the visual for each element, and automatically orchestrates all the necessary expression animations to animate the elements accordingly as the Source collection is updated.

The CompositionCollectionView wouldn't have a default look or interaction model, it will require developers to provide a Layout object that declares how each element in the collection should be positioned (although I could imagine some basic, commonly-used Layouts being included in the Toolkit). The developer will only need to specify expression animations for the position, scale, rotation, transform.... of each element (where of course each element can have different values), and the control will start and stop those animations when appropriate, modify them as the source updates, and will interpolate smoothly between updates if desired. The developers will be able to swap the Layout at any time, which will reposition all the elements smoothly.

Aside from Layouts, there would also be an standard interface for registering Behaviors. Behaviors are composable pieces that supply additional functionality and are generic enough to be used across multiple layouts. While there could only be active Layout at a time, a Layout can have any numbers of behaviors registered. Behaviors could be used to host interaction trackers, global properties, per-element properties, global interactions (e.g. pull to refresh), per-item interactions (e.g. swipe accelerators on items)...

These pieces could be combined together by developers to build scenarios as simple as a scrolling list of items (with a layout that declares the item positioning and a behavior that supplies an interaction tracker), or as complex as an Entity Component System (with (where each item in the source collection is an entity, there's a behavior that manages the components for each of them, and the layout binds the relevant component attributes to expression animations).

As an example of the kind of experiences that could be built using this control, here is a demo in which the view arranges and animates cards in several layouts that would be very hard to express with the existing xaml controls (a tilted 2d board, a messy stack of cards, the player's hand, these would be expressed by a Layout), while implementing a custom drag and drop behavior with its own pointer gesture detection logic (that would be expressed using several reusable Behaviors):

https://twitter.com/arcadio_g_s/status/1476420027863556099

[michael-hawker]

Some of this sounds like it could overlap with the CanvasView control I plan to add to Labs as well (though that's a very simple pass-through for Canvas) that's like < 100 lines. Something to compare and investigate if there's overlap towards. But that's also the whole point of Labs!

I think we're getting closer to figuring out if we've stabilized our base template, so I'll reach out soon and we can start testing out the Labs process more with you! 🦙❤