Skip to content

Conversation

@anth12
Copy link
Contributor

@anth12 anth12 commented Jan 23, 2026

No description provided.

@mckaragoz mckaragoz merged commit a2ffc22 into CodeBeamOrg:dev Jan 23, 2026
1 check passed
@codecov
Copy link

codecov bot commented Jan 23, 2026

Codecov Report

❌ Patch coverage is 60.00000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 67.96%. Comparing base (6708197) to head (674c561).
⚠️ Report is 1 commits behind head on dev.

Files with missing lines Patch % Lines
...dBlazor.Extensions/Components/Wheel/MudWheel.razor 0.00% 0 Missing and 3 partials ⚠️
...ensions/Components/CodeInput/MudCodeInput.razor.cs 83.33% 1 Missing ⚠️

❌ Your patch status has failed because the patch coverage (60.00%) is below the target coverage (90.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files
@@            Coverage Diff             @@
##              dev     #589      +/-   ##
==========================================
- Coverage   67.98%   67.96%   -0.02%     
==========================================
  Files         106      105       -1     
  Lines        7412     7405       -7     
  Branches     1277     1276       -1     
==========================================
- Hits         5039     5033       -6     
+ Misses       1897     1896       -1     
  Partials      476      476              

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@mckaragoz
Copy link
Contributor

MudWheel also broke after new Converter change on MudBlazor, i also fixed it. Thanks 🥇

@ScarletKuro
Copy link
Contributor

ScarletKuro commented Jan 24, 2026

Should have migrated that

Converter = Conversions.From((DateTime? x) => x?.ToString(DateFormat), x => DateTime.TryParseExact(x, DateFormat, null, DateTimeStyles.None, out DateTime dt) ? dt : null);

and
public IConverter<T?, string?> Converter { get; set; } = new DefaultConverter<T?>();

To use GetDefaultConverter() as well.
And make the normal one Converter { get; set; } = null

The idea was that the default is GetDefaultConverter, but when someone wraps a component, they don't need to set the Converter property when wrapping, otherwise they get exception. And now the Converter is to override the default one.

@mckaragoz
Copy link
Contributor

Where should we call GetDefaultConverter, in component constructor? In MudWheel, i changed Converter.Convert to ConvertSet method, because converter is null now. Probably i still miss how users override Converter. What's the correct way to set initial value to Converter parameter?

@ScarletKuro
Copy link
Contributor

Where should we call GetDefaultConverter, in component constructor?

Nowhere. It will be automatically handled by MudFormComponent

Probably i still miss how users override Converter

Just like usual, via setting the Converter parameter.
Logic is simple if Converter is null fallback to GetDefaultConverter

@mckaragoz
Copy link
Contributor

Nowhere. It will be automatically handled by MudFormComponent

But in MudWheel.razor Converter.Convert method throws null reference exception due to Converter. Should we only use ConvertGet and ConvertSet methods?

@ScarletKuro
Copy link
Contributor

Should we only use ConvertGet and ConvertSet methods

Yes. If you have trouble accessing it (because it’s protected) from other child components and you need the parent’s converter, you can make a public or internal one in the parent that calls ConverterGet / ConverterSet.

@ScarletKuro
Copy link
Contributor

ScarletKuro commented Jan 24, 2026

Actually I looked the code closer, most components inherit from MudComponentBase, so setting default converter like:

public IConverter<T?, string> Converter { get; set; } = new DefaultConverter<T?>();

Is fine and using Converter.Convert / Converter.ConvertBack. I thought you are suing MudFormComponent, sorry for noise.

The only problem with that I see, is that Converter doesn't handle conversion exceptions anymore, it bubbles up, and MudFormComponent handles that with ConvertGet / ConverterSet

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants