Skip to content

Explore framework-neutral XAML Preview scenarios #6

Description

@lextm

Apple has supported UI preview scenarios in SwiftUI for years,
originally through PreviewProvider and more recently with the
#Preview macro. A view can have multiple named previews representing
different sample data, states, environments, themes, device sizes, etc.

This is particularly useful because a preview describes not just "what
this view looks like", but a reproducible scenario in which the view can
be developed and tested visually.

The XAML ecosystem has had parts of this concept for a much longer time.
WPF/UWP/Xamarin.Forms introduced design-time features such as
d:DataContext, d:DesignInstance, d:DesignData, d:DesignWidth and
d:DesignHeight. However, these are primarily design-time metadata for
a single designer view rather than a collection of reusable, named
preview scenarios.

More recently, Uno Platform introduced XAML Previews in Hot Design, with
concepts similar to SwiftUI Previews and Storybook. The Uno team has
also expressed interest in pushing toward "neutral XAML Previews" that
could potentially extend beyond Uno.

Opportunity for OpenDevelop

OpenDevelop is in an interesting position because it hosts independent
visual designers for multiple UI frameworks, including WPF and WinUI.

We can experiment with a small framework-neutral Preview Scenario
convention and see whether the same model can work across different XAML
stacks.

For example, a component might define scenarios such as:

CustomerCard
  Default
  Loading
  Empty
  Error
  LongName
  DarkTheme

Each scenario could optionally describe things such as:

Name
Sample data / DataContext
State
Theme
Width / height
Viewport/device
Required host environment

The last item is particularly important for desktop UI. Not everything
can be rendered as an isolated component. A preview might require an
actual Window, application environment, docking environment, or
another specialized host.

Keep the declaration framework-neutral

One question worth exploring is whether Preview metadata should be
represented by actual XAML objects.

For example, Uno currently uses <hd:Preview>. This works naturally
within Uno, but using framework-specific XAML types may make adoption
across WPF, WinUI, MAUI and other XAML stacks harder because their XAML
parsers and schema systems also need to understand those types.

An alternative would be an out-of-band convention understood only by the
designer, for example:

<!-- preview: Loading -->

or a sidecar file:

CustomerCard.xaml
CustomerCard.preview.*

This would allow existing XAML to remain completely valid and unchanged
from the runtime framework's perspective. Only tooling that supports the
Preview convention needs to understand the additional metadata.

Existing d: design-time features should be reused wherever practical
rather than reinvented.

Goals

The initial goal is not to define another XAML standard.

Instead, we should:

  1. Study SwiftUI Previews, Uno XAML Previews, Storybook and existing
    XAML d: design-time metadata.
  2. Identify the smallest useful framework-neutral Preview Scenario
    model.
  3. Prototype it in both the OpenDevelop WPF and WinUI designers.
  4. Determine which parts can genuinely remain independent of the
    underlying XAML framework.
  5. Compare the results with Uno's work on neutral XAML Previews and
    other XAML ecosystems.

If the same convention proves useful across multiple independent
designers and frameworks, it could eventually become a de facto
convention that other XAML tooling can adopt.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions