Coder Legion - Recent posts tagged blazor

Let the Router Own the Next Paint

Sat, 24 Oct 2026 07:06:52 +0000

Navigation bugs are often judged by their final state. Did the correct page appear? Did the authorization check pass? Did the URL settle on the expected address?

Those questions matter, but they can miss the frame that users actually notice.

In a recent component-based web fix, the destination page was correct. The address was correct. The authorization result was correct. Yet, between the address change and the destination render, the departing page painted once more. Because the framework also applied its scroll reset during that interval, users briefly saw stale content at the top of the viewport before the new page arrived.

The repair produced a useful general lesson: after an address change, the router should own the next visible paint.

A correct destination can still have a wrong journey

An end-state test sees a simple sequence:

start on page A;
navigate to page B;
assert that page B is visible.

The browser may have seen something richer:

page A is visible at the user’s current scroll position;
the address changes to B;
page A renders again under B’s address;
a framework scroll reset moves that stale page to the top;
page B finally renders.

Steps three and four may last only one frame. They are still part of the product.

This is why navigation correctness is not only about eventual state. It also includes the ordered render sequence between the user action and the destination becoming authoritative.

The hidden effect of an event receiver

The source of the extra paint was subtle. An asynchronous navigation callback was registered with the component that hosted the route tree as its receiver.

In many component frameworks, completing an event callback schedules a render of the receiving component. That behaviour is normally helpful: event handlers change state, so the framework redraws the owner automatically.

Navigation is different. The callback prepared the transition, but the router—not the departing component—owned the destination. When the receiver-bound callback completed, the framework rendered the old route tree once more. The router rendered the new page immediately afterward, but it was no longer responsible for the first batch after the address changed.

The fix did not add a delay, loading overlay, or animation. It removed the accidental receiver. The callback still ran, but its completion no longer implied that the departing route component needed to render. The router’s destination batch became the first visible paint after the address change.

Measure the interval, not just the answer

The strongest part of the repair was the test shape.

Instead of sleeping and hoping to catch a flicker, the test marked the instant the address changed. It then counted every component render until the destination page entered the render tree.

Before the change, that interval contained twelve render notifications in the exercised path. After the change, it contained zero.

The specific number is less important than the invariant:

Nothing else paints after the address changes and before the destination appears.

That assertion is deterministic. It does not depend on monitor refresh rate, screenshot timing, or a human noticing a flash. It also fails for the causal behaviour rather than a visual approximation of the symptom.

Keeping the old page has a boundary

There is a reasonable usability goal behind retaining the current page: an established screen is often a better placeholder than a blank shell while the destination prepares.

But retained content needs a strict boundary. The old page belongs to the source route and its source authorization decision. It must not start making decisions for the new address, consume state prepared for the destination, or imply that access to the destination has been granted.

Security invalidation is the important exception. If the user signs out or loses a role, the retained page must stop being authoritative immediately. Smoothness must never extend stale permission.

That gives us two complementary rules:

retain a certified source view only until its replacement is ready;
invalidate it immediately when the identity or authorization basis changes.

The result is continuity without authority leakage.

Test the negative space

A good transition test suite should cover more than the successful move between two ordinary pages.

Useful cases include:

an allowed destination;
a refused destination;
a layout or shell change;
sign-out during preparation;
role loss during preparation;
an older asynchronous result completing after a newer transition;
a callback that finishes on a different scheduling context.

These cases reveal who truly owns the transition. If several components can repaint or decide access for the same interval, the design is probably carrying more than one authority.

A practical review method

When reviewing client-side navigation, draw a short timeline: user action, address change, preparation, first destination render, and interaction-ready state.

For each gap, ask:

Which component may render?
Which route does that render belong to?
Which authorization decision supports it?
Can an event callback schedule an incidental redraw?
What happens if identity changes or an older task completes late?

Then write at least one sequence assertion. Final-state tests remain valuable, but they should be paired with a guard over the transition when a single wrong frame matters.

The leadership lesson

Small visual defects often expose unclear ownership rather than missing polish. A loading spinner might hide the flash, but it would not explain why the departing component could repaint under the destination address.

The more durable repair is to assign one owner to the critical interval and test that ownership directly.

Users experience every frame, not only the last one. Our tests should be willing to do the same.

Test the Owner, Not the Teardown

Tue, 20 Oct 2026 17:41:25 +0000

Flaky lifecycle tests often produce a tempting diagnosis: the cleanup code must be unreliable. Sometimes that is true. Sometimes the test is asking a framework harness to prove a narrower ownership contract, and the harness is free to finish work on a different schedule.

That distinction matters in interactive server-side UI systems. A component may subscribe to live updates, start a timer, register an observer, or attach a callback. The resource needs a clear owner and a reliable release path. But the test for that contract should not depend entirely on whether a whole rendered tree has completed teardown at one particular instant.

The shape of the failure

Consider a header component that subscribes to a process-local notification service. A child pop-up also owns a separate subscription. The component test renders the tree, publishes an update, observes the visual change, disposes the test context, and immediately expects the global subscription count to be zero.

That sounds reasonable. It is also broader than the claim we really want to prove.

Under a full test-suite load, the notification can overlap a render. The harness teardown call may return while the renderer still has a queued batch. At that instant the header might not yet have received its disposal callback. The non-zero count is therefore ambiguous: either the header leaked, or the harness has not disposed it yet.

A test with two possible explanations is a weak regression guard.

Waiting is not the same as proving

The first instinct is usually to add a retry window: wait for the subscription count to reach zero, perhaps for a few seconds.

That is appropriate when the product contract is genuinely eventual. It is not a universal cure for lifecycle tests. If the harness has left the component alive, waiting merely spends more time observing the wrong boundary. The test remains dependent on incidental scheduling and can still fail without a cleanup defect.

The key question is not, “How long should we wait?” It is, “Which object owns the resource, and what exact behaviour are we trying to prove?”

Put the assertion at the ownership boundary

The stronger test calls the owning component's disposal contract directly, on the correct renderer context, and checks only the resource that component owns.

If the header owns one subscription and a still-rendered child owns another, disposing the header should reduce the count by one. Expecting zero would incorrectly make the header test responsible for the child's lifetime as well.

That narrower assertion is not weaker. It is more precise:

the owner releases its resource;
an independently owned resource is not silently claimed by the parent test;
the result does not depend on whole-tree teardown timing; and
removing the owner's cleanup call makes the test fail consistently.

That last point is especially valuable. A small mutation check—temporarily disabling the cleanup call—shows whether the test detects the regression it claims to detect. If the test still passes, it is probably measuring something else.

Production code still needs lifecycle discipline

A focused test does not excuse fragile implementation. Cleanup should normally be idempotent because framework callbacks, navigation, error handling, and explicit shutdown can converge on the same release path.

The object should also refuse to acquire new resources after disposal. An asynchronous load may resume after the component has gone away. If its continuation subscribes again, a perfectly correct earlier disposal becomes irrelevant because nothing will release the new subscription.

The same reasoning applies beyond subscriptions. Failed in-flight loads should close or abandon temporary buffers. Retained arrivals should have a sensible bound. Work dispatched to another recipient should not accidentally carry ambient request state from the publisher. These are all lifecycle questions: who owns the state, when does ownership end, and what context is allowed to cross the boundary?

Keep two layers of evidence

Direct ownership tests and integration tests answer different questions.

An owner-level test asks: when this component is disposed, does it release what it owns, and can it remain released?

An integration test asks: does navigation, circuit shutdown, or framework teardown actually invoke the right lifecycle path across the rendered tree?

Both matter. The mistake is using only the second, broad test as proof of the first, narrow contract. When the broad test fails, you cannot tell whether ownership or orchestration is broken.

Separating the layers improves diagnosis. A direct test failure points toward the owner. An integration-only failure points toward wiring, scheduling, or framework interaction. The test suite becomes a map of contracts instead of a collection of timing guesses.

A practical checklist

For each subscription, timer, observer, or callback:

Name the owner explicitly.
Make release safe to call more than once.
Prevent acquisition after the owner is disposed.
Test the owner's release contract directly.
Give child-owned resources separate coverage.
Keep one integration test for the framework path.
Prove the test's sensitivity by breaking cleanup locally and seeing it fail.

The trade-off is a few more focused tests and slightly more explicit lifecycle code. In return, failures become actionable. You know whether the owner leaked, the child still legitimately owns something, or the framework has not completed teardown.

Reliable tests do not merely wait longer. They make ownership visible.

Hand Off Intent, Not Authority

Sun, 18 Oct 2026 08:36:51 +0000

Moving a user from one application host to another often looks harmless. A button opens a browser, the user continues, and the original client waits for them to return.

Architecturally, that is not merely navigation. It is a trust-boundary decision.

This becomes especially important when one user experience runs across several .NET hosts: perhaps an ASP.NET Core site, a Blazor WebAssembly client, and a .NET MAUI hybrid app. The shared components may look identical, but the hosts do not own the same secrets, sessions, callbacks, or security guarantees.

The lesson is simple: when a workflow crosses hosts, hand off intent, not authority.

The tempting shortcut

Suppose a client has already loaded an order-like resource and can display the next sensitive action. It is tempting to let every host render the same provider form or carry the current access proof into the browser.

That preserves continuity, but it also widens the boundary. A client that only needed to display state may now receive signed fields, transaction details, callback assumptions, or a reusable proof. Putting any of that into a query string or fragment creates more problems: URLs are copied, logged, cached, placed in browser history, exposed to extensions, and sometimes sent as referrers.

Shared UI does not imply shared authority. Reuse the presentation and state model where it helps, but make each host's capabilities explicit.

A narrower handoff

A safer design gives the less-trusted client one small capability: open a fixed public entry point on the authoritative host.

The destination should be deliberately boring. It should not contain an order reference, email address, one-time code, access token, signed provider fields, or a claimed outcome. It should have no dynamic query string or fragment. It communicates only this intent: “the user wants to continue this workflow on the web.”

The authoritative host then starts again from its own security context. It asks for the identifiers appropriate to the workflow, performs anti-forgery checks, verifies ownership through its normal mechanism, and only then exposes the sensitive action.

That separation gives each statement a precise meaning:

