feat: add Appearance to FluentProgressRing

[Skintkingle]

🙋 Feature Request

The ability to configure the Appearance similar to other Fluent components.

🤔 Expected Behavior

<FluentProgressRing Appearance=Appearence />

😯 Current Behavior

<FluentProgressRing Color=GetRingColourFromButtonAndAppearenceConfigAsync() />
  
  @code {
      [Parameter]
      public Appearance? Appearance { get; set; }
      private async Task<string> GetRingColourFromButtonAndAppearenceConfigAsync()
      {
           var swatch = await GetSwatchForConfiguredAppearence();
           return $"#{((int)(swatch.R * 255)):X2}{((int)(swatch.G * 255)):X2}{((int)(swatch.B * 255)):X2}";
      }
      
      private async Task<Swatch?> GetSwatchForConfiguredAppearence()
      {
            return Appearance switch
            {
                Appearance.Neutral => neutralForegroundColour.GetValueFor(_fluentButtonRef!.Element),
                Appearance.Accent => accentForegroundColour.GetValueFor(_fluentButtonRef!.Element),
                _ => null
            };
      }
  }

💁 Possible Solution

An implementation of Appearance on the FluentProgressRing to allow per-component theming changes between the built-in colour sets. (Neutral, Accent, Lightweight, Stealth, etc)

Where this isn't available (possibly due to the wrapped framework also not supporting it). A nicer way to get a Colour HexString from a Swatch, or advice where this extension method exists already.

🔦 Context

As part of componentising some functionality, a FluentProgressRing appears on top of a FluentButton.
The FluentButton can be configured with the Appearance property to (normally dramatically) change the Colour of the button. Either to make it pop out more in contrast to other buttons, or to indicate some preference, etc. The same Appearance configuration cannot be provided to the FluentProgressRing So given contrasts between Accent and Neutral colour configurations, sometimes an Accent Background is displayed along or behind a Neutral foreground. these colours are often not complimentary. (For example, Accent background may be black instead of white, where a Neutral is white background black foreground). With these 2 combined it makes it impossible to see.

A workaround we have introduced is to inject the NeutralForegroundActive and AccentForegroundActive design tokens and read the value off of the FluentButton depending on the value of Appearance. This lead us to another issue that you can only provide a Hex colour string to FluentProgressRing and there appears to be no "ToHexColor" or similar extension method for Swatches. If you feel this would be a useful feature request in itself (I certainly think so) then I will raise it separately. Or I'd love to be told where this extension method lives, so that I can use a similar method without having to put frameworky code in my solution.

💻 Examples

Provided in Current Behavior and Expected Behavior

[vnbaaij]

Hi,

I don't think Appearance is a correct term/way to style the ProgressRing. At tleast, that is not how the Fluent Design is using that. What would happen if you set a ProgressRing to stealth appearance? Does it only display when the mouse moves over it?

Users (both developers and end-users excpect a certain commonality in the terms used and the effects of using it produce. We feel the Color parameter offers enough customization for this specific elelment/component. And by providing that option, we are already strechtching the limits a bit

As part of componentising some functionality, a FluentProgressRing appears on top of a FluentButton.
The FluentButton can be configured with the Appearance property to (normally dramatically) change the Colour of the button. Either to make it pop out more in contrast to other buttons, or to indicate some preference, etc. The same Appearance configuration cannot be provided to the FluentProgressRing

We do that by design. The system determines the color of the ProgressRing then, just as it determimes the text color (mostly to guard contrast is sufficient)

So given contrasts between Accent and Neutral colour configurations, sometimes an Accent Background is displayed along or behind a Neutral foreground. these colours are often not complimentary. (For example, Accent background may be black instead of white, where a Neutral is white background black foreground). With these 2 combined it makes it impossible to see.

There is no notion of an Accent background in the design system. It is just a fill color. Setting accent to black would mean an Acen button would be black, the Tabs indicator would be black, a 'on' switch would be black, etc.

Turning this into a discussion item so others can chime in.

[vnbaaij]

This lead us to another issue that you can only provide a Hex colour string to FluentProgressRing and there appears to be no "ToHexColor" or similar extension method for Swatches. If you feel this would be a useful feature request in itself (I certainly think so) then I will raise it separately.

Yes, such an extension could come in handy. Please raise that separately

[Skintkingle]

I'll raise this now then, thanks. :)

[Skintkingle]

It may have been my misunderstanding about how the design system flows through the components. My experience with a Component Composition similar to this caused the FluentProgressRing to be invisible when Appearance was set to "Accent"

<FluentButton @ref=_busyFluentButton
              Id=@Id
              FormId=@FormId
              Type=@Type
              Appearance=@Appearance>
    <span class="overlaying-grid">
        @if (IsBusy)
        {
            <span>
                <FluentProgressRing Width="16px" />
            </span>
        }
        <span style="@(IsBusy ? "visibility: hidden;" : "")">@ChildContent</span>
    </span>
</FluentButton>

We do that by design. The system determines the color of the ProgressRing then, just as it determimes the text color (mostly to guard contrast is sufficient)

This lead me to believe that the ProgressRing should adopt a complimentary colour in the configured code snippet above. It in fact does not. If IsBusy is true.

With the following usage of the above component (assume it's called "BusyButton")

<BusyButton IsBusy=false>Not Busy</BusyButton>
<BusyButton IsBusy=true>Busy</BusyButton>
<BusyButton IsBusy=false Appearance="Appearance.Accent">Alt Not Busy</BusyButton>
<BusyButton IsBusy=true Appearance="Appearance.Accent">Alt Busy</BusyButton>

produces the following experience:

I would have expected "Alt Busys" FluentProgressRing to be visible. however it seems to have adopted exactly the same colour as the buttons background colour (Which I believe is derrived from the AccentBaseColor Design Token)

[vnbaaij]

We do it in the button compoennt like this:

So 'mute' the accent or neutral color and show the progress ring in accent color. This is built in functionality. It doesn't seem you implementation does anything different (but I might be wrong of course)., What is the default button not providing for you?

[Skintkingle]

I was unaware it had the capability to do this which is why we were componentising it. This is basically perfect. I will be using the built-in Loading property from now on and throwing away our custom component. Thank you for making me aware of it :)

It does seem to stop working after the first click if it's of Type ButtonType.Submit. Which didn't happen with our custom implementation. Is this possibly a bug?

[Skintkingle]

After some further investigation it seems to be when it's referenced to a form from outside of a form, for example

<EditForm id="MyForm" Model=MyModel OnValidSubmit=SubmitAsync OnInvalidSubmit=SubmitAsync>
    <FluentTextField @bind-Value=MyModel.Value Label="Some Value" />
</EditForm>
<FluentButton Id="SubmitButtonForMyForm" FormId="MyForm" Loading="IsSubmitting" Type="ButtonType.Submit">Submit</FluentButton>

@code {
    private bool IsSubmitting { get; set; } = false;

    private async Task SubmitAsync()
    {
        IsSubmitting = true;
        await Task.Delay(2000);
        IsSubmitting = false;
    }
}

Does this example seem to be correct or have I made some mistakes when using the Loading property of FluentButton

[Skintkingle]

After playing even more with it, if I provide the FluentButton with @[email protected]() (Make the component completely new on every single render, Inefficient but a workaround). The button can be clicked multiple times.

It feels like this issue, specifically this response from you on it, we are potentially dancing tantalisingly close to the same kind of bug.

[vnbaaij]

Seems like it, yes. Maybe the effect you are seeing is in fact a bug in the underlying web components