API Proposal: Blazor SSR TempData support

[javiercn]

Background and Motivation

Blazor SSR currently has no built-in mechanism for TempData — data that persists between HTTP requests with read-once semantics. MVC/Razor Pages have TempData for flash messages, POST-Redirect-GET patterns, and one-time notifications. Blazor developers had to build custom solutions. This feature adds native TempData support with pluggable storage backends (cookies by default, session storage as alternative), plus a [SupplyParameterFromTempData] attribute consistent with other SupplyParameterFrom* attributes.

The [SupplyParameterFromTempData] attribute is powered by two new framework abstractions — CascadingParameterSubscription and TryAddCascadingValueSupplier — which enable attribute-driven cascading value suppliers without building a full ICascadingValueSupplier from scratch.

PRs #64749 and #65306, fixes #49683 and #65039. Design proposal: issue #65039.

Proposed API

namespace Microsoft.AspNetCore.Components;

+ public interface ITempData
+ {
+     object? Get(string key);
+     void Keep();
+     void Keep(string key);
+     object? Peek(string key);
+ }

+ public abstract class CascadingParameterSubscription : IDisposable
+ {
+     public abstract object? GetCurrentValue();
+     public abstract void Dispose();
+ }

namespace Microsoft.AspNetCore.Components.Endpoints;

+ public enum TempDataProviderType
+ {
+     Cookie = 0,
+     SessionStorage = 1,
+ }

public class RazorComponentsServiceOptions
{
+    public CookieBuilder TempDataCookie { get; set; }
+    public TempDataProviderType TempDataProviderType { get; set; }
}

namespace Microsoft.AspNetCore.Components.Web;

+ [AttributeUsage(AttributeTargets.Property, AllowMultiple = false, Inherited = true)]
+ public sealed class SupplyParameterFromTempDataAttribute : CascadingParameterAttributeBase
+ {
+     public string? Name { get; set; }
+ }

namespace Microsoft.Extensions.DependencyInjection;

public static class CascadingValueServiceCollectionExtensions
{
+    public static IServiceCollection TryAddCascadingValueSupplier<TAttribute>(
+        this IServiceCollection serviceCollection,
+        Func<IServiceProvider, Func<ComponentState, TAttribute, CascadingParameterInfo, CascadingParameterSubscription>> subscribeFactory)
+        where TAttribute : CascadingParameterAttributeBase;
}

Usage Examples

Basic attribute-based access:

@page "/form"

<p>@Message</p>

<form @onsubmit="Submit">
    <input @bind="Input" />
    <button>Submit</button>
</form>

@code {
    [SupplyParameterFromTempData]
    public string? Message { get; set; }

    private string? Input;

    void Submit()
    {
        Message = "Success!";
        NavigationManager.NavigateTo("/form", forceLoad: true);
    }
}

Direct ITempData access via cascading parameter:

@code {
    [CascadingParameter]
    public ITempData? TempData { get; set; }

    protected override void OnInitialized()
    {
        _message = TempData?.Get("Message") as string;
        // Or peek without consuming:
        var notification = TempData?.Peek("Notification") as string;
        // Or keep for another request:
        TempData?.Keep("Message");
    }
}

Alternative Designs

TempData is provided as a cascading value rather than requiring explicit injection, making it accessible throughout the component tree. Cookie-based storage is the default (matching MVC behavior) because it doesn't require additional middleware. The [SupplyParameterFromTempData] attribute was added in a follow-up PR to reduce boilerplate for simple read/write scenarios, consistent with [SupplyParameterFromQuery] and [SupplyParameterFromForm].

Risks

• When a component uses both TempData["key"] directly and [SupplyParameterFromTempData] for the same key, the final persisted value depends on execution order. Mixing approaches for the same key is unsupported.
• TryAddCascadingValueSupplier is a low-level extensibility point for framework authors; misuse could cause unexpected cascading parameter behavior.

[dotnet-policy-service]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[github-actions]

Triage Summary

Area: area-blazor ✅ (already labeled — Blazor SSR components, ITempData, [SupplyParameterFromTempData], CascadingParameterSubscription, RazorComponentsServiceOptions)
Type: api-proposal — formal API surface proposal with diff blocks, motivated by existing issues (#49683, #65039), and providing new public interfaces, attributes, and service registration helpers.

Potential Duplicates

• TempData design proposal #65039 — Design proposal for Blazor TempData (referenced by this issue as the upstream design proposal; not a duplicate, this is the formal API review issue)
• Blazor TempData #49683 — Related feature request being addressed by this proposal (also not a duplicate)
• No other open duplicate issues found.

Notes

• The issue already carries area-blazor and api-ready-for-review; adding api-proposal as the type label.
• No regression — this is a new feature addition.
• Mentions PRs TempData support for Blazor #64749 and SupplyParameterFromTempData support for Blazor #65306 as the implementation, so the code is already available for API review.
• TryAddCascadingValueSupplier is a low-level extensibility point; the API review may want to assess discoverability and whether it should be in a more internal namespace.

Generated by Issue Triage Agent for dotnet/aspnetcore for issue #66390 · ● 248.2K · ◷