Opening the browser is navigation.
Proving ownership grants access in the destination host.
Starting the action is a separate command.
A callback or authoritative read confirms the outcome.

None of those statements is allowed to stand in for another.

Treat public configuration as an API

Installable browser clients need runtime configuration, but a generated client configuration document is still a public API. Do not serialize a server configuration tree and hope that only safe values happen to be present.

Build a small allowlist instead. For this kind of handoff, the browser might receive an enablement flag and a reviewed public origin. That is enough. Return the document with a no-store policy so a stale capability does not linger after an operational change.

Validate the destination before the application starts. Require the exact shape you intend: HTTPS, a root origin, no embedded credentials, no path, no query, no fragment, and no unexpected local or alternate-port destination. Keep the feature disabled when configuration is absent. If someone explicitly enables it with an invalid value, fail startup with a value-free error rather than echoing the bad input into logs.

Failing closed here is not pessimism. It turns configuration from ambient text into an enforceable security boundary.

Make the destination defensive too

The source client should generate a clean URL, but the destination should not trust that promise.

If someone arrives with a query string, canonicalize to the fixed entry before rendering. Apply no-store and a restrictive referrer policy. Do not pre-fill sensitive identifiers from URL input. Start with the ordinary ownership flow and its existing anti-forgery protection.

This matters because links escape their intended callers. They are bookmarked, pasted into messages, opened by scanners, and reconstructed by users. A robust boundary remains safe even when the source is not your application.

Failure must remain boring

A browser launch can fail for mundane reasons: platform policy, missing handlers, lifecycle changes, or an exception from the native shell. None of those failures should mutate domain state.

The client should report only that the launch did not happen. It should not create the sensitive form, mark work as started, grant access, or imply success. Concurrent clicks can be collapsed while an open attempt is running, but a failed attempt should be retryable.

This is a useful design test: if navigation failure requires compensation, the handoff probably carried too much authority.

Test the negative space

Most happy-path tests prove that a button eventually opens the right page. Boundary tests need to prove what cannot happen.

Useful tests include:

the capability is off by default;
malformed enablement and invalid destinations fail safely;
the client opens only the fixed path;
the URL contains no proof or private state;
each host renders only its intended action;
public configuration contains only allowlisted fields;
the web entry removes unexpected query data before rendering;
caching and referrer protections are present;
ownership and anti-forgery checks happen in the destination;
launch failure changes no workflow state; and
repeated clicks do not create duplicate launches.

These are negative properties. They are easy to lose during refactoring unless tests name them directly.

The trade-off is honest friction

Fresh ownership proof adds a step. A dedicated entry route, host-specific capability registration, and configuration validation add code. The boundary also needs maintenance as new hosts appear.

That cost buys something valuable: the sensitive operation stays with the host designed to own it. The other clients remain simpler, public configuration stays small, and failures have a narrow blast radius.

When reviewing any cross-host workflow, write down four things: the exact destination, the data allowed to cross, the authority that must be re-established, and the state a failed launch may change. If those answers are vague, the implementation probably is too.

Intent can cross a boundary. Authority should have to earn its way back in.

A Route Is Not a Feature Until Someone Can Reach It

Tue, 13 Oct 2026 07:01:11 +0000

Modern applications are often assembled from modules. That is good for ownership, deployment boundaries, and keeping large codebases understandable. It also creates a subtle user-experience failure mode: a page can compile, carry a valid route, pass its local tests, and still be effectively absent because no one can discover it from a real entry point.

This is not primarily a visual-design problem. It is an architecture-contract problem.

Routable is not reachable

Imagine an administrative application with pages spread across two modules. The team already has a test that scans routed pages and checks that each one appears in a navigation catalogue. The test is green, so the navigation surface looks covered.

Later, someone discovers that the scan only walks one module. The second route tree was outside its boundary. Pages there could be added indefinitely without the test knowing they existed.

That is the first important lesson: a completeness check is only as complete as its discovery mechanism.

When the scan is expanded, it finds an entry screen that has documentation and valid follow-on steps, but no link from the application itself. The workflow exists technically. Operationally, it begins with “type this URL.” That is not a usable feature contract.

Define a genuine entry point

The tempting fix is to accept any reference to the route. Perhaps another page links to it. Perhaps it appears on a tab rail. Perhaps a help article mentions it.

Those references are not equivalent.

A help article explains a feature; it is not application navigation. A link on a neighbouring screen can be useful, but it may make discoverability depend on an accidental journey. A tab rail is particularly deceptive: it helps someone move within an area only after they have reached one of its pages. It cannot prove that the area itself has an entrance.

The architectural rule should therefore name the user-facing property you actually want. For example:

Every static administrative workflow page must be represented by a discoverable entry in the primary hub available to its entitled audience.

That sentence is stricter than “the route is mentioned somewhere,” and that is precisely why it is useful.

Test pages, not strings

Route graphs have legitimate shapes that a simple string search will misclassify.

A parameterised detail page is usually reached from a list or search result. Giving every detail route a top-level card would be noisy and misleading. The test can classify routes containing parameters as downstream pages rather than entry pages.

The reverse case also matters. One page may answer on two route aliases for compatibility. Requiring two navigation cards would duplicate the same destination. The unit of the contract is the page, with at least one discoverable canonical route—not every literal route declaration.

These distinctions keep the test strict without making it simplistic.

Make the scan fail honestly

Source-scanning tests have a dangerous failure mode: they can pass after discovering nothing. A changed directory, glob, parser, or build layout can turn the result set into an empty collection, after which every “all pages are covered” assertion becomes vacuously true.

Add a coarse lower bound to the discovered page count. It does not need to encode the exact inventory. It only needs to make a broken scan conspicuous. Pair that with a useful failure message that lists uncovered entry pages and explains the intended remedy.

Exceptions deserve the same discipline. Sometimes an exception is legitimate, but an exemption list easily becomes a hiding place. Store a reason beside each exception, keep the list narrow, and assert that every exception still corresponds to a real uncovered case. Once navigation is fixed, the stale exception should fail the next test run.

That turns exceptions into temporary, reviewable decisions rather than permanent silence.

Align visibility with authorization

Navigation and authorization answer related but different questions.

Navigation visibility asks, “Should this person be offered this destination?” Authorization asks, “May this request proceed?” A hidden card is not a security boundary. Someone can still follow a saved link or construct a request directly.

The useful contract is alignment: the navigation entry should use the same entitlement expressed by the destination policy, while the page or endpoint continues to enforce that policy independently.

This check often exposes ambiguity. If a destination has only broad authentication while its navigation card is restricted to a privileged audience, do not quietly declare the card to be protection. Flag the mismatch for an explicit security decision. Navigation work should reveal authorization uncertainty, not accidentally resolve it.

The trade-off is real

A strict hub contract has costs. The catalogue grows. New pages require deliberate placement and wording. A hub can become crowded if every capability is presented at the same level.

The alternative, however, is not free. A loose rule produces accidental journeys, invisible capabilities, and tests that certify the presence of links without certifying usable discovery.

The practical balance is to keep the entry-point contract strict while allowing the interface to group, search, filter, and progressively disclose destinations. The architecture test should protect reachability; the visual design can protect clarity.

A small checklist

For a modular routed application:

Inventory every route tree, not only the first one the test was written for.
Classify static entry pages, parameterised downstream pages, and route aliases.
Identify the navigation roots users can actually reach.
Require every entry page to appear from an appropriate root.
Add a minimum discovery count to catch broken scans.
Make exemptions explicit, reasoned, narrow, and self-cleaning.
Align link visibility with destination authorization, while enforcing security at the destination.

The deeper lesson is that architecture includes the path a person can take through the system. If a feature has no honest entrance, its route is an implementation detail—not a delivered capability.

The Async Result Belongs to the Snapshot That Started It

Sat, 10 Oct 2026 06:01:28 +0000

Modern client components are long-lived, reactive, and full of asynchronous work. That combination creates a subtle class of defect: a response can be factually correct for the request that produced it, yet wrong for the screen that exists when it arrives.

This is especially important when a component mixes route parameters with identity-scoped state. The user can navigate while a request is in flight. Authentication can resolve, refresh, or change. The component instance may survive both events. Unless the component tracks which context owns each result, an older task can update a newer view.

The core rule is simple:

An awaited result belongs to the input snapshot that started it.

That snapshot is more than a component reference. It can include the current route value, the current authentication-state operation, and a monotonically increasing generation number.

How the race forms

Imagine a detail page that loads an item, then asks whether the current viewer has reacted to it. The page shows a highlighted action when the answer is yes.

The component begins loading item A for identity A. Before the viewer-specific request returns, the user signs out and another identity becomes current—or the same component navigates to item B. The old request then completes with a truthful answer: identity A did react to item A.

If the continuation writes directly to a shared isActive field, that truth is now displayed in the wrong context. Item B may appear active, or identity B may see state derived from identity A.

This is not merely a cosmetic race. Identity-derived state can influence which actions are enabled, what ownership badges appear, and which command a user can submit next.

Make ownership explicit

A practical pattern is to treat every meaningful input change as a new generation.

When a route or authentication input changes:

Increment the generation.
Capture the route and authentication input in local variables.
Clear state derived from the previous identity.
Disable identity-scoped actions while the new identity is unresolved.
After each await, confirm that the generation and captured inputs are still current.
Apply results only when those checks pass.

The checks matter after every awaited boundary, not only at the end. A component may load the main item, related content, entitlement state, reaction state, and cart state in sequence. Any await is a point where navigation or identity can change.

Cancellation tokens can reduce wasted work, and they are worth using when the underlying operation supports cancellation. But cancellation alone is not the ownership proof. Cancellation can race with completion, and some dependencies cannot cancel promptly. The continuation still needs to ask, “Does this result belong to the current snapshot?”

Fail closed while identity is unknown

There is another important state between old identity and new identity: unresolved identity.

Keeping the old viewer-specific UI visible during that interval is convenient, but unsafe. The component should clear ownership badges, active reactions, and similar derived state before awaiting the new authentication result. Any action that depends on identity should be disabled until the new snapshot is ready.

That brief disabled state is honest. The application does not yet know which identity owns the next command.

This principle also prevents an action from being sent using newly refreshed credentials while the visible UI still describes the previous viewer. Read state and write authority move together.

