Blazor Interview Questions

A .NET framework for building interactive web UI with C# and Razor components instead of JavaScript. Components can render on the server or run in the browser via WebAssembly.

Public properties marked [Parameter] receive values from the parent component. [EditorRequired] warns when a required parameter is missing, and EventCallback parameters let children notify parents.

A .razor file that combines HTML markup with C# in an @code block. It renders UI, handles events and can be reused with parameters, like <ProductCard Product="p" />. Components can be pages (with @page) or building blocks.

Use @onclick, @onchange, @onsubmit and so on with a C# method or lambda: @onclick="Save" or @onclick="() => Remove(item.Id)". Handlers can be async Task, and Blazor re-renders the component after they finish.

Two-way data binding between an input and a field or property: <input @bind="Name" />. It updates on change by default; use @bind:event="oninput" for every keystroke and @bind:after to run code after an update.

@page "/products/{Id:int}" makes a component routable, and route parameters bind to [Parameter] properties. NavLink highlights the active link and NavigationManager.NavigateTo navigates in code.

Components that inherit LayoutComponentBase and render @Body. MainLayout is set in Routes.razor; a page can choose another with @layout AdminLayout.

Static SSR renders HTML without interactivity. Interactive Server handles events on the server over SignalR. Interactive WebAssembly runs .NET in the browser. Interactive Auto starts on the server and switches to WebAssembly once it is downloaded.

Use EditForm with a model, DataAnnotationsValidator, input components such as InputText, and ValidationMessage. Handle OnValidSubmit to save.

Through parameters and EventCallbacks for parent/child, cascading values for a subtree, or a scoped/singleton state service injected with DI that raises change events.

IJSRuntime.InvokeAsync calls JavaScript functions from C#, and [JSInvokable] methods let JavaScript call .NET. Use it for browser APIs Blazor doesn’t wrap, such as clipboard or charts.

The default render mode in a Blazor Web App: components render to HTML on the server per request, with no persistent connection or WebAssembly. Forms post back normally, and enhanced navigation swaps page content without full reloads.

Fast first load and full server access, but every UI event goes over a SignalR circuit, so latency affects responsiveness, each user holds server memory and the app stops working when the connection drops.

The .NET runtime and your app download to the browser, so the first load is heavier, but then the UI runs client-side with no server round trips and can work offline. The code is public — it cannot hold secrets or access the database directly.

Use @inject IProductService Products in markup or [Inject] on a property in code-behind. Register services in Program.cs. Scoped services live per circuit in Interactive Server and per app in WebAssembly.

Inject HttpClient (configured with the API base address) and use GetFromJsonAsync<T>, PostAsJsonAsync and so on. Handle loading and errors, and add a DelegatingHandler to attach access tokens.

1@inject HttpClient Http
2

3@if (products is null) { <p>Loading…</p> }
4else { foreach (var p in products) { <p>@p.Name</p> } }
5

6@code {
7    private List<ProductDto>? products;
8    protected override async Task OnInitializedAsync() =>
9        products = await Http.GetFromJsonAsync<List<ProductDto>>("api/products");
10}

Inject IDbContextFactory<AppDbContext> and create a short-lived context per operation with await using. A single scoped DbContext would live for the whole circuit and is not thread-safe.

Wrap markup in <AuthorizeView> with <Authorized> and <NotAuthorized> sections, protect pages with @attribute [Authorize], and read the user from the cascading Task<AuthenticationState>. Enforce rules on the server too.

Use ASP.NET Core authentication, AuthorizeView and [Authorize] for UI, and always authorise on the server or API — WebAssembly code runs on the client and can be inspected or modified.

Use Virtualize for long lists, @key for list diffing, override ShouldRender where appropriate, avoid unnecessary re-renders from frequent events, choose render modes carefully and enable AOT/trimming for WebAssembly.

SetParametersAsync, OnInitialized{Async} (once), OnParametersSet{Async} (each time parameters change), then rendering and OnAfterRender{Async}(firstRender). Implement IDisposable or IAsyncDisposable to clean up.

Use <ErrorBoundary> around risky UI to show fallback content instead of crashing the circuit, log with ILogger, and handle API failures explicitly. In Interactive Server an unhandled exception terminates the circuit.

Prerendering runs OnInitializedAsync on the server and again when the component becomes interactive. Use PersistentComponentState (or the declarative [PersistentState] attribute in .NET 10) to pass the data so it is not fetched twice.

Publish with dotnet publish -c Release and host it like any ASP.NET Core app (App Service, IIS, containers). For Interactive Server enable WebSockets and sticky sessions behind a load balancer, or use Azure SignalR Service. Standalone WebAssembly can be hosted as static files.

Use DataAnnotations with <DataAnnotationsValidator />, custom ValidationAttribute classes, IValidatableObject for cross-field rules, or a FluentValidation integration. Add server errors with a ValidationMessageStore after the API responds.