Aspnetcore.docs: Add SignalR Blazor logging coverage

[guardrex]

https://github.com/dotnet/aspnetcore/issues/22706#issuecomment-642226932

cc: @captainsafia

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 7184a308-a254-9350-a5cd-5bced1f369ae
• Version Independent ID: 726e3bf1-f367-d733-8933-bccc04da0e16
• Content: Logging in .NET Core and ASP.NET Core
• Content Source: aspnetcore/fundamentals/logging/index.md
• Product: aspnet-core
• Technology: aspnetcore-fundamentals
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[guardrex]

@captainsafia Here's some draft lingo to get started ...

Use a logger provider extension method (for example, \) or inject an instance of \, and call \ to add the provider:

```csharp
var connection = new HubConnectionBuilder()
    .WithUrl(NavigationManager.ToAbsoluteUri("/chatHub"))
    .ConfigureLogging(logging => logging.Add{PROVIDER})
    .Build();
```

For more information, see \.

Modified code ... uh ... er ... cough cough stolen cough :smile: ... from @tboby at https://github.com/dotnet/aspnetcore/issues/22706#issuecomment-641453132. Thanks @tboby! 🏎️

The draft text doesn't drill down to any particular provider ... they can use any provider they want there, correct?

[BrennanConroy]

they can use any provider they want there, correct

No, that's the problem. ConsoleLogger uses a thread which doesn't work in WASM.

[guardrex]

Sorry ... bad guess. I should've read the issue!

How about ...

Inject an instance of \, loggerProvider in the following example, and call \ to add the provider:

```csharp
var connection = new HubConnectionBuilder()
    .WithUrl(NavigationManager.ToAbsoluteUri("/chatHub"))
    .ConfigureLogging(logging => logging.AddProvider(loggerProvider))
    .Build();
```

For more information, see \.

[guardrex]

btw @BrennanConroy ... Can I put in a PR that changes "myhub" to "chathub" everywhere? The docs go back-and-forth a bit on it. Also, I can make sure that var connection = is used everywhere. I think I've seen one or more var client = in the docs.

[BrennanConroy]

😆 go for it

[tboby]

@guardrex Thanks for helping make this clearer to others! I'm just going to splurge a bit of feedback on this topic here, feel free to ignore :)

That snippet by itself will probably be enough to help people get logging working, but it doesn't explain why injecting that logging provider works, nor inform people of the magic that is different to non-wasm.

At the top of the page this section explains that the Generic Host sets up a number of loggers, which is here I think.

The only reason we can just inject the logging provider is because the WebAssemblyHostBuilder does a similar thing here.

Perhaps a follow up task would be to expand this section to mention the existence of WebAssemblyConsole and WebAssemblyConsoleLoggerProvider (which isn't mentioned anywhere in the docs as far as I can see).

[guardrex]

Depending on the context, yes, we can add additional information. We often avoid writing about how (under-the-covers) and why something works (i.e., design) in the framework implementations in order to speed up doc generation, save space (reduce reading time for less essential aspects), and cut maintenance costs. Often, devs don't care about the wee details ... they just have a scenario that they want to work. I'll leave it to @captainsafia and @BrennanConroy to determine what depth of coverage to provide.

which isn't mentioned anywhere in the docs as far as I can see

Neither of those are in the API docs, so we'll need to sort that out first: Are they for 5.0? If not, will they get API doc coverage? We feel like for things that devs probably won't directly use in the vast majority of apps that we can leave them to API docs to cover. Right now tho, that's not even an option for those two.

[captainsafia]

With regard to depth, I think we can explain that injecting the ILoggingProvider will add our custom WebAssemblyConsoleLogger to the logging providers passed to HubConnectionBuilder. Unlike a traditional ConsoleLogger, the WebAssemblyConsoleLogger is essentially a wrapper around browser-specific logging APIs (e.g. console.log) so it can be used from within Mono inside a browser context.

I don't know if I would have these docs specifically in the logging page. If we had a page that was "things that are a little bit different in Blazor WASM" and linked to the content from there that might be more organized but I will leave that the experts.

Hopefully, the explanation above is helpful.

[guardrex]

We don't currently have another spot for this. It should be ok in the new little logging section that I'll add under Blazor WASM in logging.

What about WebAssemblyConsoleLogger not being in the API docs?

https://docs.microsoft.com/en-us/dotnet/api/?term=WebAssemblyConsoleLogger

[guardrex]

🤔 ... Acutually, we do have a bit of logging config coverage in the Blazor hosting model configuration topic. We're about to reorganize Blazor content, and that topic might be dropped in favor of using other locations for its coverage. All Blazor logging content might end up in the Logging topic, or Blazor might get its own separate mini Logging topic. It's under discussion right now.

I'm going to add this to Logging for now, and we'll see how it plays out.