Fetch And Send Data

.NET (Microsoft)OfficialPublished by .NET (Microsoft)

Skill
Guidelines
Software development
MIT
No issues found

From the author

Call APIs, load data into components, and handle the async lifecycle in Blazor. USE FOR fetching data from a backend, submitting data to an API, displaying loading/error states, registering HttpClient, building service abstractions for Auto/WebAssembly render modes. DO NOT USE for form validation (see collect-user-input), prerendering persistence (see support-prerendering), or project scaffolding (see create-blazor-project).

— the description by .NET (Microsoft)

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to handling data operations in Blazor, covering the nuances of different interactivity modes (Server, WebAssembly, Auto). It outlines best practices for registering HttpClient, managing component lifecycles, implementing error handling via ErrorBoundary, and abstracting services for cross-platform compatibility. The guide emphasizes safe, performant patterns for loading data, handling parameter-driven reloads, and preventing common pitfalls like PII exposure in error messages.

What it does

Registers HttpClient for API communication in Blazor applications.
Implements asynchronous data fetching patterns within component lifecycles.
Configures error handling strategies using ErrorBoundary and custom catch blocks.
Manages parameter-driven data reloads with cancellation support.
Provides patterns for abstracting data services for Auto and WebAssembly modes.
Handles loading states and UI overlays for improved user experience.

When to use it

When fetching data from backend APIs or submitting data to services.
When building components that need to support multiple Blazor render modes.
When implementing robust error handling for asynchronous operations.
When data needs to be reloaded based on changing route or query parameters.
When you need to abstract data access to support both server-side and client-side execution.

Advantages

Ensures consistent error handling across the application.
Prevents common security risks like PII exposure in error messages.
Optimizes performance by handling cancellation and avoiding redundant reloads.
Provides a clear architectural path for sharing logic between server and client.
Improves user experience through standardized loading and error states.

Usage examples

“How do I fetch a list of products in a Blazor component?”: The agent provides a pattern using OnInitializedAsync, injecting a service, and handling the null state to show a loading indicator.
“How can I handle errors when calling an API in Blazor?”: The agent demonstrates wrapping the component in an ErrorBoundary and using specific catch blocks for timeouts while logging details via ILogger.
“How do I reload data when a URL parameter changes in Blazor?”: The agent provides a pattern using OnParametersSetAsync with a guard to track the current parameter and a CancellationTokenSource to manage concurrent requests.
“How do I share a service between Blazor Server and WebAssembly?”: The agent explains creating an abstract base class and registering the appropriate implementation in each project's Program.cs.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/dotnet/fetch-and-send-data/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip fetch-and-send-data.zip -d .agents/skills

Documentation by .NET (Microsoft)

Fetch and Send Data

Step 1 — Read AGENTS.md

Check Interactivity Mode and Scope:

Mode	Data access
None (Static SSR)	Server-side: inject services/`DbContext`. Use `[StreamRendering]` for loading UX.
Server	Server-side: inject services/`DbContext`. Guard prerender with `??=` + `[PersistentState]`.
WebAssembly	Browser-side: `HttpClient` only. No direct server access.
Auto	Both server and browser. Always go through an API.

Step 2 — Register HttpClient

Only needed when calling external APIs from Server, or always for WebAssembly/Auto. Server components accessing their own database should inject DbContext or a service directly.

// Named client — requires Microsoft.Extensions.Http NuGet
builder.Services.AddHttpClient("CatalogAPI", client =>
{
    client.BaseAddress = new Uri("https://api.example.com/");
});

// Typed client
builder.Services.AddHttpClient<CatalogClient>(client =>
    client.BaseAddress = new Uri("https://api.example.com/"));

For WebAssembly/Auto with prerendering, register in both server and .Client Program.cs.

Step 3 — Fetch Data

Simple load

@page "/products"
@inject CatalogClient Catalog

