Use of HttpClient, Newtonsoft.Json, or F# Async fails to fetch

[panesofglass]

I tried delegating to a class library to fetch data. The class library has only the core HttpClient methods such as ReadAsStringAsync, so I added Newtonsoft.Json as a dependency. When I run the app, the fetch fails. I think something is wrong either with the standard methods or use of Newtonsoft.Json. However, as I also used F# and an async computation, it's possible that is the culprit. Any pointers?

Here's the reproduced call: https://github.com/panesofglass/blazorapp/blob/master/BlazorApp1/Pages/FetchData.cshtml#L43

Here's the implementation in the helper library (in F#):
https://github.com/panesofglass/blazorapp/blob/master/Library1/Library.fs#L24-L32

Update: I was able to remove the use of F# Async, and the fetch still fails.

[rdavisau]

For http - you need to construct an HttpClient instance with Blazor's BrowserHttpMessageHandler, so that the request goes via the browser - https://learn-blazor.com/architecture/rest-api/#what-happens-in-the-background . For JSON Blazor has baked in SimpleJson which you can see in the sample or the source. I'm also trying to use Json.NET (because a dependency uses it) - curious to see if you also hit the same problem as me - aspnet/Blazor#370

[rstropek]

Did you look at @SteveSandersonMS comments on size of JSON libraries. Do you want/plan to use Json.NET despite of its size? I mainly work with B2B customers where size of web apps are less important. Users typically have good connectivity and assets could be cached on the client. Therefore, I would like to have to additional functionality that Json.NET gives me although it makes Blazor apps larger. I would be curious to hear your thoughts on this.

[gingters]

My personal take on this is: I use Json.NET in my day to day work on the server-side and it can do everything you could imagine. However, in 95%+ of cases you'd probably only need 10% of its feature set. So as long as you don't really need the advanced features of Json.NET in your application (and chances are, you don't), any other Json lib will probably do the job just as good and when they are smaller it's fine.

That said, size for an SPA only matters when it's an app for end-users that is available through public internet. If you do a business app where you'd package the SPA in a mobile app (i.e. Cordova) or into an Electron package, or even if the environment is such that client browsers are on a local network with the web server serving the SPA, then a few hundred KB don't matter as much. Also, libraries are easily cacheable, so it usually is only a one-time download.

So, I guess the most fitting answer is again: It depends ;)

[RyoukoKonpaku]

I wonder if it's possible to use the IL Linker to strip Json.Net? Especially if you'd only use a part of APIs in reality. I'd be nice as you'd get the flexibility of using only what you want but also not having the extra payload size that comes with all Json.Net's libs

[TFTomSun]

@gingters
From my point of view its not really a json.net specific issue. Blazor can reference net standard 2.0 libraries. So I expect, that it (one day) simply works when I do so. Otherwise we need another, reduced, net standard version. C# is a compiler based language, so when the compiler says "ok", I expect no "unsupported / unexpected error" exceptions at runtime. From my point of view that's the most important thing to do: be able to run what you can compile and be able to compile what you can reference.

[panesofglass]

@rdavisau yes, it seems this is the same issue as aspnet/Blazor#370. I'm closing this as a duplicate. After adding Blazor as a dependency to the library project, I was able to use the HttpClient extensions and resolve the issue. However, I think it would be nice to just be able to use whatever library may be in use in an existing project.