Test the interleaving, not only the outcome

Ordinary happy-path tests rarely expose this defect because requests finish in the same order they started.

A stronger component test controls the schedule:

Start a viewer-specific read and hold its response.
Change the route or authentication identity.
Wait for the new screen to settle.
Release the old response.
Assert that the current screen does not adopt the old result.

A separate test should hold authentication unresolved and verify that identity-scoped actions remain disabled. This proves that the UI fails closed during the transition.

There is also a useful counter-test: rerender with exactly the same inputs while a valid request is pending. The component should not discard or duplicate work merely because the framework rendered again. The boundary is a meaningful input change, not every render cycle.

These tests are valuable because they verify time and ownership, not just a final value. They turn a race that might appear once in a thousand interactions into a deterministic scenario.

The trade-off

Generation markers, captured snapshots, and repeated currentness checks add code. Temporarily disabling an action can introduce a small pause. Overusing the pattern can also make a component difficult to read.

The answer is not to attach a counter to every asynchronous line. Use the pattern where results are scoped to changing inputs: routes, selected records, authentication identity, workspace, locale, or another boundary that can change while the component remains mounted. Extract a small helper when the same ownership rule appears repeatedly.

The payoff is larger than visual correctness. Explicit async ownership reduces stale-route updates, prevents state from crossing identity boundaries, and stops commands from being enabled under an unresolved context.

The humble takeaway is this: asynchronous correctness is not only about receiving the right answer. It is also about proving that the answer still belongs here.

Design the Cursor, Not Just the Query

Mon, 28 Sep 2026 06:23:05 +0000

Pagination is often introduced as a performance improvement: fetch fewer rows, render less markup, and keep response sizes predictable. That is only half the job.

For an operational queue that changes while people work, pagination also defines what it means to continue reading. If that contract is weak, the database can answer every query correctly while the person using the screen still sees duplicates or misses work.

The important design question is not merely, “How many rows should this query return?” It is, “What does the next request mean after the underlying set has changed?”

Why offset paging drifts

Consider a queue ordered newest first. A reviewer asks for the first twenty-five rows. The next request uses an offset of twenty-five.

Between those requests, a new row arrives at the top. Every earlier row has moved down one position. The second query now begins with the final row from page one, so the reviewer sees a duplicate. More importantly, one unseen row has been pushed beyond the requested range.

This is not an exotic race. Append-mostly queues invite it because adding work is the ordinary operation. Offset paging treats positions as stable even though insertion changes every position below it.

Mutable sorting creates a similar problem. If the queue is ordered by status or last-updated time, an operator’s decision can move a row while the walk is in progress. A continuation based on that value inherits the instability of the workflow.

Continue from an immutable boundary

A stronger contract says: continue after the boundary returned by the previous read.

For a newest-first queue, that boundary can be an immutable creation or submission timestamp. New rows arriving above the boundary are not part of the current walk. They will appear when the reviewer starts again from the top, but they do not shift the meaning of “next.”

Equal timestamps need deliberate handling. Adding an identifier as a tie-breaker becomes fragile when data providers sort that type differently.

Another approach is to carry the boundary timestamp plus the number of rows already consumed at that exact timestamp. The database remains responsible for its native ordering within the tie, while the continuation records how far through that tie the walk has progressed. The detail matters less than the invariant: ties must neither duplicate nor hide rows.

Make the continuation part of the contract

An opaque cursor should not be a loosely encoded page number. It is protocol state, so treat it that way.

Useful safeguards include:

a version, so the format can evolve deliberately;
a strict length limit and parse validation;
the immutable boundary and tie position;
the active filter identity; and
sensible bounds on any stored count.

Binding the cursor to its filter is especially important. A position in “all open items” does not mean the same thing in “items for one category.” Reusing the cursor after changing filters can silently skip work. Rejecting that request is clearer than pretending the cursor is still meaningful.

Likewise, a malformed continuation should fail explicitly. Silently dropping it and returning the first page converts a bad request into a plausible-looking duplicate page. Operational software benefits from visible invalid states.

Keep every downstream read bounded

Paging the primary table is not enough if enrichment still loads data for the entire result set.

A common pattern reads the page, extracts its identifiers, and then fetches related summaries in a second query. That identifier list must come from the bounded page. Otherwise the visible query is paged while a hidden IN clause continues growing with the queue.

Fetching one extra primary row is a simple way to determine whether a continuation is needed. Return the requested page size, and issue a next cursor only when the extra row exists. The presence of that cursor—not whether the current page happens to be full—becomes the authoritative “has more” signal.

This also avoids an exact count on every read. For many live queues, “Page 3” plus Previous and Next is the more honest interface.

Carry the contract into the Blazor UI

Server-side continuation paging should not be wrapped in a client component that first downloads the entire queue. The UI has to follow the same contract.

A practical Blazor page can keep a small trail containing the cursor used to open each visited page. Next stores the returned cursor. Previous reuses the earlier cursor to re-read that logical page. After an operator records a decision, refresh the current page rather than throwing them back to the beginning.

Page changes should also clear any pending confirmation tied to a row that is no longer visible. That is a small state-management detail with a large clarity benefit: the user should never be asked to confirm an action on an item they cannot see.

Test the movement, not only the shape

Happy-path tests that assert “twenty-five rows returned” do not prove a paging contract.

The valuable cases exercise movement:

insert a newer row after reading page one, then verify page two has no gap or duplicate;
create several rows with the same boundary timestamp;
reject zero, negative, and excessive page sizes;
reject malformed, oversized, and filter-mismatched cursors;
verify related-data queries receive only current-page identifiers;
navigate Next and Previous in the component; and
perform an action and confirm the current page is refreshed.

These tests describe the promise a reviewer experiences, not merely an implementation detail.

The honest trade-off

Continuation paging is more work than offset paging. It needs a stable sort, a cursor format, versioning, filter binding, careful tie semantics, and focused tests. It also makes random access and exact page counts less convenient.

That cost is justified when the list is both live and operationally important. Bounded queries protect the system under bursty load; stable continuation protects the human workflow under concurrent change.

Takeaway: choose pagination from the mutation pattern, not from the table widget. If ordinary inserts can change what “next” means, the continuation itself deserves first-class design.

A Page Is Not Shipped Until People Can Find It

Fri, 25 Sep 2026 06:06:10 +0000

A routed page can compile, pass its authorization checks, have documentation, and still be functionally absent. If the people entitled to use it cannot discover a normal way in, the product behaves as though the capability was never built.

That is easy to miss in a modular Blazor application. One team adds pages in one project, another module owns a second page tree, and a central hub or navigation catalogue tries to present the whole product coherently. Each local change can look correct while the experience between modules quietly breaks.

The remedy is not another release checklist. It is an executable discoverability contract.

Define the invariant at the page boundary

A useful rule is simple:

Every static operational page must have one intentional entry point whose visibility matches the page's access rule.

“Static” matters. A detail page with an identifier in its route is normally reached from a list, search result, or parent screen. It does not need a global menu item. A screen that answers on two route aliases is still one page; adding two cards would create duplication rather than discoverability.

The rule should cover pages, not merely strings that resemble URLs. That keeps the test aligned with the product concept people actually use.

It should also say “intentional entry point,” not “mentioned somewhere.” A link buried inside another page may technically make a route reachable, but it does not necessarily make the capability findable. Likewise, a help article that names a screen is documentation, not navigation. Requiring a deliberate card or menu entry forces the information architecture to be explicit.

Scan every module, not only the original tree

Architecture tests often begin with a useful local assumption: all administrative pages live under one directory, namespace, or assembly. The test passes for years. Then a new module introduces another tree and the guard continues to report green because it never sees the new pages.

This is a particularly awkward failure because both the feature and the guard are “working as designed.” The design boundary is simply stale.

The test therefore needs a completeness check as well as a matching check. Enumerate every known page tree. Parse the routed components. Exclude only clearly contextual routes. Then compare the resulting pages with the navigation catalogue.

Add a sanity assertion too. If a mature tree suddenly produces zero—or far fewer—pages, the parser or directory assumption probably broke. Without that guard, a failed scan can look like perfect compliance.

When a new module owns pages, extending the scan is part of integrating that module. This turns architectural coverage into an explicit responsibility rather than inherited folklore.

The navigation entry should use the same access decision as the destination page. If the card is broader, people see an invitation that ends in refusal. If it is narrower, people who are entitled to use the page cannot find it.

It is tempting to reuse a nearby permission because it is convenient. That can be wrong in both directions. When no existing decision expresses the page's real audience, adding a focused visibility flag is usually clearer than bending an unrelated one.

But matching visibility does not turn navigation into security. A hidden card only changes what the interface presents. A direct request, a bookmarked address, or another client can still reach the endpoint. The page or server operation must continue to enforce authorization independently.

This separation produces a healthy pair of invariants:

navigation makes entitled capabilities discoverable;
authorization rejects requests that are not entitled.

Testing both is stronger than asking either mechanism to do two jobs.

Prefer a precise contract over “linked somewhere”

A broad reachability scan can be a good first diagnostic. Search the codebase for links to each route and identify pages that have no inbound reference. That quickly reveals obvious orphans.

As a permanent contract, however, “linked somewhere” is weak. A tab rail is visible only after someone has already reached a page in that tab set. A contextual link may depend on data or state. A help page may mention the route without providing product navigation. Source text can prove that a string exists; it cannot prove that the intended audience has a clear entry point.

Tightening the rule to require the chosen navigation catalogue makes the standard less ambiguous. It also creates useful pressure: when a page fits nowhere, the team must decide whether the navigation model is incomplete, the page is contextual, or the feature should not be exposed yet.

Accept the maintenance cost deliberately

The stricter contract adds work. New pages need catalogue entries, accurate visibility mapping, and suitable grouping. Route conventions must be understood well enough for the test to distinguish static pages, detail pages, and aliases. Large navigation surfaces may expose sections that no longer fit their historical categories.

Those are not test problems to hide with a long exemption list. They are product and architecture decisions the test has made visible.

Keep exemptions small, named, and justified by a navigation model rather than by inconvenience. Fail when an exemption becomes stale. If a page genuinely belongs behind a list or workflow, encode that reason. If it is an operational destination, give it an intentional entry point.

