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:
- Study SwiftUI Previews, Uno XAML Previews, Storybook and existing
XAML d: design-time metadata.
- Identify the smallest useful framework-neutral Preview Scenario
model.
- Prototype it in both the OpenDevelop WPF and WinUI designers.
- Determine which parts can genuinely remain independent of the
underlying XAML framework.
- 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.
Apple has supported UI preview scenarios in SwiftUI for years,
originally through
PreviewProviderand more recently with the#Previewmacro. A view can have multiple named previews representingdifferent 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:DesignWidthandd:DesignHeight. However, these are primarily design-time metadata fora 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:
Each scenario could optionally describe things such as:
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, oranother 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 naturallywithin 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:
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 practicalrather than reinvented.
Goals
The initial goal is not to define another XAML standard.
Instead, we should:
XAML
d:design-time metadata.model.
underlying XAML framework.
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.