Docs: Fix possible NullReferenceException and Cross-Origin Request Blocked

[ScarletKuro]

Description

I think this should fix the problem reported by @Mr-Technician

How Has This Been Tested?

Visual

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• The PR is submitted to the correct branch (dev).
• My code follows the code style of this project.
• I've added relevant tests.

[Mr-Technician]

I'm still confused as to how/why this is showing up only on iOS mobile.

[ScarletKuro]

I'm still confused as to how/why this is showing up only on iOS mobile.

I believe that the issue you encountered might be either a coincidence or related to some problem with HttpClient on iOS. From the stack trace you provided, the exception occurred at BuilderRenderTree>b__0_135.
By de-compiling and examining this method, we can see that the problem is likely caused by the _nugetPackage object, as the following line indicates: __builder5.AddContent(745, ((Decimal) this._nugetPackage.TotalDownloads).RoundedToString());.
that the only line of code in the BuilderRenderTree>b__0_135.

[ScarletKuro]

related to some problem with HttpClient on iOS.

It would be nice to see the console log since it's wrapped with try-catch, but I think it's not possible on iOS.

[ScarletKuro]

@Mr-Technician I just got the same error on PC with Firefox which means its not iOS related, it looks like just a common problem when API is down or we get rate limited.

[Mr-Technician]

related to some problem with HttpClient on iOS.

It would be nice to see the console log since it's wrapped with try-catch, but I think it's not possible on iOS.

For future reference, this should be possible using inspect://chrome, which logs on iOS chrome console messages into a separate tab.

@Mr-Technician I just got the same error on PC with Firefox which means its not iOS related, it looks like just a common problem when API is down or we get rate limited.

This would make sense

[ScarletKuro]

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://azuresearch-usnc.nuget.org/query?q=packageid:mudblazor&take=1. (Reason: CORS request did not succeed). Status code: (null).
On some browsers we get this.

[ScarletKuro]

Doesn't seems that setting cors on WasmHost has any effect :(

[ScarletKuro]

Ok I found a way to fix the cross origin, but I will update the PR later. I need to polish the code and I'm busy rn.

[henon]

LGTM, is it ready for merge?

[ScarletKuro]

I have added a fix for the Cross-Origin Request Blocked issue. Ideally, we should have used a typed/named HttpClient, but it would have required adding the additional Microsoft.Extensions.Http library to MudBlazor.Docs and changing all the samples that use HttpClient directly to use IHttpClientFactory or a typed wrapper for the backend calls. Instead, I have taken a different approach by creating own instance of HttpClient in DiscordApiClient, NugetApiClient, and GitHubApiClient.

Changed the lifetime of these Clients instances from scoped to singleton to prevent injection of an HttpClient that is related to localhost. This ensures that the HttpClient instances act as singletons across the entire application and will be correctly dispose HttpClient during application shutdown. I use a similar approach at work in some of the WebAssembly projects that have multiple API clients.

[ScarletKuro]

LGTM, is it ready for merge?

Now yes.

[henon]

👍