Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.82%. Comparing base (28bc599) to head (0abf26d).
Report is 674 commits behind head on dev.

@@            Coverage Diff             @@
##              dev    #9923      +/-   ##
==========================================
+ Coverage   89.82%   90.82%   +0.99%     
==========================================
  Files         412      412              
  Lines       11878    12867     +989     
  Branches     2364     2487     +123     
==========================================
+ Hits        10670    11687    +1017     
+ Misses        681      618      -63     
- Partials      527      562      +35     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I wanted to point out that I did see this mentioned in the contributing guidelines: https://github.com/MudBlazor/MudBlazor/blob/dev/CONTRIBUTING.md#avoid-overwriting-parameters-in-blazor-components

Correct me if I'm wrong, but I don't think this is applicable here because it's being changed in the constructor, so it won't have an issue of re-running when re-rendering. There is also no event for InputModeChanged.

If this does need tackled in a different way though, just let me know.

You probably need to update the xmldoc

Correct me if I'm wrong, but I don't think this is applicable here because it's being changed in the constructor

Yes, it's not applicable when we talk about constructor.

Tho if we spoke about v8 I'd probably would want to have something like this:

[Parameter]
-public override InputMode InputMode { get; set; } = InputMode.numeric;
+public override InputMode? InputMode { get; set; } = null;

+private InputMode GetInputMode()
+{
+	if (InputMode.HasValue)
+	{
+		return InputMode.Value;
+	}
+
+	var numericTypes = new[]
+	{
+		typeof(sbyte), typeof(sbyte?), typeof(byte), typeof(byte?),
+		typeof(short), typeof(short?), typeof(ushort), typeof(ushort?),
+		typeof(int), typeof(int?), typeof(uint), typeof(uint?),
+		typeof(long), typeof(long?), typeof(ulong), typeof(ulong?)
+	};
+
+	var decimalTypes = new[]
+	{
+		typeof(float), typeof(float?), typeof(double), typeof(double?),
+		typeof(decimal), typeof(decimal?)
+	};
+
+	if (numericTypes.Contains(typeof(T)))
+	{
+		return MudBlazor.InputMode.numeric;
+	}
+
+	if (decimalTypes.Contains(typeof(T)))
+	{
+		return MudBlazor.InputMode.@decimal;
+	}
+
+	return MudBlazor.InputMode.numeric;
+}

It's weird to me that the MudBaseInput already has a predefined InputMode set.

Anyway, I will let @henon to decide this one. If we merge it in v7 or we keep it v8 which will be started soon.

We'll merge this in v8, just to be sure. It can be in preview.1 which we can make available end of next week or so. Then you can already use it. Is that a good compromise @Eddie-Hartman ?

@henon please don't compromise for that. I truly wasn't trying to make a mountain out of molehill or make you all go out of your way. I was just generally trying to better understand the thought process of how these types of things get fixed and playing devil's advocate since I rely so heavily on this library and felt like it is an actual bug scenario.

I'd have to review any other breaking changes in V8 as well and likely won't be rushing to upgrade right away with what may be other breaking changes (yes I'm aware of the irony).

Let me know if you need me to update anything to follow more closely what ScarletKuro suggested.

Stick to your timelines. It's a great library and I want it to stay great so keep doing what you're doing bc it's working. 🙂

I'd have to review any other breaking changes in V8 as well and likely won't be rushing to upgrade right away with what may be other breaking changes (yes I'm aware of the irony).

I plan to create a roadmap thread outlining what will be done in v8.
Based on our previous experience with v7, we aim to minimize breaking changes, it certainly won't include a billion property renames.

v8 will be a logical continuation of v7, primarily dropping .NET 7, removing obsolete APIs, and changing behaviors that make more sense (like in this PR). There will be few renames but mainly the typo ones and things that interfere (like this one #9434 (comment)). We do not plan to make fundamental changes, like replacing SVG icons with Font icons at this stage. I think this will be postponed to v9.

I hope the transition will be smoother and easier. Considering that the v7 will be deprecated and will not receive any support, even from the community.

@henon so are we merging this into v8?

Thanks!
Added to the v8 Migration guide

It looks like this change introduces an unexpected behaviour when the application language/culture uses comma as a decimal separator. When opening the application in a browser with a language that uses period as a decimal separator, the comma is not accepted by the MudNumericField.

Example 1:

• Chrome browser language: English
• Application language: Slovenian (culture: sl-SI), decimal separator is comma
• Component: <MudNumericField @bind-Value="@Value" Label="@("Test")" />
• Behaviour: I'm not able to enter 3,14.

Example 2:

• Chrome browser language: Slovenian
• Application language: Slovenian (culture: sl-SI), decimal separator is comma
• Component: <MudNumericField @bind-Value="@Value" Label="@("Test")" />
• Behaviour: I'm able to enter 3,14.

Example 3:

• Chrome browser language: English
• Application language: Slovenian (culture: sl-SI), decimal separator is comma
• Component: <MudNumericField @bind-Value="@Value" Label="@("Test")" InputMode="InputMode.text" />
• Behaviour: I'm able to enter 3,14.

So setting the InputMode="InputMode.text" solves the issue, but then it probabbly won't work on an iOS device, right (I'm not able to test it)?

@andrejpanjan Thanks for the comment.
I'm unfortunately less familiar with your situation. With this PR I was trying to bring things to a better web standard for these input types as was discussed in the original issue. I see that some others had commented on your particular situation as having issues before these changes as well. #4198 (comment)

Knowing that, would your comment be better as a new issue?

Also, your example 1 sounds like it might be a browser limitation (or trying to adhere to a standard in some way) rather than a component specific bug. In other words, Chrome is running in English, and therefore not expecting a comma as a decimal separator regardless of the fact that the app is "running" in Slovenian. I'm not super familiar with localization and cultures for the web and how it interacts with Blazor, but maybe make sure you're setting the culture properly for the page/browser itself and not just the Blazor app itself.

Regardless, I think you'd get results faster with a new issue.