Add a component-like (eco)sytem

[Odonno]

I know this is not how XAML developers are used to but I want to know what you think of a Component-centric system like React but oriented for XAML. Even if the two languages have differences, I think there is a lot of similitude because the two languages seems close to me.

Here are my arguments followed by examples :

1) Every UI element is a XAML component

It means a Component-centric and a Component-only system so everything is a component : a Page is a component, a UserControl is a component, any UIElement is a component. It reduces overhead because you only have one way to update the UI, it is simply by updating or adding a component.

<Page x:Name="FirstPage">
  <Grid>
     <TextBlock x:Name="HelloWorldTextBlock">My text!</TextBlock>
  </Grid>
</Page>

By default, react understand the child(ren) tree as its Content, and so do XAML. The major difference is that you can add complex properties in the tree (with XAML) where you can simply put a variable in JS (with react). Consider the following example :

<Page x:Name="FirstPage">
  <Grid>
    <Grid.RowDefinitions>
      <RowDefinition />
      <RowDefinition />
    </Grid.RowDefinitions>

     <TextBlock Grid.Row="0" x:Name="HelloWorldTextBlock">My text!</TextBlock>
     <Button Grid.Row="1" x:Name="RandomButton">Random text</Button>
  </Grid>
</Page>

This kind of complex properties are handled very differently in react but here are some suggestions so we can "attach" these properties to the correct component and not treat them as Content.

• Detect them automatically as XAMl already do with Attached Properties
• Rewrite the complex properties mechanism by removing the component name in the syntax like <.RowDefinitions>
• Put values of the properties in code-behind of the Component so it can easily managed with a script language (JS, C#)
• Any other idea?

2) A XAML component should be easily testable

Then, with a "unifed" component experience, you can write test on every component with a reduced overhead again.

• A test on a component can be language independant

Consider the following tests :

it.should("First page should contain a TextBlock", () => {
    const renderedComponent = xamlRenderer.render(new FirstPage());

    xamlParser(renderedComponent).should.contains("TextBlock", 1);
}); 

public void FirstPageShouldContainATextBlock()
{
    var renderedComponent = XamlRenderer.Render(typeof(FirstPage);

    new XamlParser(renderedComponent).AssertContains(typeof(TextBlock), 1);
}

• Also, a component can be shaped with no effort by a designer (using Blend for example) with features like live rendering and hot reloading of the source code

3) A XAML component should only store UI variables

But of course it can consume logic data. The principle is to follow the path of Purely Functional Programming but instead of having pure functions, we have pure UIs. Internal changes in a component should only change the rendering result. On the other side, every event (like a click) can trigger an action that will result in changing the data stored in the app, in a ViewModel.

4) A XAML component should be universal

We have XAML for multiple platforms (Windows 10, Android, iOS, Windows Desktop, macOS some others). So, each component can easily be designed for all platforms (like the Grid or the TextBlock) but it can also be designed per Platform if we need to extend the control based on UX guidelines or Platform limitation.

All platforms

- CustomButton.xaml

Per platform

- CustomButton.Default.xaml
  - CustomButton.Android.xaml  
  - CustomButton.iOS.xaml

5) And last but not least, a XAML component should be small and simple

[Mike-E-angelo]

Appreciate the thoughtful contribution here, @Odonno. Not sure how much of it is valid for consideration under the Standard, however. Definitely valuable to get and hear your thoughts, for sure. 👍

[lokitoth]

This seems like you are defining Templated Controls (contrasted with User Controls), no?

[birbilis]

PME model (Property-Model-Event) is related to components (here we seem to focus on only P and E [with E treated as P in practice])

also related to components is a reusable/portable binary packaging mechanism for code and assets together with metadata, where metadata is used for adding to toolboxes, selecting from component galleries, for updating (NuGet style) etc.

[Odonno]

@birbilis Yes, I mostly showed Properties but of course it will apply on Events. For the Model, I think it's a very different perspective because in this philosophy, Model should be separated from the UI.

But, the main point of this topic is a Component-centric vision. I mean, from the new emerging web Framework like react and angular, every UI element is pretty much a Component, even simple element like Button or Input can be considered as a Component. I do not say we should copy this philosophy but if everything were a Component, if we all share and talk about Component, I think we will have a better ecosystem for the reasons I explained that are :

• easy reusability (a Component can be a whole Page or just the Content part of another page or even a small part of a biger page)
• easy to code, easy to design, easy to test
• works pretty well with almost any architecture (MVC, MVVM, etc..)