The payoff is modest but durable: completed capabilities do not disappear between modules, permission drift becomes easier to see, and a new page cannot quietly land outside the product's navigation contract.

A page is not shipped merely because its route exists. It is shipped when the right person can find it—and the wrong person still cannot execute it.

When a Green Test Protects the Wrong Authorization Rule

Tue, 22 Sep 2026 07:08:12 +0000

An automated test is useful only when its assertion represents the rule we intend to preserve. That sounds obvious until a test passes for the exact condition that should make a reviewer uneasy.

A recent Blazor change offered a concrete reminder. Two routed administrative pages required a signed-in user but did not assert a permission policy at the page. The links that led to them were filtered by permission. That made the interface look appropriately restricted, while a signed-in person could still enter the URL directly. Two existing tests expected the permissive page attributes, so the green suite helped the gap survive.

The engineering lesson is broader than those pages: when a test blesses an authorization omission, fix the assertion and add an invariant that catches the next omission. Keep the invariant honest about what it can and cannot prove.

Consider an administrative interface with a configuration card. The card appears only when the current viewer has a configuration permission. The destination page, however, asks only whether the viewer is signed in. Hiding the card changes what the viewer sees; it does not change what the route accepts.

The direct URL is the simplest counterexample. If the user knows or guesses it, the navigation filter is bypassed. A page-level policy is needed to decide whether that route may render for the viewer. The underlying API or command must make its own authorization decision as well. These checks serve different entry points, so one cannot stand in for the other.

In the inspected change, the page policies were added. One data endpoint already had a stricter authorization rule and kept it. The lesson is to review each boundary on its own terms: visible link, routed page, and operation.

Read assertions as product decisions

The surprising part was not that a page attribute was too broad. It was that tests explicitly expected that breadth. One assertion accepted the absence of a policy; another looked for a bare sign-in attribute. Those statements had made an implementation detail into a contract.

When correcting a test like this, start by naming the intended behaviour in plain language. For example: “This routed configuration page requires the configuration policy.” Then inspect the compiled authorization attribute and assert that policy. This makes the test follow the behaviour the framework will see, rather than a particular text fragment in a Razor file.

That specific test matters even if a broader scan exists. A scan can report that a policy is present, but a policy for an unrelated administrative task could still pass it. The page-specific assertion checks the narrower decision about which permission belongs there.

Turn the omission into an invariant

The change also added a structural test over routed administrative pages in two application areas. It checks whether each page asserts a permission policy. The test has a nonempty coverage guard, because a scan that accidentally finds zero pages is worse than a failing scan: it can look reassuring while doing nothing.

This is a useful pattern for requirements that should apply across a family of files. A single page test protects a known case. A route scan makes it harder for a new page to repeat the same omission. Neither test needs to simulate every user and role to answer the structural question, “Did this route declare a permission policy?”

The boundary of that answer is important. The scan does not prove that every declared policy is correct. It does not prove that an API rejects unauthorized calls. It does not prove that authorization is complete across the product. Those claims require different tests and review.

Make exceptions accountable

Some landing pages can legitimately be available to any signed-in viewer because their contents filter themselves by the viewer's permissions. A blanket rule that rejects every such page would create noise and encourage people to weaken the test. The committed scan therefore allows explicit exemptions with reasons.

An exemption is still a maintenance obligation. If a page is deleted, renamed, or later gains a policy, its old exemption should disappear. A second test checks for those stale entries. It keeps the exception list from becoming a historical catalogue that a future developer might mistake for permission to add more exceptions.

The two corrected pages are pinned separately. That matters because someone could otherwise make the broad scan green by putting a vulnerable page on the exemption list. The pinned tests say those particular pages must keep their policies and cannot be exempted.

The same change initially documented a separate unresolved permission decision as a known gap. A follow-up commit assigned that page a policy after an owner made the decision. Recording the gap first kept the review honest while the right policy was decided rather than guessed from a neighbouring page.

The practical review sequence

When a green test has protected the wrong rule, I use this sequence:

Reproduce the bypass at the relevant entry point in a controlled test or review, such as direct route access rather than clicking the navigation card.
State the intended permission and correct the local assertion so it checks the framework-visible attribute.
Add a structural invariant if the same omission can recur across many pages.
Give every real exception a reason, and make stale exceptions fail.
Keep page and operation authorization under separate review; presence of a page policy is only one piece of evidence.

This approach costs some test and exception-list maintenance. The benefit is a much earlier signal when another route omits a policy, while the specific assertions preserve the decisions that matter most. A green suite should mean that our intended boundary is holding, not merely that yesterday's implementation has stayed the same.

Pagination Is a Consistency Contract

Sun, 20 Sep 2026 07:52:36 +0000

Page numbers feel harmless. They are familiar, easy to render, and easy to explain. But on a mutable work queue, they can lie.

Imagine a reviewer reading a newest-first queue. They load the first 25 items. Before they request the next page, a new item arrives at the top. An offset such as skip 25 now starts one row later than it would have a moment ago. The last row from page one may appear again, and the row displaced by the insert may never appear in that walk.

Nothing crashed. No error was logged. The interface simply presented an inconsistent view of the work.

The engineering lesson is that pagination over changing data is a consistency contract, not a decorative control beneath a table.

Begin with the mutation model

The right pagination strategy depends on how the collection changes.

For an append-mostly queue ordered newest first, new work normally arrives above the operator's current position. Other fields, such as workflow status, may change while the operator is reviewing an item. Those two facts suggest a useful boundary: continue from something fixed when the item entered the queue, not from a mutable field and not from the current numeric position.

A submission timestamp can provide that boundary if it is frozen when the item is created. Status usually cannot; ordering by status lets a decision move rows between pages while someone is walking the list.

The principle is broader than timestamps: choose an ordering key whose meaning remains stable for the duration of a walk.

Make the server own the continuation

A client should not reconstruct position from a page number, a visible row, or a guessed offset. The server should return an opaque continuation and accept it unchanged on the next request.

For a newest-first queue, a continuation can describe the last timestamp boundary and how many rows at that exact instant have already been emitted. The next query includes rows at or below the boundary, skips only the already-seen ties at that boundary, and takes one extra row to determine whether another page exists.

Why count ties instead of comparing an identifier? Identifier ordering is not always portable across database providers. Let the query provider apply its established ordering, and record only how far through the boundary group the walk has progressed.

Opaque does not mean unchecked. Reject blank, malformed, oversized, or unsupported continuations. A bad continuation should not silently restart at the top, because a restart looks like valid data with unexplained duplicates.

Bind position to query context

A continuation names a position in one specific ordered result set. Change the filter and that position may no longer mean anything.

Suppose page one was filtered to one workflow cycle, then the same continuation was replayed with the filter removed. Honouring it could skip rows that were never part of the original walk. The continuation should therefore carry enough context to prove it belongs to the active query. If the context differs, refuse the request and let the client restart explicitly.

The same discipline applies to page size. Put a small upper bound in the contract and reject values outside it. Quietly shrinking an oversized request hides caller mistakes; accepting it defeats the point of paging.

Bounding the first query is only half the work. If each row needs evidence, comments, or another related record, fetch those details only for identifiers on the current page. Otherwise an apparently paged endpoint can still perform an unbounded secondary read.

Preserve the operator's place

Continuation cursors naturally move forward. A usable review screen also needs Back and refresh.

The client can keep a short trail of the server-provided continuations used to open each visited page. Previous then replays the cursor that originally opened the prior page. The client is not interpreting the cursor; it is remembering the path.

After a reviewer changes an item, refresh the page they are currently viewing. Returning to page one after every decision is technically simple and operationally punishing. It also encourages people to work around the interface rather than trust it.

There is one awkward edge case: a later page may become empty before it is refreshed. Do not render a global empty-state message that implies the entire queue has vanished. Reset to the first page and show the current truth from a valid starting position.

Test the walk, not only the query

Happy-path tests that assert “25 rows returned” are not enough. The important properties live between requests.

Useful executable checks include:

a new item arriving above the boundary neither duplicates nor hides an existing row;
a workflow status change does not alter page membership;
several items sharing one timestamp are neither repeated nor lost;
a continuation cannot be replayed with a different filter;
malformed continuations and invalid page sizes are refused;
forward and backward navigation use the exact server continuations;
a write refreshes the active page; and
an empty later page recovers without claiming the whole queue is empty.

These tests describe the contract more clearly than the word “paged” ever could.

The trade-off is explicit complexity

Cursor paging asks more of both sides. The server must define and validate a stable continuation. The client must retain a small history. Ties and disappearing pages need deliberate behaviour. Troubleshooting is less intuitive than looking at page=3 in a URL.

In return, database work stays bounded and a reviewer can walk a changing queue without silent duplicates or gaps. That is a worthwhile trade whenever missing one item matters more than keeping the paging code superficially simple.

Before choosing offsets for a mutable list, simulate one insert and one update between consecutive requests. If the same walk no longer produces the same set of rows, the pager needs a stronger contract.

Realtime Is a Hint, Not Your Source of Truth

Thu, 17 Sep 2026 08:20:15 +0000

A notification badge looks like a small feature. In a distributed application, it can expose a large architectural assumption.

I recently investigated a badge that sometimes stayed stale in an ASP.NET Core and Blazor application running across multiple server instances. The notification itself had been created successfully. Durable state was correct. A separate push path could also complete. Yet the visible count did not always change until the user left the screen and returned.

The bug was not really about arithmetic. It was about assigning too much authority to a realtime transport.

The hidden assumption

The UI initially loaded its count from the server and then relied on live events to remain current. That feels reasonable while developing against one server with a stable connection. In production, several ordinary conditions weaken the assumption:

The client can disconnect briefly.
A load balancer can place the sender and receiver on different instances.
A workflow can create the same durable state without passing through the page that happens to broadcast.
A transport or hub can fail after the database operation has already succeeded.
An idempotent retry can revisit work that should not increment the UI again.

None of these conditions makes realtime technology a poor choice. They simply mean that a realtime message should usually be treated as a hint that fresh state is available, not as the state itself.

A three-layer reliability pattern

The repair became much clearer once the responsibilities were separated into three layers.