@if (products is null)
{
    <p>Loading…</p>
}
else
{
    @foreach (var p in products)
    {
        <p>@p.Name — @p.Price.ToString("C")</p>
    }
}

@code {
    private Product[]? products;

    protected override async Task OnInitializedAsync()
    {
        products = await Catalog.GetProductsAsync();
    }
}

No error handling needed in the simplest case — wrap the component usage in <ErrorBoundary> at the parent/layout level to catch unhandled exceptions.

Static SSR — StreamRendering

Without [StreamRendering], the user sees nothing until OnInitializedAsync completes:

@attribute [StreamRendering]

Only affects Static SSR. No effect on interactive components.

Prerendering guard

Prerendering calls OnInitializedAsync twice. Skip the duplicate:

[PersistentState] private Product[]? products;

protected override async Task OnInitializedAsync()
{
    products ??= await Catalog.GetProductsAsync();
}

See the support-prerendering skill for details.

Step 4 — Handle Errors

Use <ErrorBoundary> as the default error strategy. It provides a consistent error experience across all components without any per-component catch logic. Wrap component usage at the layout or parent level:

<ErrorBoundary>
    <ChildContent>
        <ProductList />
    </ChildContent>
    <ErrorContent>
        <div class="alert alert-danger">Something went wrong. Please refresh.</div>
    </ErrorContent>
</ErrorBoundary>

Non-cancellation exceptions (HttpRequestException, etc.) propagate to ErrorBoundary automatically — no catch blocks needed in the component.

Cancellation is special

ComponentBase silently swallows all OperationCanceledException — both self-initiated (disposal, parameter change) and external (HttpClient timeout). ErrorBoundary never sees them. This means:

Self-cancellation → silently ignored. Correct behavior, no action needed.
External cancellation (timeout) → also silently swallowed. Component gets stuck in loading state. Usually acceptable — timeouts are rare.

When to add in-component error handling

Only add catch blocks when the component needs behavior ErrorBoundary can't provide — typically retries or timeout-specific messages. Even then, only catch what you need:

// Catch only external cancellation (timeouts) — everything else flows to ErrorBoundary
catch (OperationCanceledException ex) when (!cancellationToken.IsCancellationRequested)
{
    Logger.LogWarning(ex, "Request timed out for category {CategoryId}", CategoryId);
    error = "The request timed out. Please try again.";
}

If the component also needs to handle general errors with a retry button instead of letting ErrorBoundary take over:

catch (OperationCanceledException ex) when (!cancellationToken.IsCancellationRequested)
{
    Logger.LogWarning(ex, "Request timed out for category {CategoryId}", CategoryId);
    error = "The request timed out. Please try again.";
}
catch (Exception ex)
{
    Logger.LogError(ex, "Failed to load products for category {CategoryId}", CategoryId);
    error = "Unable to load products. Please try again.";
}

Rules

Never display exception.Message — it may contain PII, connection strings, or internal details. Use hardcoded user-friendly messages.
Always log through ILogger — the real exception goes to the logging pipeline.
Services must accept CancellationToken — pass it to every async call so work stops when the component cancels.

Step 5 — Parameter-Driven Reloading

When data depends on a route or query parameter that changes (e.g., navigating between /products/1 and /products/2), use OnParametersSetAsync with a guard to skip reloads for parameters that don't affect data.

Pattern: cancel-and-reload with stale data overlay

@page "/products/{CategoryId:int}"
@implements IAsyncDisposable
@inject ProductService ProductService
@inject ILogger<Products> Logger

@if (error is not null)
{
    <div class="alert alert-danger">
        <p>@error</p>
        <button @onclick="LoadAsync">Retry</button>
    </div>
}
else if (products is null)
{
    <p>Loading…</p>
}
else
{
    @if (isLoading)
    {
        <p><em>Refreshing…</em></p>
    }
    @foreach (var p in products)
    {
        <p>@p.Name — @p.Price.ToString("C")</p>
    }
}

