Problem
Previews of MVUX-based pages need to show the loading / error / empty / value states of a FeedView without constructing the real model. Mocking the model to get a feed into a given state means mocking every injected service too (there is no DI in previews), which does not scale.
Since FeedView state switching is implemented with visual states, we can bypass the feed entirely and force the visual state from outside.
Proposal
An attached property, settable at the page (or any ancestor) level, that walks down the visual tree, finds the FeedView(s) below it, and forces their visual state.
Two forms:
- Short form — a dedicated helper that assumes the target is
FeedView and applies to all FeedViews found in the subtree. This is the form we expect people to use most of the time, and the one Hot Design can offer as a simple state dropdown in the property grid, reusing the existing VisualStateManager extensions picker.
- Long form — the general-purpose version: a
States markup extension taking a state value plus a target type, e.g. state Loading, type FeedView. Conceptually the mirror of AncestorBinding — walking down to descendants instead of up to ancestors. The short form is just a facade over this.
Scope of this issue (validation first)
This is a hypothesis validation, not an implementation ask. Before building anything:
- Confirm the syntax above is workable as a custom markup extension — specifically that a descendant-walking markup extension can resolve its targets at the right point in the XAML/loading lifecycle.
- Identify which visual state groups on
FeedView need to be driven, and confirm they can be forced externally via VisualStateManager.GoToState while a source is (or is not) attached.
- Note the
FeedView template variant that uses a single composite data template — where loading/error/value are bindable overlays rather than swapped templates. Forcing a visual state may not cover that case; call out what does and does not work.
- Decide where this belongs:
AncestorBinding and VisualStateManagerExtensions live in Uno.Toolkit, but the FeedView-specific facade is arguably closer to home here. Flag the recommendation.
Report findings before starting implementation.
Why
Unblocks previews for MVUX pages. Together with #3144 (allowing FeedView.Source to bind to a constant value), this removes the need to mock models, services, and feeds just to render a preview.
Problem
Previews of MVUX-based pages need to show the loading / error / empty / value states of a
FeedViewwithout constructing the real model. Mocking the model to get a feed into a given state means mocking every injected service too (there is no DI in previews), which does not scale.Since
FeedViewstate switching is implemented with visual states, we can bypass the feed entirely and force the visual state from outside.Proposal
An attached property, settable at the page (or any ancestor) level, that walks down the visual tree, finds the
FeedView(s) below it, and forces their visual state.Two forms:
FeedViewand applies to allFeedViews found in the subtree. This is the form we expect people to use most of the time, and the one Hot Design can offer as a simple state dropdown in the property grid, reusing the existing VisualStateManager extensions picker.Statesmarkup extension taking a state value plus a target type, e.g. stateLoading, typeFeedView. Conceptually the mirror ofAncestorBinding— walking down to descendants instead of up to ancestors. The short form is just a facade over this.Scope of this issue (validation first)
This is a hypothesis validation, not an implementation ask. Before building anything:
FeedViewneed to be driven, and confirm they can be forced externally viaVisualStateManager.GoToStatewhile a source is (or is not) attached.FeedViewtemplate variant that uses a single composite data template — where loading/error/value are bindable overlays rather than swapped templates. Forcing a visual state may not cover that case; call out what does and does not work.AncestorBindingandVisualStateManagerExtensionslive in Uno.Toolkit, but theFeedView-specific facade is arguably closer to home here. Flag the recommendation.Report findings before starting implementation.
Why
Unblocks previews for MVUX pages. Together with #3144 (allowing
FeedView.Sourceto bind to a constant value), this removes the need to mock models, services, and feeds just to render a preview.