First, persist the truth

The durable record must be committed independently of whether any connected client is listening. If the user closes the app, changes networks, or connects to another instance, the correct unread state must still be recoverable later.

This ordering matters. Broadcasting first can produce a convincing UI update for data that subsequently fails to commit. Persisting first means a missed broadcast can be healed; an invented broadcast cannot be trusted.

Second, broadcast from the business chokepoint

The live update originally depended on a narrower UI workflow. Other creation paths could produce the same durable result without emitting the event. Moving the broadcast to the shared dispatch path made the behavior consistent across interactive and background work.

The broadcast was also tied to the outcome of the durable write. A genuinely new record emits a hint. An idempotent replay that finds the work already completed does not. That prevents duplicate increments and makes the event reflect a real state transition rather than merely an attempted command.

Third, reconcile periodically

Even a correctly placed broadcast can be missed. The client therefore refreshes the authoritative count on a bounded interval. The loop is cancelled when the component is disposed, and a transient refresh failure does not kill future attempts.

This is not polling as the primary experience. Realtime still gives the fast path. Polling is the repair path.

The trade-off

Hybrid delivery is not free.

Periodic reconciliation adds read traffic. The interval also defines a maximum period of visible staleness when a realtime event is missed. A very short interval increases load and can waste battery or bandwidth on mobile clients. A long interval lowers cost but leaves stale UI visible for longer.

That makes the interval a product and operational decision, not a magic constant. Ask how damaging stale information is, how expensive the read is, how many active clients exist, and whether the endpoint can use a cheap aggregate or cache.

For a badge, bounded staleness may be acceptable. For a payment confirmation or permission change, the interaction may require an immediate authoritative read instead. The pattern stays the same, but the recovery budget changes.

Failure boundaries matter too. Once durable work has succeeded, a hub failure should not turn the whole operation into a failure. Otherwise a temporary transport problem can encourage retries of already-completed business work. Log the broadcast failure, observe it, and let reconciliation repair the presentation.

Test the contract, not the transport

The most useful tests were not attempts to prove that a network never fails. They pinned the business boundary:

New durable state produces one realtime hint.
Previously completed or deduplicated work produces no new hint.
A failing realtime transport does not invalidate successful durable work.

Client-side tests can add the complementary guarantees: an initial authoritative load occurs, the reconciliation loop refreshes state, transient errors do not stop later ticks, and disposal cancels the loop.

These tests document the intended hierarchy. The database-backed read is authoritative. Realtime reduces latency. Reconciliation restores convergence.

A practical review checklist

When reviewing a live-update feature, I now ask five questions:

What is the source of truth?
Where is the single shared point that knows a real state transition occurred?
Can the live event be safely missed or duplicated?
How and how quickly does the client converge again?
What happens if the transport fails after the business operation succeeds?

If those answers are vague, the feature may look realtime in a demo while remaining fragile in production.

The broader lesson is modest: reliability often comes from combining mechanisms with explicit roles. Durable storage provides truth. Realtime provides speed. Periodic reconciliation provides healing. None needs to pretend it can do the others’ job.

That separation made a small badge easier to trust, and it is a pattern I would reuse for dashboards, counters, presence indicators, job progress, and other derived UI state.

Blazor Latest Features

Tue, 19 May 2026 08:11:04 +0000

Blazor Latest Features

Blazor, Microsoft’s modern web UI framework, has evolved significantly in recent releases (.NET 8 and .NET 9). It now provides a powerful mix of full-stack capabilities, flexible rendering, and high performance, making it a strong alternative to JavaScript-based frameworks.

1. Unified Full-Stack Blazor

With .NET 8, Blazor became a full-stack framework that unifies server and client rendering within a single project.

Supported rendering models:

Static Server-Side Rendering (SSR)
Interactive Server
Interactive WebAssembly
Interactive Auto (hybrid)

Developers can now choose the best rendering strategy per component, improving both performance and flexibility.

⚙️ 2. Advanced Rendering Modes

Blazor introduces powerful rendering options:

Static SSR → Fast HTML, SEO-friendly
Interactive Server → Real-time updates via SignalR
Interactive WebAssembly → Runs fully in the browser
Auto Mode → Switches dynamically between server and client

✅ This enables hybrid applications where static content and interactive UI coexist seamlessly.

⚡ 3. Streaming Rendering

Blazor supports streaming SSR, allowing content to be delivered progressively while data loads.

Benefits:

Faster perceived load time
Better user experience for data-heavy apps
Improved responsiveness

4. Performance Improvements

Recent versions include major performance enhancements:

Faster startup times (WebAssembly optimizations)
Smaller application bundles
Improved rendering efficiency
Optimized static file delivery

Result: faster apps and better scalability

5. New Blazor Web App Template

The new unified template simplifies development:

Single project structure
Built-in rendering configuration
Reduced setup complexity

✅ Ideal for modern full-stack applications.

6. Better Developer Experience

Blazor now includes:

Constructor-based dependency injection
Improved debugging and diagnostics
Simplified authentication handling
Cleaner component architecture

Makes development faster and more maintainable.

7. Improved Interactivity

Enhancements in .NET 9:

Better reconnection handling
Improved routing and navigation
Enhanced state management

✅ Applications are more stable and responsive.

8. Cross-Platform & Hybrid Apps

Blazor integrates with .NET MAUI, allowing apps to run on:

Web
Desktop
Mobile

One codebase across multiple platforms.

9. Blazor UI Component Libraries

Blazor’s ecosystem includes powerful UI libraries that accelerate development.

MudBlazor (Open Source)

A popular Material Design component library.

Features:

Modern UI components (DataGrid, Dialogs, Forms)
Pure C# (minimal JavaScript)
Easy setup
Open-source

✅ Best for:

Dashboards
Admin panels
Rapid development

Syncfusion Blazor

Enterprise-grade UI component suite.

Features:

80+ components (Grid, Charts, Scheduler, etc.)
High-performance data handling
Built-in AI-enhanced components
Excellent documentation

✅ Best for:

Enterprise apps
Data-intensive dashboards
Reporting systems

DevExpress Blazor

Professional enterprise UI library.

Features:

Advanced DataGrid and TreeList
Reporting tools
High performance
Accessibility improvements

✅ Best for:

Large-scale business applications
Complex data visualization

✅ Conclusion

Blazor has evolved into a modern, enterprise-ready full-stack framework.

Key strengths:

✅ Flexible rendering (SSR + WASM)
✅ Strong performance improvements
✅ Simplified developer experience
✅ Rich UI component ecosystem

With libraries like MudBlazor, Syncfusion, and DevExpress, developers can build powerful applications faster than ever.

Building a Clean Master-Detail App with Blazor Server, MudBlazor, and EF Core

Thu, 26 Mar 2026 11:08:58 +0000

Building a Clean Master-Detail App with Blazor Server, MudBlazor, and EF Core

When building business applications, one of the most common requirements is a master-detail workflow. Orders and order items are a perfect example.

You need a clean list view, a reliable detail page, inline editing, validation, filtering, and a structure that can grow without becoming messy.

That is exactly what BlazorOrderApp is designed to demonstrate.

This application is a production-ready Blazor Server solution built with MudBlazor for the UI, EF Core with SQL Server for persistence, and a clean architecture that separates concerns across Domain, Application, Infrastructure, and Web layers.

Instead of placing everything in pages or code-behind files, the app keeps business rules, data access, validation, and UI responsibilities clearly divided.

At the core of the app is a classic master-detail pattern. The Orders.razor page acts as the master list, giving users filtering, search, pagination, and a structured overview of all orders. The OrderDetail.razor page handles the detail side, where users can inspect customer information, manage order items, and update order status in a focused way.

A big strength of this project is its use of the Repository and Specification patterns. The repository layer keeps EF Core logic centralized and testable, while specifications allow queries to be defined as reusable objects instead of scattered LINQ expressions. This makes filtering, paging, and retrieving complex data much easier to maintain over time.

Validation is handled with FluentValidation, which keeps rules explicit and easy to evolve as business needs grow. Combined with MudBlazor dialogs for create, edit, and delete operations, the result is a workflow that feels polished and user-friendly without sacrificing structure behind the scenes.

Overall, BlazorOrderApp is a strong example of how to build a modern internal business application in Blazor. It shows that you can create a clean, scalable CRUD system with a professional UI, solid architecture, and maintainable backend patterns, all within the .NET ecosystem.

Source code : https://github.com/stevsharp/BlazorOrderApp

Building a Blazor Form with the Command Pattern and Undo

Fri, 20 Mar 2026 08:35:01 +0000

Building a Blazor Form with the Command Pattern and Undo

In a typical Blazor form, inputs update the model directly. That is simple and works fine for basic CRUD screens, but it starts to feel limiting when you want more control over how changes happen, especially if you want undo support.

That is where the Command Pattern becomes useful.

Instead of letting the form change the model directly, each meaningful edit is wrapped inside a command object. That command is responsible for two things: applying the change and reversing it later if the user clicks Undo.

In other words, the form is no longer just changing values. It is recording actions.

The basic idea

In this approach, every field change becomes its own small object.

So if the user changes FirstName, that is one command.
If they change Email, that is another command.
If they toggle IsActive, that is a third command.

Those commands are stored in a stack, and Undo simply reverses the most recent one.

The core interface is very small:

public interface IUndoableCommand
{
    string Name { get; }
    void Execute();
    void Undo();
}

This keeps the pattern easy to understand. Every command knows what it does, and how to undo it.

The undo manager

To store the history of changes, we use a simple UndoManager:

public sealed class UndoManager
{
    private readonly Stack<IUndoableCommand> _undoStack = new();

    public bool CanUndo => _undoStack.Count > 0;

    public void Execute(IUndoableCommand command)
    {
        command.Execute();
        _undoStack.Push(command);
    }

    public void Undo()
    {
        if (_undoStack.Count == 0)
            return;

        var command = _undoStack.Pop();
        command.Undo();
    }

    public void Clear()
    {
        _undoStack.Clear();
    }
}

The idea is straightforward. When a command runs, it is pushed onto the stack. When the user clicks Undo, the last command is popped and reversed.

A reusable command for field changes

For a form, a generic SetPropertyCommand<TModel, TValue> is often enough to get started.