@code {
    [Parameter] public int CategoryId { get; set; }
    [SupplyParameterFromQuery] public string? ViewMode { get; set; } // UI-only

    private CancellationTokenSource? cts;
    private int? loadedCategoryId;
    private List<Product>? products;
    private bool isLoading;
    private string? error;

    protected override async Task OnParametersSetAsync()
    {
        if (CategoryId == loadedCategoryId)
        {
            return; // Only ViewMode changed — no reload
        }

        loadedCategoryId = CategoryId;
        await LoadAsync();
    }

    private async Task LoadAsync()
    {
        if (cts is not null)
        {
            await cts.CancelAsync();
            cts.Dispose();
        }

        cts = new CancellationTokenSource();
        var cancellationToken = cts.Token; // Capture locally before await

        error = null;
        isLoading = true;

        try
        {
            var result = await ProductService.GetByCategoryAsync(CategoryId, cancellationToken);
            products = result;
        }
        catch (OperationCanceledException ex) when (!cancellationToken.IsCancellationRequested)
        {
            Logger.LogWarning(ex, "Timed out loading category {CategoryId}", CategoryId);
            error = "The request timed out. Please try again.";
        }
        finally
        {
            isLoading = false;
        }
    }

    public async ValueTask DisposeAsync()
    {
        if (cts is not null)
        {
            await cts.CancelAsync();
            cts.Dispose();
        }
    }
}

Key details:

Guard with tracked value: loadedCategoryId skips reloads when only UI parameters change.
Capture the token locally before the await — the CTS field may be replaced by a concurrent parameter change.
Don't null out products on subsequent loads — keep existing data visible with an isLoading overlay.
IAsyncDisposable cancels pending work when the user navigates away.

Step 6 — Send Data

var response = await http.PostAsJsonAsync("products", newProduct);
response.EnsureSuccessStatusCode();

var response = await http.PutAsJsonAsync($"products/{id}", updated);
response.EnsureSuccessStatusCode();

var response = await http.DeleteAsync($"products/{id}");
response.EnsureSuccessStatusCode();

Disable the submit button while saving to prevent duplicate requests. Show a saving indicator.

Step 7 — Service Abstraction for Auto or WebAssembly with Prerendering

When components run in both server and browser (Auto mode, or WebAssembly with prerendering), abstract data access behind an abstract base class:

public abstract class ProductServiceBase
{
    public abstract Task<Product[]> GetAllAsync(CancellationToken ct = default);
}

// Server — direct database access
public class ServerProductService(AppDbContext db) : ProductServiceBase
{
    public override async Task<Product[]> GetAllAsync(CancellationToken ct = default) =>
        await db.Products.ToArrayAsync(ct);
}

// Client — calls API
public class ClientProductService(HttpClient http) : ProductServiceBase
{
    public override async Task<Product[]> GetAllAsync(CancellationToken ct = default) =>
        await http.GetFromJsonAsync<Product[]>("api/products", ct) ?? [];
}

Don'ts

Don't call APIs in constructors — use OnInitializedAsync.
Don't use OnParametersSetAsync unless data depends on a changing parameter. Use OnInitializedAsync for initial loads.
Don't inject DbContext in WebAssembly/Auto components — no database in the browser.
Don't call your own server via HttpClient — inject the service directly.
Don't display exception.Message to users — PII risk. Log it, show a generic message.
Don't catch OperationCanceledException for self-cancellation — ComponentBase handles it.

Files

ATTRIBUTION.mdAdded by AutoGineer851 B
LICENSELicence file added by AutoGineer1.1 KiB
SKILL.md9.9 KiB

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

.NET (Microsoft)

Publisher

.NET (Microsoft) (Official)

Source

dotnet/skills · plugins/dotnet-blazor/skills/fetch-and-send-data · commit 96c3d68

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by .NET (Microsoft) or .NET (Microsoft).

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download fetch-and-send-data.zip