public sealed class SetPropertyCommand<TModel, TValue> : IUndoableCommand
{
    private readonly TModel _model;
    private readonly Func<TModel, TValue> _getter;
    private readonly Action<TModel, TValue> _setter;
    private readonly TValue _newValue;

    private TValue? _oldValue;
    private bool _captured;

    public string Name { get; }

    public SetPropertyCommand(
        string name,
        TModel model,
        Func<TModel, TValue> getter,
        Action<TModel, TValue> setter,
        TValue newValue)
    {
        Name = name;
        _model = model;
        _getter = getter;
        _setter = setter;
        _newValue = newValue;
    }

    public void Execute()
    {
        if (!_captured)
        {
            _oldValue = _getter(_model);
            _captured = true;
        }

        _setter(_model, _newValue);
    }

    public void Undo()
    {
        if (!_captured)
            return;

        _setter(_model, _oldValue!);
    }
}

What makes this useful is that it does not permanently track the whole form. It only represents one change at a time.

That is an important distinction.

SetPropertyCommand is not a background tracker watching every field. It is more like a history entry. One command instance represents one action, like:

change FirstName from "Maria" to "Anna"

change Email from "Emails are not allowed" to "Emails are not allowed"

change IsActive from false to true

Example from the form

In the Blazor form, a field change is turned into a command like this:

ExecutePropertyCommand(
    "Change First Name",
    m => m.FirstName,
    (m, v) => m.FirstName = v,
    value ?? string.Empty,
    nameof(CustomerEditModel.FirstName));

This is a nice example because it shows exactly what the command needs:

how to read the property
how to set the property
what the new value is
which field changed

Then inside ExecutePropertyCommand, the actual command is created:

var command = new SetPropertyCommand<CustomerEditModel, TValue>(
    name,
    _model,
    getter,
    setter,
    newValue);

And then executed through the undo manager:

_undoManager.Execute(command);

Why this feels cleaner

This approach separates form editing from raw property assignment.

Without the pattern, a form usually does this:

_model.FirstName = value;

That works, but the change is gone the moment it happens. There is no history, no reversible action, and no good place to add undo logic later.

With the Command Pattern, the change becomes a first-class action. That makes the form behavior more predictable, easier to test, and easier to extend.

Why Save should stay separate

One important design choice is keeping Save outside the command stack.

Undo should reverse form edits, not database persistence.

That is why Save is better as a separate action:

private Task SaveAsync()
{
    ValidateModel();

    if (!_editContext.Validate())
        return Task.CompletedTask;

    // persist here

    _undoManager.Clear();
    RefreshPreview();

    return Task.CompletedTask;

This keeps responsibilities clear:

commands handle reversible UI changes

Save persists the current state

Trying to make Save itself a command usually creates confusion, because undoing a database write is a completely different problem.

A good fit for Blazor forms

This pattern is especially useful when a form has:

multiple editable fields
toggles or switches
add/remove actions
sections that can be reset
a real requirement for undo

The Command Pattern gives you a clean way to implement it without scattering logic all over the component.

Final thought

The most helpful way to think about this is not that the command is “tracking fields.” It is not.

What it is really doing is turning every meaningful edit into a small object that remembers what changed, so the form can step backward when needed.

That is what makes undo possible, and that is what makes the pattern useful in a Blazor form.

Source Code : https://github.com/stevsharp/BlazorCommandLab

When IDbContextFactory enters the chat, and what it actually fixes.

Mon, 16 Feb 2026 09:47:23 +0000

When `IDbContextFactory` enters the chat, and what it actually fixes

Most EF Core examples use a scoped DbContext. In a normal Web API request, that’s fine, the request ends, the context is disposed.

Then you build Blazor Server.

A Blazor Server circuit can stay alive for a long time, minutes or hours. If your DbContext is scoped, it can also stay alive that long. That’s when things start to break in annoying ways.

What problems show up

1) “A second operation was started on this context…”
DbContext is not thread-safe. In Blazor Server it’s easy to trigger overlapping work (clicks, timers, loading states). If two queries happen at the same time on the same context, you get this error.

2) Tracking bloat
A long-lived context keeps tracking entities. Over time:

memory grows
queries can feel slower
SaveChanges can get heavy
you hit “already being tracked” errors

3) Stale or confusing data
Because the context tracks objects, you can end up reusing old instances without realizing it, the UI feels out of sync.

What `IDbContextFactory` changes

It gives you a fresh DbContext per operation.

create context
run the query or command
dispose the context

So each click, each load, each action gets its own clean context. No shared state, no concurrency fights, no growing tracker.

When to use it

Use IDbContextFactory when you have:

Blazor Server
background jobs or hosted services
timers, polling, signalR style event flows
any parallel DB work

In simple controller-per-request apps, scoped DbContext is still perfectly fine.

The takeaway

IDbContextFactory is not a “nice to have”, it’s the safer default when your app is long-lived and event-driven. It prevents a whole category of EF Core bugs before they happen.

Source Code :

https://github.com/stevsharp/BlazorFactoryDemo

Creating a Syncfusion MultiSelect Component with Two-Way Binding in Blazor

Tue, 29 Jul 2025 08:55:27 +0000

In this example, we build a reusable Blazor component using Syncfusion’s SfMultiSelect that supports:

Dynamic option filtering based on a Picklist type (e.g., Color, Unit)

Two-way data binding with a parent component

Internal state management to avoid unnecessary updates

Why This Pattern?

Often in enterprise forms, you need a dynamic dropdown that updates based on a type and preselects values passed from a parent. This setup ensures:

Clean encapsulation

Correct @bind support

Lightweight rendering

✅ Component Markup

<SfMultiSelect TValue="List<PicklistSetDto>"
               TItem="PicklistSetDto"
               Placeholder="@Label"
               DataSource="@Options"
               @bind-Value="InternalSelectedValues"
               Mode="VisualMode.Box"
               AllowFiltering="true"
               FilterType="FilterType.Contains"
               PopupHeight="300px">
    <MultiSelectFieldSettings Text="Text" Value="Value" />
</SfMultiSelect>

Component Logic

@code {
    [Parameter]
    public string Label { get; set; } = "Select Options";

    [Parameter]
    public Picklist Name { get; set; }

    [Parameter]
    public IEnumerable<PicklistSetDto> SelectedValues { get; set; } = new List<PicklistSetDto>();

    [Parameter]
    public EventCallback<IEnumerable<PicklistSetDto>> SelectedValuesChanged { get; set; }

    protected List<PicklistSetDto> Options = new();

    private List<PicklistSetDto> _internalSelectedValues = new();

    private List<PicklistSetDto> InternalSelectedValues
    {
        get => _internalSelectedValues;
        set
        {
            if (!_internalSelectedValues.SequenceEqual(value ?? new()))
            {
                _internalSelectedValues = value ?? new();
                SelectedValuesChanged.InvokeAsync(_internalSelectedValues);
            }
        }
    }

    protected override async Task OnInitializedAsync()
    {
        Options = await Task.FromResult(PicklistService.DataSource
            .Where(x => x.Name == Name)
            .ToList());
    }

    public override async Task SetParametersAsync(ParameterView parameters)
    {
        await base.SetParametersAsync(parameters);

        InternalSelectedValues = Options
            .Where(x => SelectedValues.Any(s => s.Value == x.Value))
            .ToList();
    }
}

Example Usage in Parent Component

<PicklistMultiSelect Label="Select Colors"
                     Name="Picklist.Color"
                     SelectedValues="@colorData"
                     SelectedValuesChanged="OnColorChanged" />

private List<PicklistSetDto> colorData = new();
private void OnColorChanged(IEnumerable<PicklistSetDto> values)
{
    colorData = values.ToList();
}

To efficiently handle large datasets in Syncfusion’s SfMultiSelect in Blazor, you should avoid loading the entire dataset into memory and instead use server-side filtering and paging. Here's how to implement it:

<SfMultiSelect TValue="List<PicklistSetDto>"
               TItem="PicklistSetDto"
               @ref="multiObj"
               Placeholder="@Label"
               @bind-Value="InternalSelectedValues"
               AllowFiltering="true"
               EnableVirtualization="true"
               PopupHeight="300px"
               Filtering="OnFilter">
    <MultiSelectFieldSettings Text="Text" Value="Value" />
</SfMultiSelect>

⚠ EnableVirtualization="true" improves rendering performance but requires paging logic in OnFilter.

✅ 2. Implement OnFilter with Server-Side Querying
Replace your in-memory filter with actual server-side filtering:

✅ 1. Enable Virtualization

private async Task OnFilter(FilteringEventArgs args)
{
    args.PreventDefaultAction = true;

    // Server-side call (adjust as needed)
    var filtered = await PicklistService.GetFilteredAsync(Name, args.Text);

    await multiObj.FilterAsync(filtered, new Query());
}

✅ 3. Modify Your Service to Support Filtering and Paging

public async Task<List<PicklistSetDto>> GetFilteredAsync(Picklist name, string? filter)
{
    using var context = _dbContextFactory.CreateDbContext();

    var query = context.PicklistSets
        .Where(p => p.Name == name);

    if (!string.IsNullOrWhiteSpace(filter))
        query = query.Where(p => p.Text.Contains(filter));

    return await query
        .OrderBy(p => p.Text)
        .Take(100) // Limit for performance
        .Select(p => new PicklistSetDto
        {
            Value = p.Value,
            Text = p.Text,
            Name = p.Name
        })
        .ToListAsync();
}

✅ 4. Optional – Add Debounce to Reduce API Calls

This delays filtering execution until the user stops typing, avoiding too many API hits.

DebounceDelay="300"

Why Use Syncfusion in Blazor?
Syncfusion’s Blazor UI components offer a wide range of benefits for modern web apps. Here’s why it’s a great choice for developers:

✅ 1. Rich Component Library
Syncfusion provides 80+ production-ready components, including:

SfGrid, SfMultiSelect, SfDatePicker, SfDialog, SfChart, and more

Covers everything from data entry to dashboards

⚡ 2. Performance Optimized
Built-in virtualization and lazy loading

Handles large datasets smoothly (e.g., thousands of records in a Grid)

Consistent UI/UX
Beautiful, modern design out of the box

Theme support: Fluent, Bootstrap5, Material, Tailwind, or your custom styles

Developer Productivity
Intuitive APIs that follow Blazor standards (@bind-Value, DataSource, events)

Extensive documentation and real-world samples

Native Blazor — not just JS interop wrappers

Enterprise-Ready Features

Built-in support for localization, accessibility (WCAG 2.0), and RTL

Works seamlessly with validation frameworks like FluentValidation

Excellent Integration with Modern Blazor Patterns

Compatible with @inject, CascadingParameter, and EventCallback

MVVM-friendly (e.g., CommunityToolkit.MVVM)

Supports reactive forms and dynamic configuration

Strong Commercial Support

Regular updates and new feature rollouts

Dedicated support via forums and ticket system

Source code access included in paid plans

State Management Made Easy with Fluxor in Blazor

Fri, 25 Apr 2025 12:59:35 +0000

Exploring Actions, Effects, and the Benefits of Fluxor

Modern web applications are becoming increasingly complex, and with complexity comes the need for structured state management. In the world of Blazor a popular .NET-based web UI framework .

Fluxor offers a powerful yet easy-to-understand state container that brings predictable state flow to your applications.

Fluxor is a zero-boilerplate Flux/Redux library for Microsoft .NET.

It brings the same clean architecture and unidirectional data flow popularized by Redux in the JavaScript ecosystem—adapted for C# developers building with Blazor.

We’ll break down the core concepts of Fluxor and show how you can use Actions, Reducers, and Effects to create a clean, maintainable architecture.

Explore the GitHub project

️ What is Fluxor?

Fluxor provides a structured and predictable way to manage state in your Blazor application. Inspired by Redux, it embraces:

Unidirectional data flow — State changes follow a clear path: Action ➝ Reducer ➝ State ➝ UI.

Single source of truth — All application state lives in a centralized, immutable store.

Middleware & Effects — Separate side-effects like API calls from your UI and business logic.

Unlike some Redux implementations, Fluxor handles a lot of the boilerplate for you with C#-friendly conventions and strong typing.

Actions – Declaring Intent

In both Redux and Fluxor, Actions are plain messages that describe what happened. They're just
signals , they don’t contain logic.

Example:

public record FetchItemsAction;
public record FetchItemsSuccessAction(List<Item> Items);
public record FetchItemsFailedAction(string ErrorMessage);

⚙️ Effects – Handling Side Effects

Since Reducers must be pure, Effects in Fluxor allow you to perform async operations like API calls without cluttering your UI.

Example:

public class ItemEffects
{
    [EffectMethod]
    public async Task HandleFetchItems(FetchItemsAction action, IDispatcher dispatcher)
    {
        try
        {
            var items = await itemService.GetItemsAsync();
            dispatcher.Dispatch(new FetchItemsSuccessAction(items));
        }
        catch (Exception ex)
        {
            dispatcher.Dispatch(new FetchItemsFailedAction(ex.Message));
        }
    }
}

This Effect reacts to FetchItemsAction and handles fetching data from an external service.

State and Reducers – Updating the Store

Reducers are responsible for updating state in response to actions. They are pure functions and return a new state based on the action received.

public static class ItemReducers
{
    [ReducerMethod]
    public static ItemState OnFetchSuccess(ItemState state, FetchItemsSuccessAction action) =>
        state with { Items = action.Items, IsLoading = false };

    [ReducerMethod]
    public static ItemState OnFetchFailed(ItemState state, FetchItemsFailedAction action) =>
        state with { ErrorMessage = action.ErrorMessage, IsLoading = false };
}

Reducers never mutate state—they return a new state object.

Try It Yourself

Check out the working example project to see all these concepts in action:
https://github.com/stevsharp/BlazorAndFluxorStateMachine

It demonstrates:

Dispatching Actions from UI
Handling async logic with Effects
Clean Reducer logic
Blazor component integration

✅ Why Use Fluxor?

No boilerplate overload – clean C# syntax
Clear, testable state transitions
Great for scaling large Blazor apps
Familiar to those who’ve used Redux in React or Angular
Keeps business logic and UI concerns separate

References

Fluxor GitHub Repository

Redux Official Site

Angular Redux

Blazor Documentation – Microsoft

BlazorAndFluxorStateMachine – GitHub Sample

List item

How to Bind a MudSelect from an External Source in Blazor Using MudBlazor

Thu, 10 Apr 2025 09:15:42 +0000

Blazor is a modern framework from Microsoft that allows you to build interactive web applications using C# and .NET, both on the server and the client, without needing JavaScript. It brings the full power of .NET to the browser via WebAssembly or server-side rendering.

MudBlazor is a popular UI component library built specifically for Blazor. It offers clean, responsive components following Google's Material Design system, making it incredibly easy to create modern, beautiful, and interactive web UIs entirely in C#.

Use Case

Let’s say you need to:

Display a multi-select dropdown

Load the options from an external service

Sync selected values with the parent component

Reuse this logic throughout your application

We'll walk through a real-world pattern using MudSelect, bound to a list of brands (dtoBrands) provided by a service.

Prerequisites

A Blazor project with MudBlazor installed

A service that returns the brand data
A DTO like:

public class BrandDto
{
    public string Text { get; set; }
    public string Value { get; set; }
}

Sample Service Interface

public interface IBrandService
{
    Task<IEnumerable<BrandDto>> GetBrandsAsync();
}

The MudSelect Markup

<MudSelect T="BrandDto"
           Label="@Label"
           MultiSelection="true"
           Clearable="true"
           @bind-SelectedValues="InternalSelectedValues"
           ToStringFunc="item => item.Text">
    @if (dtoBrands.Any())
    {
        @foreach (var item in dtoBrands)
        {
            <MudSelectItem T="BrandDto" Value="item">
                @item.Text
            </MudSelectItem>
        }
    }
</MudSelect>

⚙️ Component Logic

@inject IBrandService BrandService

@code {
    [Parameter]
    public string Label { get; set; } = "Select Brands";

    [Parameter]
    public IEnumerable<BrandDto> SelectedValues { get; set; } = new HashSet<BrandDto>();

    [Parameter]
    public EventCallback<IEnumerable<BrandDto>> SelectedValuesChanged { get; set; }

    protected IEnumerable<BrandDto> dtoBrands = new List<BrandDto>();

    private IEnumerable<BrandDto> _internalSelectedValues = new HashSet<BrandDto>();

    private IEnumerable<BrandDto> InternalSelectedValues
    {
        get => _internalSelectedValues;
        set
        {
            if (_internalSelectedValues != value)
            {
                _internalSelectedValues = value;
                SelectedValuesChanged.InvokeAsync(_internalSelectedValues);
            }
        }
    }

    protected override async Task OnInitializedAsync()
    {
        dtoBrands = await BrandService.GetBrandsAsync();

        _internalSelectedValues = new HashSet<BrandDto>(
            dtoBrands.Where(x => SelectedValues.Any(s => s.Value == x.Value))
        );
    }

    public override async Task SetParametersAsync(ParameterView parameters)
    {
        await base.SetParametersAsync(parameters);

        _internalSelectedValues = new HashSet<BrandDto>(
            dtoBrands.Where(x => SelectedValues.Any(s => s.Value == x.Value))
        );
    }
}

How It Works

♻️ Example Usage

Imagine turning this into a reusable component, like BrandSelector.razor. You’d use it like this:

<BrandSelector Label="Choose Brands"
               SelectedValues="@selectedBrands"
               SelectedValuesChanged="@OnSelectedBrandsChanged" />

Why This Pattern Rocks

By combining Blazor's powerful component model with MudBlazor's modern UI toolkit, you get:

✅ Fully data-driven dropdowns

✅ Type-safe C# components

✅ No need for JavaScript

✅ A consistent look and feel

And all of it is maintainable and testable across large-scale apps.

✅ Final Thoughts

Blazor and MudBlazor are a dream combo for building modern web apps in C#. By binding a MudSelect to an external service, you're creating a highly flexible and reusable pattern that fits beautifully in a clean architecture.

Useful Links

Blazor documentation

MudBlazor official site

MudSelect documentation

A Comprehensive Guide to Building Web Applications with Blazor

Sat, 15 Mar 2025 01:05:51 +0000

Blazor is a powerful framework from Microsoft that allows you to build interactive web applications using C# and .NET. It leverages WebAssembly to run .NET code directly in the browser, offering a rich development experience similar to frameworks like Angular or React. This guide will take you through the process of building a Blazor application, step by step, with examples of API consumption and component interactions.

Table of Contents
Introduction to Blazor
Setting Up Your Blazor Project
Creating Components in Blazor
Data Binding and Event Handling
Consuming APIs in Blazor
Component Interactions
Differences with ReactJS and NextJS
Deploying Your Blazor Application
Conclusion

Introduction to Blazor
Blazor comes in two flavors:

Blazor WebAssembly (WASM): Runs in the browser via WebAssembly.
Blazor Server: Runs on the server and uses SignalR to update the client.
In this guide, we’ll focus on Blazor WebAssembly, but many concepts apply to Blazor Server as well.

Setting Up Your Blazor Project
First, ensure you have the .NET SDK installed. You can download it from Microsoft’s official site.

Create a new Blazor WebAssembly project using the following command:

dotnet new blazorwasm -o BlazorApp
cd BlazorApp

Next, open the project in your preferred IDE (Visual Studio, Visual Studio Code, etc.).

Creating Components in Blazor
Components are the building blocks of a Blazor application. They are .razor files and can include HTML, C#, and Razor syntax.

Create a new component named Counter.razor:

@page "/counter"
@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

<h3>Counter</h3>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

This simple component includes a button that increments a counter.

Data Binding and Event Handling
Blazor supports both one-way and two-way data binding. Here’s an example of a component with two-way data binding:

Create a new component named DataBindingExample.razor:

@page "/databinding"
@code {
    private string name = "";

    private void HandleSubmit()
    {
        Console.WriteLine($"Hello, {name}!");
    }
}

<h3>Data Binding Example</h3>

<input @bind="name" placeholder="Enter your name" />
<button class="btn btn-primary" @onclick="HandleSubmit">Submit</button>

<p>You entered: @name</p>

Consuming APIs in Blazor
Blazor can consume APIs using HttpClient. First, configure HttpClient in Program.cs:

   builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });

Next, create a service to fetch data. Create a new folder Services and add a file WeatherService.cs:

    using System.Net.Http;
    using System.Net.Http.Json;
    using System.Threading.Tasks;
    
    public class WeatherService
    {
        private readonly HttpClient _httpClient;
    
        public WeatherService(HttpClient httpClient)
        {
            _httpClient = httpClient;
        }
    
        public async Task<WeatherForecast[]> GetWeatherForecasts()
        {
            return await _httpClient.GetFromJsonAsync<WeatherForecast[]>("sample-data/weather.json");
        }
    }

Register the service in Program.cs:

    builder.Services.AddScoped<WeatherService>();
    Create a WeatherForecast.razor component to display the data:
    
    @page "/weather"
    @inject WeatherService WeatherService
    
    @code {
        private WeatherForecast[] forecasts;
    
        protected override async Task OnInitializedAsync()
        {
            forecasts = await WeatherService.GetWeatherForecasts();
        }
    }
    
    <h3>Weather forecast</h3>
    
    @if (forecasts == null)
    {
        <p><em>Loading...</em></p>
    }
    else
    {
        <table class="table">
            <thead>
                <tr>
                    <th>Date</th>
                    <th>Temperature (C)</th>
                    <th>Summary</th>
                </tr>
            </thead>
            <tbody>
                @foreach (var forecast in forecasts)
                {
                    <tr>
                        <td>@forecast.Date.ToShortDateString()</td>
                        <td>@forecast.TemperatureC</td>
                        <td>@forecast.Summary</td>
                    </tr>
                }
            </tbody>
        </table>
    }

Component Interactions
Components can interact with each other using parameters and cascading values.

Create a parent component ParentComponent.razor:

@page "/parent"
@code {
    private string parentMessage = "Message from Parent";
}

<h3>Parent Component</h3>

<p>Parent's message: @parentMessage</p>

<ChildComponent MessageFromParent="@parentMessage" />
Create a child component ChildComponent.razor:

@code {
    [Parameter]
    public string MessageFromParent { get; set; }
}

<h3>Child Component</h3>

<p>Received message: @MessageFromParent</p>

Differences with ReactJS and NextJS
Blazor, ReactJS, and NextJS are all popular frameworks for building modern web applications, but they have distinct differences. This section delves deeper into their core aspects to help you understand which one might be the best fit for your needs.

Language and Ecosystem
Blazor

Language: Blazor uses C# for both client-side and server-side logic. This is beneficial for developers who are already familiar with the .NET ecosystem.
Ecosystem: It integrates seamlessly with the .NET ecosystem, including libraries and tools like Entity Framework, ASP.NET Core, and Azure services. The .NET ecosystem is mature and provides robust support for enterprise-level applications.
Advantages: Uniform language for both front-end and back-end, strong typing with C#, rich tooling support in Visual Studio.
ReactJS

Language: React uses JavaScript, the most popular language for web development. TypeScript, a superset of JavaScript, is also commonly used to provide static typing.
Ecosystem: React has a vast ecosystem with countless libraries for state management (Redux, MobX), routing (React Router), and UI components (Material-UI, Ant Design). The React community is very active, providing extensive resources and third-party libraries.
Advantages: Extensive library support, large community, flexibility in choosing tools and libraries, high performance due to the virtual DOM.
NextJS

Language: Next.js, built on React, also uses JavaScript or TypeScript.
Ecosystem: Next.js enhances React with features like server-side rendering (SSR) and static site generation (SSG). It simplifies deployment and scaling through its close integration with Vercel, the platform that maintains Next.js.
Advantages: Built-in SSR and SSG, API routes for serverless functions, zero-config deployment, improved SEO and performance.
Performance
Blazor WebAssembly

Performance: Runs .NET code directly in the browser via WebAssembly, providing a near-native performance once the application is loaded. The initial load time can be higher due to the size of the .NET runtime that needs to be downloaded.
Optimization: Techniques like ahead-of-time (AOT) compilation and tree shaking are used to optimize performance.
ReactJS

Performance: React’s virtual DOM diffing algorithm efficiently updates the UI. The performance is generally high but can vary based on how the application is implemented.
Optimization: Code splitting, lazy loading, and memoization are commonly used to enhance performance in React applications.
NextJS

Performance: Next.js excels in performance with its built-in features for SSR and SSG, which ensure faster initial page loads and better SEO. It also supports incremental static regeneration, allowing pages to be updated after the build process.
Optimization: Automatic code splitting, image optimization, and caching strategies contribute to Next.js’s performance.
Development Experience
Blazor

Development Experience: Offers a familiar development experience for .NET developers with features like dependency injection, a component-based architecture, and comprehensive tooling in Visual Studio.
Tooling: Strong integration with Visual Studio, including debugging, IntelliSense, and project templates.
Learning Curve: Easier for developers already familiar with C# and .NET.
ReactJS

Development Experience: Highly flexible and modular. Developers can choose from a wide range of libraries and tools to set up their development environment.
Tooling: Supported by tools like Create React App for project scaffolding, React DevTools for debugging, and extensive support in VS Code.
Learning Curve: Requires learning JavaScript/TypeScript and React concepts like JSX, hooks, and state management.
NextJS

Development Experience: Streamlined development with out-of-the-box support for SSR, SSG, and API routes. Provides a simplified setup and configuration process.
Tooling: Excellent integration with Vercel for deployment and scalability, and built-in development server with hot module replacement.
Learning Curve: Easier for developers familiar with React, but requires understanding of SSR/SSG concepts.
Deployment
Blazor

Deployment: Can be deployed as static files to any static web host, such as GitHub Pages, Azure Static Web Apps, or AWS S3. Blazor Server apps can be deployed to any server that supports .NET.
CI/CD: Integrates with Azure DevOps, GitHub Actions, and other CI/CD tools for automated deployments.
ReactJS

Deployment: Typically deployed as static files to services like Vercel, Netlify, or traditional web servers. Can also be integrated with server-side frameworks like Express.js for more complex deployments.
CI/CD: Supported by various CI/CD platforms, including GitHub Actions, Travis CI, and CircleCI.
NextJS

Deployment: Optimized for deployment on Vercel, which supports both static and dynamic content seamlessly. Can also be deployed to other platforms like Netlify, AWS, or traditional servers.
CI/CD: Vercel provides seamless CI/CD integration, automatically deploying updates when code is pushed to the repository.
Community and Support
Blazor

Community: Growing community with strong backing from Microsoft. Resources include official documentation, Microsoft Learn, and community forums.
Support: Enterprise-level support available from Microsoft, along with various third-party support options.
ReactJS

Community: Massive and active community with numerous resources, tutorials, courses, and third-party libraries. Strong backing from Facebook.
Support: Community-driven support with extensive online resources, plus commercial support available from various vendors.
NextJS

Community: Rapidly growing community with strong backing from Vercel. Extensive documentation and tutorials are available.
Support: Commercial support from Vercel, along with community-driven support and resources.

Deploying Your Blazor Application
To deploy your Blazor WebAssembly application, publish it using the following command:

dotnet publish -c Release

This command creates a dist folder in your project, which you can deploy to any static file host such as GitHub Pages, Azure Static Web Apps, or AWS S3.

Conclusion
Choosing between Blazor, ReactJS, and NextJS depends on your specific requirements, existing skill set, and the ecosystem you’re comfortable with. Blazor is an excellent choice for .NET developers looking to leverage their existing skills in web development. ReactJS offers unparalleled flexibility and a vast ecosystem, making it suitable for a wide range of applications. NextJS builds on ReactJS to provide powerful features for server-side rendering and static site generation, making it ideal for high-performance and SEO-friendly applications.

Coder Legion - Recent posts tagged blazor

Let the Router Own the Next Paint

A correct destination can still have a wrong journey

The hidden effect of an event receiver

Measure the interval, not just the answer

Keeping the old page has a boundary

Test the negative space

A practical review method

The leadership lesson

Test the Owner, Not the Teardown

The shape of the failure

Waiting is not the same as proving

Put the assertion at the ownership boundary

Production code still needs lifecycle discipline

Keep two layers of evidence

A practical checklist

Hand Off Intent, Not Authority

The tempting shortcut

A narrower handoff

Treat public configuration as an API

Make the destination defensive too

Failure must remain boring

Test the negative space

The trade-off is honest friction

A Route Is Not a Feature Until Someone Can Reach It

Routable is not reachable

Define a genuine entry point

Test pages, not strings

Make the scan fail honestly

Align visibility with authorization

The trade-off is real

A small checklist

The Async Result Belongs to the Snapshot That Started It

How the race forms

Make ownership explicit

Fail closed while identity is unknown

Test the interleaving, not only the outcome

The trade-off

Design the Cursor, Not Just the Query

Why offset paging drifts

Continue from an immutable boundary

Make the continuation part of the contract

Keep every downstream read bounded

Carry the contract into the Blazor UI

Test the movement, not only the shape

The honest trade-off

A Page Is Not Shipped Until People Can Find It

Define the invariant at the page boundary

Scan every module, not only the original tree

Keep navigation and authorization separate

Prefer a precise contract over “linked somewhere”

Accept the maintenance cost deliberately

When a Green Test Protects the Wrong Authorization Rule

Navigation visibility is a different boundary

Read assertions as product decisions

Turn the omission into an invariant

Make exceptions accountable

The practical review sequence

Pagination Is a Consistency Contract

Begin with the mutation model

Make the server own the continuation

Bind position to query context

Preserve the operator's place

Test the walk, not only the query

The trade-off is explicit complexity

Realtime Is a Hint, Not Your Source of Truth

The hidden assumption

A three-layer reliability pattern

First, persist the truth

Second, broadcast from the business chokepoint

Third, reconcile periodically

The trade-off

Test the contract, not the transport

A practical review checklist

Blazor Latest Features

Blazor Latest Features

1. Unified Full-Stack Blazor

⚙️ 2. Advanced Rendering Modes

⚡ 3. Streaming Rendering

Benefits:

When `IDbContextFactory` enters the chat, and what it actually fixes

What `IDbContextFactory` changes