.NET 11 RC1. The attributes and defaults in this article come from the ASP.NET Core 11 release notes and the Blazor server state-management docs: [SupplyParameterFromTempData], [SupplyParameterFromSession], cookie TempData, and cookie-backed session. They apply to static server-side rendering only. Interactive Server and WebAssembly leave the property at its CLR default. The browser matrix at the end is the contract to check on the sample, StaticSsrState. It is not a record of a browser run.

A static SSR page is one HTTP request. The component is created, rendered, and thrown away. Nothing you stored in a field is there for the next click. That is a good trade when you do not want a SignalR circuit per user, and it is a problem the moment a form needs to say "Saved." after a redirect, or a three-step wizard needs to remember step one.

.NET 11 gives Blazor static SSR the two stores MVC and Razor Pages have used for years, wired as component parameters:

• [SupplyParameterFromTempData] — read-once flash state. The Post-Redirect-Get message.
• [SupplyParameterFromSession] — state that must survive several requests. The wizard draft or the cart.

Both are declarative in the same way as [SupplyParameterFromQuery] and [SupplyParameterFromForm]. You stop injecting IHttpContextAccessor and hand-serializing a session key for every property.

Six rules cover the choice. The sections after them are the code, the limits, and how to confirm each rule in the browser.

• TempData is the flash. It is written on the POST and read on the next GET. The attribute's first read uses ITempData.Get(), which schedules deletion. Copy the value into a display field and clear the parameter before the request ends, because the framework writes the property back at the end of the request.
• Session is the multi-request store. Values stay until the idle timeout (20 minutes by default; each access resets it), until you assign null, or until the session cookie disappears.
• Static SSR only. On an interactive render mode the same property is never supplied.
• Different boxes. TempData's default store is an encrypted cookie, .AspNetCore.Components.TempData. Session puts the payload in a server-side cache and sends only .AspNetCore.Session.
• The URL is still the shareable store. A copied link does not carry TempData or Session. Bookmarkable view state belongs in the query string.
• One provider for TempData. The cookie provider is the default. Switching to session storage removes the cookie size cap and requires session affinity. Cookie-backed TempData cannot be saved after the response starts streaming.

Where this state should live

Pick the store from the lifetime you actually need. The rest of the article is the two middle rows.

| Store | Lifetime | Shareable link | Survives F5 | New tab | Static SSR | What you operate | | ---------------------------------------------------- | ------------------------------------------ | ---------------------------- | -------------------------------- | ------------------------ | ----------------------------------- | ----------------------------------------------------------------------------- | | TempData | Next read, then removed | No | No, once the GET has consumed it | No | Yes | Encrypted cookie, or the session store if you switch provider | | Session | Idle timeout, reset on access | No | Yes | Yes, same session cookie | Yes | Server cache plus a session cookie; session affinity required | | URL query | As long as the URL is kept | Yes | Yes | Yes | Yes | Nothing on the server | | Database | Until you delete the row | Only if the id is in the URL | Yes | Yes | Yes | Your database | | Interactive Server, WASM, PersistentComponentState | Circuit, prerender handoff, or the browser | No | Depends on the mode | No | The page no longer has to be static | A circuit or a client runtime |

A success banner after save is TempData. A wizard or a cart that must not show up in the address bar is Session. A filtered list someone should send to a colleague is the query string and that is the subject of QuickGrid in .NET 11: Sorting and Paging That Live in the URL. An order that must still exist after the browser is closed is a database row.

What a static SSR request actually keeps

Blazor Server holds component fields in a SignalR circuit. WebAssembly holds them in the browser. Static SSR holds them nowhere. The next request starts from the parameters the framework can rebuild: route, query, form, TempData, session.

Circuit persistence, [PersistentState], and auto-pause are interactive-server features. They resume a circuit. They do not implement Post-Redirect-Get on a page that has no circuit. The section When static SSR is the wrong tool comes back to them.

TempData

TempData is the bag you fill on the POST so the redirect target can show a message once. AddRazorComponents() registers it. You do not call AddSession for the default cookie provider.

The full API is a cascading ITempData:

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

Get reads a key and schedules it for deletion. Peek reads it and leaves it. Keep() retains every key for the following request. Keep(key) retains one. Keys are case-insensitive. Those methods are how you keep a message alive across an intermediate redirect. The attribute does not expose them — the TempData attribute work left Peek and Keep on ITempData on purpose.

For a single value, [SupplyParameterFromTempData] is the shortcut. The key defaults to the property name. Set Name when the key should be stable across a rename, or when two properties would otherwise collide:

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

[SupplyParameterFromTempData(Name = "flash_message")]
public string? FlashMessage { get; set; }

Two components in the same render tree cannot register the same key. The supplier throws InvalidOperationException. Mixing TempData["flash_message"] and the attribute for that same key in one request is unsupported; the value that wins depends on order.

The first time the attribute reads a key it calls Get(), so the key is marked for deletion. Later reads in the same request return the property's current value, so your submit handler can overwrite it. At the end of the request the supplier writes every bound property back into TempData. That write-back is why a flash you leave sitting in the property can be saved again. The feedback sample below copies the string into a display field and assigns null before the response completes.

The supported types are a closed list: string, int, bool, Guid, DateTime, int-backed enums, the nullable forms of those, T[], List<T>, HashSet<T>, Collection<T>, Dictionary<string, T>, and object[]. A custom class is not on that list.

A read-side mismatch is the case that becomes null. If the stored value's type is not assignable to the property, or deserialization fails, the attribute supplies null and writes a log entry. An unsupported non-null value fails later, when the response is persisted, after the component has rendered.

The default provider stores that JSON in an encrypted cookie. Data Protection does the encryption. The docs' defaults are:

| Setting | Default | | ------------ | --------------------------------- | | Name | .AspNetCore.Components.TempData | | HttpOnly | true | | SameSite | Lax | | SecurePolicy | SameAsRequest |

On a production HTTPS site, set CookieSecurePolicy.Always. Override the cookie on the Razor components options:

builder.Services.AddRazorComponents(options =>
{
    options.TempDataCookie.Name = ".AspNetCore.Components.TempData";
    options.TempDataCookie.HttpOnly = true;
    options.TempDataCookie.SameSite = SameSiteMode.Lax;
    options.TempDataCookie.SecurePolicy = CookieSecurePolicy.Always;
});

Browsers limit a single cookie to about 4 KB. The provider chunks large values with ChunkingCookieManager. Past that, call AddSessionStorageTempDataValueProvider(). Only one provider is active. Session-backed TempData then needs AddSession, UseSession, and session affinity. Cookie-backed TempData cannot be saved after the response has started streaming. A page that streams and still needs TempData has to use the session provider.

Session

Session is the store you read on several requests and never want in the query string: the onboarding draft, the cart id, the step index. Unlike TempData, a read does not delete it.

It is not registered by AddRazorComponents() alone:

builder.Services.AddDistributedMemoryCache();

builder.Services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromMinutes(20);
    options.Cookie.HttpOnly = true;
    options.Cookie.IsEssential = true;
    options.Cookie.SameSite = SameSiteMode.Lax;
});

builder.Services.AddRazorComponents();

var app = builder.Build();

app.UseSession();
app.MapRazorComponents<App>();

UseSession() has to run before the component endpoint. UseAntiforgery() is optional in .NET 11 and is no longer in the Blazor template. The defaults you are overriding, or accepting, are:

| Setting | Default | | ------------ | -------------------------------- | | Cookie name | .AspNetCore.Session | | Path | / | | HttpOnly | true | | SameSite | Lax | | SecurePolicy | None | | IsEssential | false | | IdleTimeout | 20 minutes, reset on each access | | IOTimeout | 1 minute |

IsEssential defaults to false, so cookie-consent middleware can drop the cookie and the wizard silently restarts. The sample sets it to true because the draft is required for the flow. Idle timeout applies to the session contents, not to the cookie's Expires. SecurePolicy defaults to None because apps often mix HTTP and HTTPS in development, and some browsers refuse to overwrite a Secure cookie from an insecure URL. That rationale belongs to this cookie, not to TempData.

[SupplyParameterFromSession] reads the key on the way in and writes the property back before the response is sent. Allowed values are the same closed list as TempData: string, int, bool, Guid, DateTime, int-backed enums, their nullables, T[], List<T>, HashSet<T>, Collection<T>, Dictionary<string, T>, and object[]. A custom class is not on that list. [SupplyParameterFromSession] OnboardingDraft? Draft threw InvalidOperationException: the type is not supported for session storage. The sample stores string? and int? instead. A duplicate key across components throws InvalidOperationException. Keys are compared case-insensitively.

[SupplyParameterFromSession(Name = "onboarding_name")]
public string? Name { get; set; }

[SupplyParameterFromSession(Name = "onboarding_step")]
public int? Step { get; set; }

AddDistributedMemoryCache() is process-local. Session requires session affinity in a load-balanced deployment, including when the cache is in memory. A second instance does not see the first instance's memory.

Streaming SSR has two separate rules. If the page subscribes with [SupplyParameterFromSession], or the session-storage TempData provider is active, the session cookie is issued before streaming starts, even when the handler writes nothing. Pages that do not touch session are unchanged. Cookie-backed TempData cannot be saved once streaming has started, so a streaming page that needs TempData uses AddSessionStorageTempDataValueProvider() and takes on the same affinity requirement.

What the attributes leave alone

During interactive SSR and interactive client rendering the value is not supplied. The property stays at its default: null for string?, null for int?. A page marked @rendermode InteractiveServer that expects the wizard to appear will render the empty state.

They also do not replace antiforgery. EditForm with a FormName emits the token. A plain <form method="post"> needs <AntiforgeryToken /> and @formname. Leave validation on. Calling UseAntiforgery() is optional in .NET 11, and the Blazor template no longer includes it.

The sample

Create a Blazor web app with no interactivity:

dotnet new blazor -n StaticSsrState --interactivity None --empty
cd StaticSsrState
dotnet run

The sample is StaticSsrState. The matrix in Behavior to check on the sample is the contract from this article. It is not a filled-in record of a browser run.

Suggested layout:

• Program.cs — session registration and TempData cookie policy
• Components/Pages/Feedback.razor — PRG flash
• Components/Pages/Onboarding.razor — three steps and a clear

Service registration

Add the session services next to AddRazorComponents, and call UseSession() before the endpoint. Leave the rest of the generated pipeline in place.

builder.Services.AddDistributedMemoryCache();

builder.Services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromMinutes(20);
    options.Cookie.HttpOnly = true;
    options.Cookie.IsEssential = true;
    options.Cookie.SameSite = SameSiteMode.Lax;
    options.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest;
});

builder.Services.AddRazorComponents(options =>
{
    options.TempDataCookie.HttpOnly = true;
    options.TempDataCookie.SameSite = SameSiteMode.Lax;
    options.TempDataCookie.SecurePolicy = CookieSecurePolicy.SameAsRequest;
});

app.UseSession();
app.MapRazorComponents<App>();

The sample does not call AddInteractiveServerComponents(). The two pages below are static on purpose. UseAntiforgery() is left out, matching the .NET 11 template. TempData's SameSite and SecurePolicy in this block are the defaults (Lax, SameAsRequest). The session cookie's SecurePolicy default is None; the sample sets SameAsRequest instead.

Post-Redirect-Get flash message

Feedback.razor posts a comment, stores a one-line result in TempData, and redirects to itself. Enhanced form handling is off unless the form sets Enhance or data-enhance. Enhance="false" changes nothing, so these forms omit it. The POST is a full document post. NavigateTo(..., forceLoad: true) loads the redirect target as a full document.

The handler writes FlashMessage. OnInitialized copies it into _notice and clears the parameter so the end-of-request write-back does not save the banner for the refresh after that.

@page "/feedback"
@using System.ComponentModel.DataAnnotations
@inject NavigationManager Navigation

<PageTitle>Feedback</PageTitle>

@if (!string.IsNullOrEmpty(_notice))
{
    <p role="status">@_notice</p>
}

<EditForm Model="Input" FormName="feedback" OnValidSubmit="Submit">
    <DataAnnotationsValidator />
    <div>
        <label>
            Comment
            <InputText @bind-Value="Input.Comment" />
        </label>
        <ValidationMessage For="() => Input.Comment" />
    </div>
    <button type="submit">Send</button>
</EditForm>

@code {
    private string? _notice;

    [SupplyParameterFromTempData(Name = "flash_message")]
    public string? FlashMessage { get; set; }

    [SupplyParameterFromForm]
    public FeedbackInput Input { get; set; } = new();

    protected override void OnInitialized()
    {
        _notice = FlashMessage;
        FlashMessage = null;
    }

    private void Submit()
    {
        FlashMessage = $"Thanks. We received \"{Input.Comment}\".";
        Navigation.NavigateTo("/feedback", forceLoad: true);
    }

    public sealed class FeedbackInput
    {
        [Required]
        [StringLength(280)]
        public string? Comment { get; set; }
    }
}

Flash Message

[Required] keeps an empty submit off the success path, so there is no fake error banner to invent. If you also want an error that survives a redirect, a failure that happens after validation, such as a downstream reject, set FlashMessage to that text and redirect the same way.

When one redirect is not enough, drop the attribute for that key and use the cascading dictionary:

protected override void OnInitialized()
{
    _notice = TempData?.Get("flash_message") as string;
    TempData?.Keep("flash_message");
}

Keep is the exception. The feedback page should consume the message.

Multi-step onboarding in session

OnboardingDraft is not a supported session type. The sample stores three values, and null removes each key. Finish assigns Name, Company, and Step to null. The next GET is written to render step 1.

@page "/onboarding"
@using System.ComponentModel.DataAnnotations
@inject NavigationManager Navigation

<PageTitle>Onboarding</PageTitle>

@if (Step is null || Step <= 1)
{
    <h1>Your name</h1>
    <EditForm Model="NameInput" FormName="onboarding-name" OnValidSubmit="SaveName">
        <DataAnnotationsValidator />
        <label>
            Name
            <InputText @bind-Value="NameInput.Name" />
        </label>
        <ValidationMessage For="() => NameInput.Name" />
        <button type="submit">Continue</button>
    </EditForm>
}
else if (Step == 2)
{
    <h1>Your company</h1>
    <p>Name on file: @Name</p>
    <EditForm Model="CompanyInput" FormName="onboarding-company" OnValidSubmit="SaveCompany">
        <DataAnnotationsValidator />
        <label>
            Company
            <InputText @bind-Value="CompanyInput.Company" />
        </label>
        <ValidationMessage For="() => CompanyInput.Company" />
        <button type="submit">Continue</button>
    </EditForm>
}
else
{
    <h1>Review</h1>
    <p>@Name, @Company</p>
    <form method="post" @formname="onboarding-finish" @onsubmit="Finish">
        <AntiforgeryToken />
        <button type="submit">Finish and clear</button>
    </form>
}

@code {
    [SupplyParameterFromSession(Name = "onboarding_name")]
    public string? Name { get; set; }

    [SupplyParameterFromSession(Name = "onboarding_company")]
    public string? Company { get; set; }

    [SupplyParameterFromSession(Name = "onboarding_step")]
    public int? Step { get; set; }

    [SupplyParameterFromForm]
    public NameInputModel NameInput { get; set; } = new();

    [SupplyParameterFromForm]
    public CompanyInputModel CompanyInput { get; set; } = new();

    protected override void OnInitialized()
    {
        NameInput ??= new();
        CompanyInput ??= new();
        NameInput.Name ??= Name;
        CompanyInput.Company ??= Company;
    }

    private void SaveName()
    {
        Name = NameInput.Name;
        Step = 2;
        Navigation.NavigateTo("/onboarding", forceLoad: true);
    }

    private void SaveCompany()
    {
        Company = CompanyInput.Company;
        Step = 3;
        Navigation.NavigateTo("/onboarding", forceLoad: true);
    }

    private void Finish()
    {
        Name = null;
        Company = null;
        Step = null;
        Navigation.NavigateTo("/onboarding", forceLoad: true);
    }

    public sealed class NameInputModel
    {
        [Required]
        public string? Name { get; set; }
    }

    public sealed class CompanyInputModel
    {
        [Required]
        public string? Company { get; set; }
    }
}

Session Logic

Idle expiry is the other clear. Set IdleTimeout to 30 seconds in Development, wait, and reload. The three properties come back unset, and the page has to show step 1. Treat a missing step as a new draft, never as step 3 with blank fields. The Step <= 1 branch above is that guard. The sample leaves the timeout at 20 minutes.

A cart uses a supported collection, such as List<string> of product ids. List<CartLine> is rejected the same way OnboardingDraft was.

An interactive render mode does not supply these parameters. The property stays at its default, so a circuit is the wrong place to read the flash or the wizard. That limit is stated in When static SSR is the wrong tool. The sample does not add a page for it.

Security, scale-out, and the refresh button

Security and privacy

Data Protection keys have to be the same on every node. A TempData cookie written on node A does not decrypt on node B when each machine has its own key ring. Share the key ring the same way you already share authentication-cookie keys: a file share, Redis, or a vault.

The cookie is encrypted and HttpOnly. It still travels on every request and sits in the browser profile. Keep secrets, tokens, and personal data out of it. Session stores the payload on the server and sends the session id. That is the right default as soon as the value identifies a person or grows past a short message.

Both forms still post an antiforgery token. Tampering with the TempData cookie should fail at decryption. Check that on the sample by editing the cookie and reloading: the page should come back with an empty flash and a log entry, not with attacker-controlled text in the paragraph.

Scale-out

In-memory distributed cache is one process. A second instance, or a recycle, drops every draft stored there. Session requires session affinity so the next request returns to the node that holds that session. Session-backed TempData has the same requirement. Cookie TempData needs shared Data Protection keys and does not need affinity.

Refresh, Back, and copied links

F5 after the feedback GET drops the banner. That is the lifetime you asked for when you chose TempData. F5 on the wizard keeps the draft.

Back and Forward move through URLs. They do not rewind TempData or Session the way they rewind ?step=2. If the product needs history, put the step in the query string and keep only the draft body in session.

A copied /onboarding link opens step 1 on another computer, because the draft is in the first browser's session cookie. Publish a link only for state that lives in the URL or in a database row the recipient is allowed to read.

When static SSR is the wrong tool

Use Interactive Server or WebAssembly when the interface itself has to stay alive between requests: a drag-and-drop board, a circuit-scoped service, a component that mutates on onclick without a POST. [PersistentState] and PersistentComponentState carry prerendered values into that interactive runtime, and circuit persistence can resume an Interactive Server circuit after a disconnect. They are the wrong tool for a flash message after a redirect.

A practical split is a static page for the wizard and the banner, and an interactive render mode on the one component that needs a live event. Turning the whole app interactive in order to remember one string gives you a circuit per user and still loses the value on a full reload unless you persist it anyway.

Behavior to check on the sample

These rows are the contract from the sections above. They are not measured results. The last column is what to look for. If the browser disagrees, change this article.

| Action | TempData contract | Session contract | What to look for | | -------------------------------------------- | ------------------------------------------------------------------ | --------------------------------------- | -------------------------------------- | | Submit the feedback form | flash_message is stored, then read on the redirect GET | — | Banner text after redirect | | Submit onboarding step 1, then step 2 | — | Name and step retained across both GETs | Name still visible on the company step | | F5 | Consumed by the previous GET, and cleared by the null write-back | Name still present | Banner gone; name still there | | Open the same URL in a new tab | Flash already consumed | Same .AspNetCore.Session cookie | Banner absent; draft visible | | Copy the URL into a private window | No session cookie | No session cookie | Both pages empty | | Finish onboarding | — | Name, company, and step set to null | Next GET is step 1 | | Idle timeout (set 30 seconds in Development) | — | Session abandoned | Step 1, empty fields | | Edit the TempData cookie and reload | Decrypt fails, value becomes null | — | Empty banner, no injected markup |

Also note, if you hit them: a log line when two components share one session key, cookie chunking if you stuff the feedback string toward 4 KB, and Set-Cookie: .AspNetCore.Session on a streaming response before the body. Cookie-backed TempData on that same streaming response cannot be saved.

Constraints that are already part of the contract, whether or not the demo surprises us:

• Both attributes are static SSR only.
• Both attributes accept the closed list: string, int, bool, Guid, DateTime, int-backed enums, their nullables, T[], List<T>, HashSet<T>, Collection<T>, Dictionary<string, T>, and object[]. A custom class is rejected. The wizard stores string? and int?.
• Cookie TempData is a short, non-sensitive message. Large TempData, and any TempData on a streaming response, moves to the session provider and requires session affinity.
• Session does nothing until AddSession and UseSession are both there. A load-balanced deployment also needs session affinity.
• One TempData provider is active.

Adoption checklist

• Flash after one redirect → TempData. Several requests, and the value must stay out of the URL → Session. A link someone else can open → query string. Still there after the browser closes → database.
• The page is static SSR. An interactive render mode will not populate these parameters.
• AddRazorComponents is registered. Session also has a distributed cache, AddSession, and UseSession before the endpoint.
• The flash sample copies the TempData value out and assigns null, so write-back does not keep the banner.
• TempData holds no secrets and no personal data. Session holds no unbounded blobs.
• Data Protection keys are shared across the farm. Session and session-backed TempData run with session affinity.
• Production cookies set Secure. Session is IsEssential only when the flow actually requires the cookie.
• Form posts still include the antiforgery token. UseAntiforgery() is optional in .NET 11 and is not in the template.
• Finish, cancel, and idle expiry all end on the empty state.
• F5, a new tab, and a copied link were tried, and what you saw matches the "what to look for" column. Until that happens, the matrix stays unchecked.
• Attribute names and cookie defaults were rechecked on the SDK you ship.

References

• What's new in ASP.NET Core in .NET 11 — TempData, [SupplyParameterFromSession], and the streaming-SSR session-cookie fix. This article tracks .NET 11 RC1
• ASP.NET Core Blazor server-side state management — ITempData, both attributes, cookie and session option tables
• Enhanced navigation and form handling — Enhance and data-enhance are opt-in
• dotnet/aspnetcore: PR #64749 (TempData for Blazor SSR), PR #65306 ([SupplyParameterFromTempData]), PR #65184 ([SupplyParameterFromSession]), PR #66832 (streaming SSR session cookie and TempData persistence)
• QuickGrid in .NET 11: Sorting and Paging That Live in the URL — when the query string is the better store
• Demo StaticSsrState

Angular's shift toward Signals has changed how applications model state and data loading. Instead of manually coordinating subscriptions, loading flags, and error handling, Angular now provides resource APIs that integrate asynchronous data fetching directly into the signal ecosystem.

To embrace this programming model, ABP now offers an optional Resource API generation mode for Angular service proxies. When enabled, the proxy generator produces signal-friendly APIs for read operations while preserving the familiar Observable-based experience for the rest of your application.

This article introduces the new Resource API generation mode, explains why it exists, how it works, and when it should be preferred over traditional Observable-based proxies.

Why Resource APIs

For years, Angular applications have relied on observable-based services to communicate with backend APIs. While Observables remain extremely powerful, consuming them inside components often requires additional state management.

A typical read operation usually involves:

• subscribing to an Observable,
• tracking loading state,
• storing the latest value,
• handling errors,
• cleaning up subscriptions when necessary.

As applications adopt Signals for local state, this pattern starts to feel increasingly imperative. The component becomes responsible not only for displaying data, but also for orchestrating the entire request lifecycle.

Angular's Resource APIs address this problem by treating asynchronous data as reactive state. Instead of manually reacting to changes, you describe what the request depends on, and Angular automatically keeps the resource synchronized.

For example, if a request depends on an entity ID represented as a Signal, changing that signal automatically triggers a new request. The component no longer needs to manually subscribe or invoke refresh logic simply because an input changed.

This approach offers several benefits:

• loading, error, and value state are managed together,
• requests automatically react to signal changes,
• components become more declarative,
• significantly less boilerplate is required.

Resource APIs are therefore an excellent fit for read-only data retrieval, where the primary goal is to keep the UI synchronized with backend state.

What Angular Gives Us

Angular provides several APIs for working with asynchronous resources, each targeting a slightly different use case.

resource

The resource API is Angular's generic primitive for asynchronous state.

It is designed for loaders that return promise-based results and automatically exposes:

• the current value,
• loading status,
• errors,
• reload capabilities.

This API is ideal when your asynchronous source is not based on RxJS.

rxResource

Most Angular applications—including ABP applications—already communicate with the backend through HttpClient, whose APIs return Observables.

The rxResource helper bridges these existing Observable streams with Angular's Resource model. Instead of rewriting existing services to use Promises, it simply wraps an Observable-producing function and exposes it as a reactive resource.

Internally, the new ABP proxy generation mode uses this approach. Generated resource methods eventually call the existing RestService request pipeline, while exposing the result as an Angular ResourceRef. This means existing authentication, interceptors, multi-tenancy, localization, error handling, and other ABP infrastructure continue to work exactly as before.

httpResource

Angular also provides httpResource, which is a specialized resource implementation built directly on top of HttpClient.

For applications making direct HTTP requests, this can be a convenient option.

However, ABP applications already centralize HTTP communication through RestService, which adds framework-specific behavior around every request. Because of that, the generated proxies rely on rxResource rather than httpResource, allowing them to preserve the entire ABP request pipeline while still providing a signal-based API.

In short:

| API | Intended for | | --- | --- | | resource | Generic asynchronous loaders returning Promises | | rxResource | Existing RxJS/Observable-based data sources | | httpResource | Direct HttpClient requests without additional abstraction |

Since ABP proxies already build on top of RestService, rxResource is the natural choice for bringing Signal-based data loading to generated client proxies.

Why This Feature Is Opt-In

One of the primary goals of the new Resource API generation mode is to introduce a modern, Signal-friendly API without disrupting existing applications.

ABP's generated Angular service proxies have been Observable-based for years, and they continue to serve a wide range of applications effectively. Many projects already rely on RxJS operators, custom Observable pipelines, and existing component patterns. Replacing those generated APIs would introduce unnecessary breaking changes for little benefit.

Instead, Resource API generation is completely opt-in.

By passing the --resource-api option to the abp generate-proxy command, the generator produces additional resource helpers designed for Angular's Signal ecosystem. If you do not enable the option, proxy generation behaves exactly as it always has, producing the familiar Observable-based services.

This gradual approach offers several advantages:

• Existing applications continue working without modification.
• Teams can adopt Signals incrementally instead of performing a large migration.
• New pages can embrace Resource APIs while older features continue using Observables.
• Developers remain free to choose the programming model that best fits each feature.

Another intentional design decision is that only read operations receive Resource API helpers.

Resource APIs naturally model asynchronous state that can be refreshed whenever their reactive inputs change. This makes them an excellent fit for GET requests, where the goal is to retrieve and synchronize data.

Write operations such as POST, PUT, PATCH, and DELETE represent user actions rather than continuously synchronized state. These operations are typically composed with RxJS pipelines, optimistic updates, notifications, or custom error handling, making Observables the more appropriate abstraction.

By limiting Resource APIs to read operations, generated proxies follow Angular's recommended usage patterns while keeping mutation APIs predictable and familiar.

Generator Behavior

Enabling Resource API generation requires only a single additional option:

abp generate-proxy -t ng --resource-api

Without this option, the generator behaves exactly as before, producing standard Observable-based service methods.

For example, a generated service might expose a method like:

bookService.getList(input);

which returns an Observable and can be consumed with RxJS operators or converted into Signals using Angular's interoperability utilities.

When --resource-api is enabled, the generator preserves these existing methods and additionally generates companion Resource API methods for every GET endpoint.

For example:

bookService.getList(...);          // Observable
bookService.getListResource(...);  // ResourceRef

These generated resource methods internally use Angular's rxResource while continuing to execute requests through ABP's existing RestService. As a result, the complete ABP request pipeline—including authentication, interceptors, localization, multi-tenancy, and error handling—remains unchanged.

The generator only creates resource helpers for GET endpoints. Mutation methods such as create, update, and delete continue to return Observables exactly as before.

This selective generation keeps the generated API straightforward:

• Read operations gain Signal-friendly Resource APIs.
• Write operations continue using Observables.
• Existing Observable methods remain available, allowing gradual adoption without forcing a migration.

In the next section, we'll examine the shape of the generated Resource API methods and see how they integrate naturally with Angular Signals.

Generated API Shape

The generated Resource API methods closely resemble their Observable counterparts, making them easy to adopt. Rather than introducing an entirely new programming model, they adapt the existing proxy APIs to Angular's Signal ecosystem.

There are, however, a few important differences.

Signal-Based Inputs

Traditional proxy methods accept plain values:

bookService.get(id);

The generated Resource API methods instead accept Signals.

const id = signal('42');

const book = bookService.getResource(id);

Because the input is reactive, Angular automatically re-executes the request whenever the signal value changes.

id.set('43');

No additional method calls, subscriptions, or refresh logic are required—the resource stays synchronized with its dependencies automatically.

Returning a ResourceRef

Observable-based proxy methods return an Observable<T>.

Resource methods instead return a ResourceRef<T>, which exposes the request state as Signals.

This gives components access to everything they typically need during data loading:

• the current value,
• loading status,
• any request error,
• reload functionality.

A component can consume the resource directly:

const book = bookService.getResource(id);

book.value();
book.isLoading();
book.error();
book.reload();

Instead of maintaining separate signals for loading, data, and errors, the resource keeps these states together in a single reactive object.

Reactive Request Construction

Many API endpoints require multiple parameters or request objects.

Rather than asking developers to manually rebuild those objects whenever an input changes, the generated methods construct the request reactively using Angular's computed() API.

Suppose a request depends on pagination and a search keyword:

const page = signal(1);
const filter = signal('');

The generated proxy internally derives the request object from these Signals.

Whenever either value changes, Angular recomputes the request and automatically performs a new HTTP request.

This means developers only manage application state. The generated proxy takes care of determining when a request should be refreshed.

Examples

Let's compare a few common scenarios to see how generated Resource APIs look in practice.

Fetching a Single Entity

A traditional generated proxy might be used like this:

bookService.get(id).subscribe(...);

With Resource API generation enabled:

const id = signal('42');

const book = bookService.getResource(id);

Changing the ID automatically reloads the resource.

id.set('84');

The component simply reads the latest value:

book.value();

Angular handles the request lifecycle automatically.

Fetching a List with Query Parameters

List endpoints become even more interesting because they usually depend on multiple reactive inputs.

Consider a search page with pagination.

const filter = signal('');
const skipCount = signal(0);
const maxResultCount = signal(10);

Using the generated proxy is straightforward:

const books = bookService.getListResource({
  filter,
  skipCount,
  maxResultCount,
});

Whenever any of these Signals changes, Angular automatically refreshes the resource.

filter.set('Angular');
skipCount.set(20);

There is no need to manually call getList() again or synchronize subscriptions with UI state.

Behind the Scenes

Although the generated API feels simple to consume, the proxy performs a considerable amount of work internally.

Conceptually, the generated method looks similar to the following:

getListResource(input: {
  filter: Signal<string>;
  skipCount: Signal<number>;
  maxResultCount: Signal<number>;
}): ResourceRef<PagedResultDto<BookDto>> {
  return this.restService.requestResource({
    method: 'GET',
    url: '/api/app/books',
    params: computed(() => ({
      filter: input.filter(),
      skipCount: input.skipCount(),
      maxResultCount: input.maxResultCount(),
    })),
  });
}

Notice that every request parameter is read inside a computed() callback. This establishes Angular's reactive dependency tracking, ensuring that any change to an input Signal automatically triggers a new request.

As a consumer, you never need to think about this implementation detail. You simply update your Signals, and the generated proxy keeps the resource synchronized with your application's state.

Best Practices

As with any new Angular feature, Resource APIs are most effective when used in the scenarios they were designed for. The following recommendations can help you get the most out of generated Resource-based proxies while keeping your codebase clean and maintainable.

Use Resource APIs for Read Operations

Resource APIs are designed to represent reactive, read-only state.

Whenever your UI needs to retrieve data that should stay synchronized with one or more Signals, generated resource methods are an excellent choice.

Typical examples include:

• entity details,
• paginated lists,
• search results,
• dashboard widgets,
• lookup data.

These scenarios naturally benefit from automatic reloading whenever their reactive inputs change.

Keep Mutations as Observable Methods

Operations that modify server state—such as creating, updating, or deleting data—should continue using the standard Observable-based proxy methods.

Mutation requests often involve additional workflows such as:

• displaying success notifications,
• handling validation errors,
• optimistic UI updates,
• chaining additional requests,
• navigation after completion.

These workflows fit naturally into RxJS pipelines, which is why the generator intentionally keeps write operations unchanged.

Let Signals Drive Your Requests

One of the biggest advantages of Resource APIs is that you no longer decide when to issue a request.

Instead, you describe what the request depends on, and Angular takes care of the rest.

Rather than writing code like:

filter.valueChanges.subscribe(() => loadBooks());

simply update the underlying Signals.

Whenever those Signals change, the generated resource automatically refreshes itself.

This declarative approach removes much of the manual subscription and synchronization logic that traditionally accumulates in Angular components.

Build Request Objects with computed()

When an endpoint accepts multiple parameters, derive the request object using computed() instead of constructing it manually.

For example:

const request = computed(() => ({
  filter: filter(),
  skipCount: skipCount(),
  maxResultCount: maxResultCount(),
}));

This ensures Angular can correctly track every dependency involved in the request.

Likewise, avoid reading Signal values outside of the reactive computation.

Instead of extracting Signal values first:

const currentFilter = filter();

const request = computed(() => ({
  filter: currentFilter,
}));

read them directly inside the computed() callback:

const request = computed(() => ({
  filter: filter(),
}));

Doing so allows Angular to react whenever those Signals change.

Consume the Entire ResourceRef

A generated resource provides much more than the retrieved value.

Instead of creating separate Signals for loading and error state, consume the ResourceRef directly.

For example:

• value() exposes the latest successful result.
• isLoading() indicates whether a request is in progress.
• error() provides the latest request failure.
• reload() manually refreshes the resource when needed.

Keeping these states together makes components easier to understand and reduces state duplication.

Choose the Right Resource API

Angular offers multiple Resource APIs, each serving a different purpose.

For generated ABP service proxies, the recommended approach is the generated Resource API based on rxResource, since it preserves the existing RestService pipeline and all of its framework integrations.

If you're writing standalone Angular services that communicate directly with HttpClient, httpResource may be a better fit.

Choosing the appropriate abstraction helps keep both your generated code and handwritten services consistent with Angular's intended usage patterns.

Conclusion

Angular Signals have introduced a more declarative way to manage application state, and Resource APIs naturally extend that model to asynchronous data loading.

With Resource API generation, ABP brings this programming model directly into generated Angular service proxies. Read operations become reactive, Signal-driven, and significantly easier to consume, while write operations continue using the familiar Observable-based APIs that already work well for mutations.

Most importantly, this evolution is completely opt-in. Existing applications can continue using their current proxies without modification, while new features can gradually adopt Resource APIs wherever they provide the greatest benefit.

Whether you're building a new Signal-first Angular application or incrementally modernizing an existing ABP solution, Resource-based proxy generation offers a straightforward path toward cleaner components, less boilerplate, and a more reactive data-fetching experience.

Angular has been steadily moving toward a signal-first architecture since the introduction of Signals in Angular 16. With Angular 22, that transition reaches another milestone. Signals are now at the center of Angular's reactive programming model, while APIs such as Resource and Signal Forms have matured into production-ready solutions. Combined with the framework's continued investment in zoneless change detection, these improvements significantly influence how Angular applications should manage state.

This shift also changes the role of NgRx. While the classic NgRx Store remains a powerful solution for large, event-driven applications, many scenarios that previously required reducers, selectors, and effects can now be implemented with much simpler, feature-scoped signal stores. Rather than replacing NgRx, Angular 22 encourages developers to choose the right state management strategy based on the scope and complexity of the problem.

In this article, we'll explore how Angular 22 changes the state management landscape, compare the classic NgRx Store with NgRx SignalStore, and demonstrate best practices for building modern Angular applications. We'll also discuss how Angular's new reactive APIs fit into enterprise applications and what these changes mean for projects built with the ABP Framework.

Why Angular 22 Changes State Management

Angular Signals introduced a fundamentally different approach by providing fine-grained reactivity built directly into the framework. Instead of propagating changes through Observable streams, Signals allow Angular to track exactly which pieces of state are consumed and update only the affected parts of the UI. This results in more predictable rendering, less boilerplate, and improved runtime performance.

Angular 22 builds on this foundation by making Signals the preferred reactive primitive throughout the framework. New APIs such as Resource for asynchronous data loading and Signal Forms for reactive forms integrate naturally with Signals, reducing the need for custom RxJS pipelines in many common scenarios.

For developers using NgRx, this doesn't mean abandoning existing applications or rewriting every store. Instead, it changes how state management should be approached. Component-local state can often be managed with plain Signals, feature-level state fits naturally into SignalStore, and the classic NgRx Store continues to excel for large-scale applications that benefit from centralized event streams, auditing, and global state synchronization.

Understanding these changing responsibilities is the key to designing maintainable Angular applications in the Angular 22 era. A practical way to think about state management is to start with the simplest solution and introduce additional abstractions only when the application's complexity requires them.

Use Signals for Local Component State

Plain Angular Signals are ideal for state that belongs exclusively to a single component. Examples include dialog visibility, selected tabs, loading indicators, filter values, or temporary form data.

Signals provide a straightforward API with minimal overhead and integrate seamlessly with Angular's change detection. For state that never needs to be shared outside a component or its immediate children, introducing a dedicated store often adds unnecessary complexity.

A settings page often contains UI state that doesn't need to be shared with the rest of the application. Using a dedicated store for this would introduce unnecessary complexity.

@Component({...})
export class UserListComponent {
  readonly search = signal('');
  readonly showInactive = signal(false);

  readonly filteredUsers = computed(() =>
    this.users().filter(user =>
      user.name.includes(this.search()) &&
      (this.showInactive() || user.active)
    )
  );
}

This state is entirely local to the component and doesn't justify introducing a SignalStore.

Use NgRx SignalStore for Feature State

As applications grow, state often needs to be shared across multiple components within the same feature. Examples include user profiles, shopping carts, administration screens, dashboards, or settings pages.

NgRx SignalStore is designed specifically for these scenarios. It combines Angular Signals with a lightweight, feature-oriented architecture where state, computed values, and business logic are defined together. Instead of scattering logic across reducers, selectors, effects, and services, developers can keep everything related to a feature inside a single store.

SignalStore also integrates naturally with Angular's signal-based APIs, making it an excellent choice for modern Angular applications built around Resources and Signal Forms.

A User Management module is shared by multiple pages. The selected user, filters, and loaded entities should remain synchronized across those pages.

export const UserStore = signalStore(
  withState({
    users: [] as User[],
    selectedUserId: null as number | null,
    loading: false,
  }),

  withComputed(({ users, selectedUserId }) => ({
    selectedUser: computed(() =>
      users().find(x => x.id === selectedUserId())
    ),
  })),

  withMethods((store) => ({
    selectUser(id: number) {
      patchState(store, { selectedUserId: id });
    },
  })),
);

Everything related to the feature lives in one place: state, derived values, and business operations.

NgRx Store vs. NgRx SignalStore

Although both solutions belong to the NgRx ecosystem, they are designed to solve different architectural problems.

The classic NgRx Store follows the Redux pattern, where every state change is represented by an action that flows through reducers before producing a new immutable state. This explicit, event-driven architecture provides excellent traceability and scales well for applications with extensive global interactions.

SignalStore takes a different approach. Instead of centering the application around dispatched actions, it treats state as a reactive service built with Angular Signals. A SignalStore typically contains three core building blocks:

• State, which represents the application's reactive data.
• Computed signals, which derive values from existing state.
• Methods, which encapsulate business logic and state updates.

This functional model significantly reduces boilerplate while remaining predictable and testable. Since it builds directly on Angular Signals, it also integrates naturally with Angular's fine-grained change detection without requiring selectors or async pipes for many common scenarios.

The following comparison summarizes the strengths of each approach.

| Feature | Classic NgRx Store | NgRx SignalStore | | ---------------- | ------------------------------- | --------------------------------- | | Architecture | Redux-based global store | Feature-oriented reactive store | | Reactivity | RxJS Observables | Angular Signals | | Boilerplate | Higher | Lower | | State Scope | Global application state | Feature or route state | | Side Effects | Effects | Store methods or rxMethod | | Change Detection | Observable subscriptions | Native signal reactivity | | Best For | Large event-driven applications | Modern feature-based applications |

For most new Angular 22 applications, SignalStore is an excellent default choice for feature-level state management because it embraces the framework's signal-first architecture while keeping code concise and maintainable. The classic NgRx Store remains indispensable for applications that rely heavily on centralized event processing, global synchronization, or advanced debugging capabilities.

Instead of asking "Which one should I use?", the better question is "Which scope of state am I trying to manage?" The answer usually determines the appropriate solution.

Angular 22 Features That Improve State Management

Angular 22 introduces several framework APIs that naturally complement modern state management patterns. Rather than replacing NgRx, these APIs reduce the amount of custom infrastructure developers previously had to build around it.

Resource API

One of the most significant additions is the Resource API, which provides a signal-based approach to asynchronous data loading.

Historically, fetching remote data in Angular involved coordinating HttpClient, RxJS operators, subscriptions, loading flags, and error handling. While these patterns remain valid, they often require considerable boilerplate even for straightforward scenarios.

Resources encapsulate these concerns into a single reactive abstraction. A Resource automatically tracks the signals it depends on, performs requests when those dependencies change, cancels obsolete requests, and exposes its lifecycle through reactive state such as the current value, loading status, and errors.

This makes Resources particularly well suited for read-oriented operations where data should stay synchronized with application state.

For example, changing a selected user ID can automatically trigger a new request without manually wiring switchMap or managing subscription lifecycles.

const userResource = httpResource(() => ({
  url: `/api/users/${selectedUserId()}`
}));

Signal Forms

Another major improvement is the stabilization of Signal Forms.

Traditional Reactive Forms expose their state through FormControl and FormGroup instances, requiring developers to query validation status, dirty state, touched state, and values through an imperative API.

Signal Forms expose these properties as signals instead. Every field becomes reactive by default, making templates easier to read while eliminating much of the manual state synchronization commonly found in form-heavy applications.

@if (profileForm.email.invalid() && profileForm.email.touched()) {
  <span>Please enter a valid email.</span>
}

Because field state is already reactive, components rarely need additional subscriptions or helper observables to keep the UI synchronized.

It's important to note that Signal Forms are responsible for UI state, while business operations such as saving data, loading entities, or handling server responses still belong in a dedicated service or SignalStore. Keeping these responsibilities separate results in components that remain focused on presentation while stores continue to own application logic.

Best Practices for Building Modern SignalStores

SignalStore significantly reduces the ceremony traditionally associated with state management, but the same architectural principles still apply. A well-designed store should encapsulate business logic without becoming responsible for concerns that belong elsewhere.

1. Keep Stores Focused on a Single Feature A SignalStore should represent a cohesive business feature rather than becoming a global container for unrelated state. For example, an administration module might expose separate stores for users, roles, and permissions instead of combining all administrative functionality into a single, monolithic store. Smaller stores are easier to test, understand, and maintain over time.
2. Store Business State, Not UI State Not every piece of state belongs in a store. Transient UI concerns such as dialog visibility, selected tabs, expanded panels, or temporary input values are usually better managed with plain Signals inside the component. Stores should own state that represents the application's business domain—entities, filters, permissions, settings, or data shared across multiple components.
3. Derive State Instead of Duplicating It Whenever possible, compute values instead of storing them. SignalStore's withComputed() feature makes it easy to derive reactive values from existing state, reducing the likelihood of inconsistent or stale data. Instead of storing both a list of users and an active user count, derive the count directly from the collection.

withComputed(({ users }) => ({
  activeUsers: computed(() =>
    users().filter(user => user.active).length
  ),
}))

Keeping a single source of truth simplifies updates and reduces maintenance. 4. Prefer Immutable State Updates Although SignalStore simplifies updates through patchState(), state should still be treated as immutable. Updating only the affected portions of state makes changes predictable and allows Angular's signal system to efficiently notify dependent computations.

patchState(store, {
  users: [...store.users(), newUser]
});

Integrating Resources with SignalStore

Resources and SignalStore solve different problems, and understanding their responsibilities leads to a cleaner architecture.

A Resource is responsible for synchronizing data with a remote source. It knows how to load data, react to parameter changes, expose loading and error states, and keep requests up to date.

A SignalStore, on the other hand, owns the application's business state. It coordinates operations, exposes domain-specific methods, derives computed values, and serves as the single source of truth for a feature.

Rather than replacing one another, they work best together.

A common pattern is to use a Resource for loading entities while allowing the store to expose business operations that modify those entities.

export const UserStore = signalStore(
  withState({
    selectedUserId: undefined as number | undefined,
  }),

  withComputed(({ selectedUserId }) => ({
    userResource: httpResource<User>(() => {
      const id = selectedUserId();

      return id
        ? {
            url: `/api/users/${id}`,
          }
        : undefined;
    }),
  })),

  withMethods((store) => ({
    selectUser(id: number) {
      patchState(store, {
        selectedUserId: id,
      });
    },
  })),
);

In this example, changing the selected user automatically causes the Resource to fetch new data. The store doesn't need to manage subscriptions or manually coordinate loading indicators because the Resource already exposes this information through signals.

This separation keeps data synchronization declarative while allowing the store to remain focused on business behavior.

Integrating Signal Forms with SignalStore

Signal Forms and SignalStore naturally complement one another because both are built on Angular Signals. However, they should not be treated as interchangeable.

Signal Forms are responsible for managing user input and validation, while SignalStore coordinates business operations such as loading, updating, and persisting data.

A common workflow consists of four steps:

1. Load the entity through the store.
2. Populate the Signal Form.
3. Allow the user to edit the data.
4. Submit the updated values back to the store.

The component remains responsible only for orchestrating the interaction between the form and the store.

@Component({
  // ...
})
export class UserEditorComponent {
  readonly store = inject(UserStore);

  readonly form = form({
    name: '',
    email: '',
  });

  async save() {
    if (this.form.invalid()) {
      return;
    }

    await this.store.updateUser(this.form.value());
  }
}

This approach keeps presentation concerns inside the component while allowing business rules to remain centralized in the store.

Handling Asynchronous Operations

One challenge when combining Signal Forms with SignalStore is coordinating asynchronous operations.

A form submission typically expects an asynchronous operation to complete before updating its own state. Meanwhile, the store is responsible for managing loading indicators, server errors, and successful updates.

Instead of placing HTTP requests directly inside components, expose descriptive methods such as createUser(), updateProfile(), or changePassword() from the store. Components simply invoke these methods and react to the outcome.

This keeps components lightweight while making business logic reusable across multiple views.

A Clear Separation of Responsibilities

A useful guideline is to divide responsibilities as follows:

| Concern | Recommended Owner | | ------------------- | ------------------------------------------ | | User input | Signal Forms | | Validation | Signal Forms | | Loading remote data | Resource | | Business rules | SignalStore | | State mutations | SignalStore | | HTTP persistence | Service or repository invoked by the store |

Following these boundaries results in components that focus on presentation, stores that encapsulate business logic, and Resources that handle server synchronization. Each part has a single responsibility, making the application easier to understand, test, and maintain as it grows.

Migrating from Classic NgRx to SignalStore

Migrating to SignalStore doesn't require replacing an entire application's state management strategy overnight. In fact, most enterprise applications can adopt SignalStore incrementally while continuing to use the classic NgRx Store where it provides the greatest value.

A practical migration strategy is to start with isolated features rather than the application's global state.

Keep the Classic Store for Global State

Global concerns such as authentication, user sessions, application configuration, notifications, and cross-feature communication often continue to benefit from the centralized architecture of the classic NgRx Store.

These areas typically rely on dispatched actions and event-driven workflows that remain well suited to Redux patterns.

Introduce SignalStore for New Features

New feature modules are excellent candidates for SignalStore.

Instead of creating actions, reducers, selectors, and effects, developers can define state, computed values, and business methods in a single store. This reduces boilerplate while aligning the feature with Angular's signal-first architecture.

Existing features can also be migrated gradually as they evolve, avoiding large-scale refactoring efforts.

Move Component State First

The easiest migration is often replacing component-local Observables and BehaviorSubjects with Signals.

Many components don't require a dedicated store at all. Converting temporary UI state to Signals simplifies the codebase immediately and familiarizes teams with Angular's reactive model before introducing SignalStore.

Incremental adoption minimizes risk while allowing teams to modernize applications at a sustainable pace.

What This Means for ABP Applications

Angular 22's signal-first architecture aligns well with ABP's modular application model.

Most ABP applications consist of independent feature modules such as Identity, Tenant Management, SaaS, or CMS. These modules naturally map to feature-scoped SignalStores, allowing state and business logic to remain encapsulated within each module. However, the full support will be introduced in the next version.

As Angular continues investing in Signals, Resources, and Signal Forms, future ABP applications can increasingly rely on the framework's native reactive APIs instead of custom state management patterns.

This doesn't diminish the importance of RxJS or the classic NgRx Store. RxJS remains an essential foundation of Angular's HTTP infrastructure and many third-party libraries, while the traditional Store continues to provide an excellent solution for complex global state management.

Instead, Angular 22 encourages developers to use each reactive tool where it provides the greatest value.

Whether you're upgrading an existing ABP application or starting a new project, adopting SignalStore for feature-level state can simplify development while remaining fully compatible with Angular's evolving ecosystem.

Conclusion

Angular's evolution toward a signal-first architecture represents more than a new reactive API—it changes how applications should be designed.

Rather than treating every piece of state as part of a centralized store, Angular now encourages developers to choose the appropriate abstraction for each responsibility. Plain Signals excel at local component state, SignalStore provides a lightweight solution for feature-level business logic, Resources simplify server synchronization, and Signal Forms modernize user input management.

The classic NgRx Store continues to play an important role in large, event-driven applications, but it no longer needs to be the default choice for every state management scenario.

By embracing these complementary tools, developers can build Angular applications that are simpler to maintain, require less boilerplate, and integrate naturally with the framework's latest capabilities.

As Angular continues to evolve around Signals and fine-grained reactivity, adopting these patterns today will help applications remain aligned with the framework's direction while providing a solid foundation for future improvements.

Enterprise ASP.NET Boilerplate (ABP) projects rarely stay with default theme behavior for long. At some point, teams need stricter brand alignment, user experience (UX) consistency across modules, or product-specific shell behavior that goes beyond palette and typography tweaks.

This article explains a practical way to customize the LeptonX theme in Angular projects through two primary layers :

1. Style Overriding: Utilizing design tokens, global CSS custom properties (variables), and component-level styling.
2. Element Overriding: Replacing or extending UI fragments and layout pieces using ABP's built-in services.

Finally, we connect this customization mindset to ABP’s new React direction, where application development teams own more of the user interface (UI) implementation directly from day one.

Why Overriding Matters in Real ABP Solutions

In enterprise software engineering, frontend customization is not a cosmetic task. Instead, it directly supports core technical and architectural goals :

• Brand System Compliance: Enforcing strict color palettes, layouts, and typography across tenant-facing portals and internal back-office administration pages.
• Accessibility (a11y) Improvements: Optimizing focus states, color contrast ratios, screen reader compatibility, and keyboard navigation to meet WCAG standards.
• Product Differentiation: Structuring distinct top-level layouts, sidebar behavior, and navigation elements to separate multiple products within the same suite.
• Operational Usability: Reorganizing application spaces to match domain-specific workflows and simplify intensive data-entry tasks.

To avoid building fragile CSS overrides that break during framework updates, development teams must follow a strict, highly structured hierarchy of customization :

| Level | Customization Type | Technical Mechanism | Strategic Role | | :---: | :--- | :--- | :--- | | 1 | Token-Level Variables | CSS Custom Properties | 🛡️ First Line of Defense | | 2 | Component-Style Patch | Class-Based Overrides | 🎨 Moderate Visual Tweaks | | 3 | Element Replacement | ReplaceableComponents | 🏗️ Deep Structural Overrides |

Adhering to this hierarchy reduces "style debt" and ensures that theme upgrades remain manageable throughout the application lifecycle.

Layer 1: Style Overriding in LeptonX (Angular)

Style overriding is the safest and most maintainable way to alter your application's presentation layer. The LeptonX engine relies heavily on CSS custom properties (variables) defined at the :root level.

Customizing Brand Colors and Typography Tokens

To modify the default colors and branding assets, developers can define custom properties within the global src/styles.scss file :

:root {
  /* Set the primary brand color used on active elements, buttons, and focuses */
  --lpx-brand: #1e3a8a;

  /* Set the physical paths for the application logos */
  --lpx-logo: url('/assets/images/logo.png');
  --lpx-logo-icon: url('/assets/images/logo-icon.png'); /* Displayed when sidebar is collapsed */
}

For applications utilizing multi-theme layouts (such as LeptonX Pro's Light, Dark, or Dim modes), variables can be scoped under individual theme classes to dynamically swap brand colors or assets :

/* Scoping theme-specific logos to prevent visibility issues on dark backgrounds */
:root.lpx-theme-dark, :root.lpx-theme-dim {
  --lpx-logo: url('/assets/images/logo-light.png');
  --lpx-logo-icon: url('/assets/images/logo-icon-light.png');
}

Solving the "Visual Branding Blink" on Initial Page Load

A common issue in production occurs when the default LeptonX logo is briefly displayed on screen before the client browser parses the custom stylesheet. This latency creates a noticeable "blink" or flicker.

To eliminate this rendering gap, bypass the CSS variable load phase by replacing the physical logo assets inside the web host project's public directory. Write your custom branding files directly to /images/logo/leptonx/logo-light.png inside the server's public folder. Because the fallback variable defaults directly to this location, the client browser displays the custom logo asset immediately without waiting to parse the custom CSS rules.

Additionally, note that styles registered solely in the application's global styles.scss may fail to apply to the Account Layout (such as the standard login page) because it compiles within an isolated module lifecycle. To ensure your styling overrides apply globally, register the assets and styles in the Virtual File System (VFS) of the.NET backend host, making them universally accessible across all client routing contexts.

Layer 2: Element Overriding in LeptonX (Angular)

When CSS modifications cannot support your required user experience (such as adding search interfaces, custom profile controls, or custom action layouts), teams must override the underlying UI elements.

ABP provides the ReplaceableComponentsService to dynamically replace pre-built layout pieces with custom, project-owned Angular components without breaking core module logic.

Troubleshooting the Mobile User Profile Freeze

In compiled editions of the LeptonX Lite layout library (specifically versions 3.1.x through 4.3.1), developers have identified a rendering bug affecting mobile layouts. When a user logs in via a mobile device and taps the profile dropdown menu, the page freezes. Instead of displaying the profile options, the sidebar area recursively renders a duplicate copy of the active route page. This layout loop completely breaks navigation until the page is refreshed.

The root cause is a layout bug inside the compiled LeptonX library template (mn-user-profile.component.html), where the template markup is wrapped inside an <ng-component> tag instead of a structurally neutral <ng-container> tag.

To resolve this issue, you can implement a custom component replacement :

1. Generate a custom mobile profile component using the Angular CLI

   ng g component components/my-mobile-profile
   

2. Implement the component template, ensuring the wrapper elements utilize <ng-container> instead of <ng-component>.

3. Inject the ReplaceableComponentsService into your root app.component.ts to swap the underlying component keys during application bootstrap :

   import { Component, OnInit } from '@angular/core';
   import { ReplaceableComponentsService } from '@abp/ng.core';
   import { eThemeLeptonXComponents } from '@volosoft/ngx-lepton-x';
   import { MyMobileUserProfileComponent } from './components/my-mobile-profile.component';
   
   @Component({
     selector: 'app-root',
     template: '<abp-dynamic-layout />'
   })
   export class AppComponent implements OnInit{
     private replaceableComponents = inject(ReplaceableComponentsService);
   
     ngOnInit() {
       this.replaceableComponents.add({
         component: MyMobileUserProfileComponent,
         key: eThemeLeptonXComponents.MobileUserProfile
       });
     }
   }
   

Template Context: From LeptonX Demo Setup to Real ABP Application Templates

When transitioning customized designs from local prototypes to production environments, development teams must choose between two operating modes :

| Operational Mode | Core Architecture | Rationale & Trade-offs | | --- | --- | --- | | Standard Template Mode | Consumes LeptonX packages as standard dependencies (@abp/ng.theme.lepton-x) from npm registries. All overrides are applied at the application layer. | Highly Recommended. Keeps local project codebases clean, simplifies dependency updates, and avoids style debt. | | Source-Inspection Mode | Utilizes the ABP CLI get-source command to download the raw theme code and configure temporary local path aliases. | Diagnostic Only. Best used for deep debugging, prototyping layout behaviors, or tracing framework-level bugs. |

Resolving Strict MIME Type CSS Loading Exceptions

During local development or initial production deployments of LeptonX Lite Angular applications, browsers may refuse to apply the theme's styles. This issue manifests as a console exception:

Refused to apply style from 'http://localhost:4200/bootstrap-dim.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

This error occurs when the browser requests static layout stylesheets from paths that do not exist, causing the back-end host to return a default 404 HTML fallback page. To resolve this, run the installation command in your client-side workspace :

abp install-libs

This command forces the ABP CLI to parse package dependencies, copy the compiled stylesheets directly into the physical output directories, and make them available to the web server.

Deep Implementation: Integrating Theme Source Code and the Upgrade Trade-Off

For complex enterprise scenarios requiring structural changes that cannot be achieved via standard token configurations or component replacements, developers have the option to bypass compiled packages entirely and integrate the theme’s raw source code.

How to Retrieve the Source Code

ABP Commercial customers have full access to the complete source code of the LeptonX Pro theme. This can be downloaded directly through the ABP Suite user interface or by executing the following command in the ABP CLI within your project directory :

abp get-source Volo.Abp.LeptonXTheme

This command downloads the raw C# and Angular source files directly into your local solution structure. Once downloaded, you can modify the underlying HTML templates, restructure Angular modules, and alter core layout scripts to meet your product requirements.

The Upgrade Warning: Maintenance Overhead and Style Debt

While direct access to the source code provides complete design freedom, it comes with a major warning regarding long-term maintenance :

• Bypassing the Update Stream: Once you replace official package references (such as @volosoft/abp.ng.theme.lepton-x or NuGet packages) with local project references, your application is disconnected from the automatic update pipeline.
• Manual Merge Burden: When Volosoft releases framework updates, security patches, or compatibility fixes (such as aligning with newer Angular or.NET compiler baselines), these updates will not automatically apply to your customized code. Your team must manually compare, diff, and merge upstream changes, which can introduce regressions and increase technical debt.
• VFS and APIs as the First Line of Defense: Before choosing a full source code integration, try using the Virtual File System (VFS) on the backend or standard component replacement APIs in the frontend to override only the specific elements you need to change. This allows you to customize the UI while keeping the rest of your theme packages fully upgradeable.

Connecting the Mindset to ABP’s New React Era

The introduction of the React UI option in ABP 10.4 represents a major architectural shift. While the Angular implementation relies on structured layout packages and runtime component overrides, the React architecture prioritizes direct developer ownership of the presentation layer.

graph TD
    %% Styling
    classDef react fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px,color:#0d47a1;
    classDef dotnet fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px,color:#4a148c;
    classDef proxy fill:#fff3e0,stroke:#fb8c00,stroke-width:2px,color:#e65100;
    classDef tool fill:#f5f5f5,stroke:#757575,color:#333;

    %% React App Box
    subgraph ReactApp ["React App Repository"]
        C1["Custom Business Components<br><small>(Local Source Code)</small>"]:::react
        C2["TanStack Router & Query<br><small>(Type-Safe Client Routes)</small>"]:::react
        
        T1["Vite Dev Server & Bundling<br><small>(Fast HMR, Vitest)</small>"]:::tool
        T2["Tailwind CSS / shadcn/ui<br><small>(Accessible UI Components)</small>"]:::tool

        C1 --> C2
        T1 --> T2
    end

    %% Backend Box
    subgraph NetCore ["ASP.NET Core Web API Host"]
        P1["Dynamic API Client Proxies<br><small>(Auto-Generated Endpoints)</small>"]:::proxy
        A1["ABP Admin Console<br><small>(Delivered via NuGet)</small>"]:::dotnet

        P1 <==> A1
    end

    %% Inter-Repository Flow
    ReactApp -- "Generates Dynamic Proxies" --> P1

    %% Layout Tweaks
    style ReactApp fill:#fafafa,stroke:#1e88e5,stroke-width:1px,stroke-dasharray: 5 5;
    style NetCore fill:#fafafa,stroke:#8e24aa,stroke-width:1px,stroke-dasharray: 5 5;

What Stays Consistent vs. What Changes

Understanding how patterns transfer between frameworks is key for teams migrating to the React UI:

• What Stays Consistent: Core DDD infrastructure, backend integration, dynamic API proxy generation, multi-tenancy models, and permission-aware routing configurations.
• What Changes: Direct ownership of page layouts, faster iteration of UI composition, and modern utility-first styling tools.

A New Frontend Philosophy

In the Angular model, developers import pre-built layouts from compiled packages and selectively override elements using classes or replacing components. While structured, this approach can sometimes feel like "fighting" the framework.

The React UI model, by contrast, gives developers direct control over the UI components from day one. Standard administrative pages (such as Identity, Tenants, and Settings) are managed separately by the ABP Admin Console on the back-end host, while all application layouts and views remain locally in your React project.

Built with modern tools like Vite, Tailwind CSS, and shadcn/ui, developers can customize and extend components directly in their local source files without needing complex overriding wrappers.

Additionally, because the layout and page templates reside in local source directories rather than compiled packages, this architecture is highly optimized for AI-driven development. Automated coding agents (such as the ABP Studio AI Agent) can easily inspect and modify local layouts, run API proxy generation, and deploy updates quickly.

Whether your enterprise solution leverages the structured, component-driven architecture of ABP's Angular UI or is stepping into the modern, developer-owned era of the Vite-powered React UI , establishing an intentional, upgrade-safe customization strategy is crucial. By resolving design changes through token-level custom properties first, documenting structural element overrides, and preparing public-facing technical resources to be highly citable by conversational search agents , development teams can insulate their codebases from technical debt. Ultimately, the transition from rigid theme packages to direct frontend ownership not only streamlines day-to-day software delivery but also ensures that your application framework remains flexible, performant, and visible in an AI-driven ecosystem.

Generic AI coding tools can write code really fast. They often leave chunks that do not fit your framework and become expensive to maintain later. The ABP AI Coding Agent in ABP Studio aims at a different outcome. Hence, it understands ABP solution structure, follows project rules, plans before large changes, and leaves a codebase you can always extend.

This article is a real build story. Hanova is a home-services booking sample serving customer and provider roles, using MongoDB, Redis, SignalR, React Native mobile UI, and demo seed data for both personas on first migrate.

1. Why “fast” is not enough

Hanova is built on the ABP Framework: pick a role, browse open jobs or specialists, send a request, negotiate the price, and message through to confirmation. Log in as ayse.kaya or mehmet.yilmaz (password Demo@1234) after a single database migrate, and every tab already has something on it.

That end-to-end loop is what I wanted to ship. What I did not want was a repository that only looked finished on day one.

The speed trap

AI-assisted development is good at the first sunny-day build. Ask for a booking screen, a REST endpoint, a chat list,and you get code quickly. The problem shows up on the second request: “Add negotiation,” “Wire SignalR,” “Enforce permissions on confirm,” “Seed demo users so QA can log in.”

Without framework context, each prompt tends to invent its own pattern:

• A new API style instead of an application service + permission
• Direct database access instead of repositories
• A one-off WebSocket layer instead of extending the hub already in the module

The app may still run. However, every new feature fights the last one. Review time goes up. The next developer, or the next agent session spend half the effort re-learning what the previous session improvised. That is fast but fragile. In other words you sustain the velocity today, but you will have to do the rework tomorrow.

What “efficient” and “sustainable” meant here

I used the ABP AI Agent inside Studio, not as generic autocomplete, but as a teammate that already knows where entities, app services, permissions, and Mongo collections live in a single-layer solution.

The goal was fast and sustainable:

• New work lands in the same folders and conventions as the template
• Bookings, messaging, and negotiation share one lifecycle and one real-time hub
• Demo data stays idempotent so migrate-and-run stays trustworthy
• The next feature extends the same graph instead of patching around it

What made agent-assisted development stick was not raw generation speed. It was working inside ABP’s structure with plans, project rules, skills, and safety rails. So, the codebase still reads like an ABP application even months later.

Takeaway: Treat AI as a delivery accelerator only when it preserves your framework conventions. Otherwise you trade tomorrow’s velocity for today’s demo.

2. Template vs. product

Hanova was scaffolded from the ABP single-layer application template: one .NET project, MongoDB, OpenIddict auth, Admin Console, React SPA scaffold, React Native shell, and English + Turkish localization. That is a lot of plumbing. It is also not the product.

What the template already carried

| Area | Already in the box | |------|-------------------| | Identity & auth | Users, roles, OpenIddict clients, token flow | | Authorization | Permission groups, role seeding (Customer, Provider) | | Host & ops | Run profiles, --migrate-database, Docker files | | Mobile & web shell | Expo auth/tabs/settings; Vite React login and identity | | Sample CRUD | Books — proof that entity → app service → UI works |

The Books sample is just a reference slice, not product scope. Hanova’s booking flow follows the same shape. The domain changed, but the skeleton did not. Login, OAuth, theming, and navigation did not need to be re-specified in every prompt.

What the agent had to grow

Backend: service categories, customer and provider profiles, service areas, bookings, negotiation, messaging hub, and supporting domains (payments, settlements, verification) toward full workflows.

Mobile (primary UI): role entry, customer tabs (Discovery, Bookings, Messages, Account), provider tabs (Job feed, Bookings, Messages, Earnings, Account), plus booking, negotiation, chat, and profile screens.

Demo glue: two personas, pending and confirmed bookings, and a message thread so migrate-and-run populates every tab.

Template: auth, permissions, navigation, theming, sample CRUD pattern.
Product: who books whom, for what service, at what price, with what conversation attached.

When a prompt said “add provider job feed,” the answer was not a new auth stack. It was a new app service, permissions, and screens inside existing patterns.

3. Why a framework-native agent matters

Once the assistant was ABP-native inside Studio, day-to-day work changed. The agent sees module layout, run profiles, permissions, and Mongo registration before it edits. For Hanova, that meant fewer wrong first drafts and fewer “throw this away and wire it properly” passes.

One workspace instead of five tabs

A typical feature would have to cross backend, mobile, and ops. Simply; add a permission, run migrate after seed changes, reload Expo, read the runtime monitor when SignalR did not connect. In Studio, the same session moves from “implement confirm rules” to “run migrator” to “why did this 403?” without re-explaining the whole stack each time.

Semantic search over a growing graph

A booking links to a provider profile, a conversation, hub groups, and mobile state. Prompts rarely name every path. Indexed search tended to land on existing job feed, booking, and hub code instead of inventing parallel endpoints. Generic tools often solve the literal sentence, not the graph it sits in.

What the agent could lean on

| Hanova need | Agent advantage | |-------------|-----------------| | Booking + confirm rules | Same vertical pattern as Books; permissions on mutating operations | | Provider job feed | Query existing bookings by provider specializations—not a second “job” store | | Messaging & negotiation | Extend the existing messaging hub, not a new socket stack | | Runnable demo | --migrate-database and idempotent seed personas | | Auth or SignalR failures | Runtime monitor output fed back into the same chat |

Efficiency came from correct first guesses in ABP-shaped folders. So, this is beyond typing speed alone.

4. Keeping the codebase maintainable

Speed only pays off if the repo is still understandable after the tenth session. Sustainability meant every agent turn adds to the same architecture, not forks a new one.

Plan before Agent mode

Multi-surface work needs a shared map first. Plan mode produces affected files, steps, and test notes before edits.

| Without a plan | With an approved plan | |----------------|----------------------| | Orphan DTOs with no app service | Full vertical slice through API and permissions | | A second hub for “quick” push | Extend the existing messaging hub | | Mobile calling an unauthorized endpoint | Permission grants listed as plan steps |

There is no multi-entity Agent running without a checked plan.

Rules, guardrails, and vertical slices

Every new chat starts with zero memory. Project rules (ABP conventions + Hanova-specific orientation) encode how we build: repositories in app services, localized business exceptions, Mapperly mappings are not renegotiated each session.

| Control | Role | |---------|------| | .abpignore | Keeps secrets and certs out of agent context | | AI Scopes | Backend vs mobile folders when refactoring | | Permission prompts | Shell and fetch require approval with a reason | | Git snapshot revert | Roll back a bad turn without diff archaeology |

5. Lessons learnt — one example (provider job feed)

The job feed is where a provider sees customers’ open booking requests where the clearest place to see the full loop in practice.

What we did

| Step | What happened | |------|----------------| | 1. Plan | Reuse existing bookings (no duplicate “job” table), filters, API + mobile screen, permissions, expected demo outcome | | 2. Verify the plan | Read, adjust, approve, no code until this passes | | 3. Agent | Implement, migrate, start API; fix permission error using runtime monitor in the same chat | | 4. Verify the implementation | Seeded provider → Jobs tab shows matching open requests—not all, not none | | 5. Recover (if needed) | Snapshot revert + narrower AI Scope, same plan |

Studio setup around the slice

These controls mattered as much as the prompt:

• Rules & workflows — ABP single-layer conventions and a repeatable slice checklist
• Skills — inject the checklist so each session does not start from zero

• AI Scope — jobs API + provider screens only; smaller scope on recover

• Models & thinking — lighter for Plan/review, deeper for cross-layer Agent work
• MCP (optional) — extra context when the answer lives outside the repo
• .abpignore — secrets stay out of context

What we learnt from this slice

The plan had to cover the whole slice, not just the API. Permissions, role grants in seed data, and the mobile list were all part of job feed. Reviewing the plan caught the grant step before Agent mode. Otherwise, the provider hits “access denied” even when the API looks finished.

Plan the API and the screen together. Filters exist on the phone and on the server. Backend-only plans often yield a working API and a list that shows nothing, or everything.

Know what “working” looks like before you test. Demo data defines success: several open customer requests; provider set up for plumbing and electrical work. Write that into the plan so verification is pass/fail.

Recover execution, keep the plan. When a session edits unrelated auth settings, revert and retry with a tighter scope rather than throwing away the approved plan.

Negotiation, messaging, and other features followed the same loop.

6. ABP AI Agent vs generic coding assistants

Generic tools (Cursor, Claude Code, Windsurf) are strong for editing code. The ABP agent is built for ABP delivery inside Studio. The goal is similar, but the default context is quite different. Hanova is one of the proof case. It is not about “who writes faster,” but what you re-do less.

| Dimension | Generic assistant | ABP AI Agent (Hanova) | |-----------|-------------------|------------------------| | Solution shape | Inferred from open files | Single-layer layout, modules, run profiles in context | | Permissions | Often missing or hardcoded | Defined, authorized, and seeded as part of the slice | | Database & demo data | Easy to pick the wrong approach | --migrate-database, seed contributors, idempotent demo users | | Real-time features | Temptation to add a parallel socket stack | Extend existing hub and module wiring | | Docs & conventions | Web search or pasted snippets | ABP docs subagent + project rules and workflows | | Session control | Usually whole repo | AI Scopes, .abpignore, approval prompts | | When a turn goes wrong | Git history | Git + per-turn snapshot revert | | Run & debug | Separate terminal / browser | Start app, migrate, runtime monitor in the same chat |

Generic tools still excel at quick edits and experiments in any stack. We are not claiming Studio replaces them. Use a generic assistant when the problem is “code.” Use the ABP agent when the problem is shipping an ABP feature end to end.

7. Template in, product out

Hanova started as an ABP template and became a working app: two roles, bookings, messaging, demo data on first migrate. The agent did not replace thinking, but it significantly shortened the gap between a feature idea and something you can run, review, and extend without breaking coding conventions.

Who this workflow fits

• Developers — Plan → verify plan → Agent → verify with demo data; rules early, scopes when a turn goes wide
• Team leads — Shared workflows, .abpignore, snapshot policy, scopes
• Product owners — Plans as reviewable artifacts; demo seed as a visible acceptance check

Hanova still has room to grow (payments, settlements, verification). The agent accelerates slices you prioritize, not the whole backlog at once.

You can try it yourself: Download ABP Studio · ABP AI Coding Agent

The template carried authentication and navigation. The agent carried what turned Hanova into a product inside ABP, not beside it.

Every mobile developer eventually hits the "Localhost Wall." You have built a brilliant API on your machine, and your React Native app works perfectly in the iOS Simulator or Android Emulator. But the moment you pick up a physical device to test real-world performance or camera features, everything breaks.

The Problem: Why Your Phone Can’t See localhost

When you run a backend server on your computer, localhost refers to the "loopback" address and essentially, the computer talking to itself. Your physical iPhone or Android device is a separate node on the network. From its perspective, localhost is itself, not your development machine. Without a direct bridge, your mobile app is shouting into a void, unable to reach the API sitting just inches away on your desk.

The Conflict: The Fragility of Local IP Addresses

The traditional workaround is to find the local IP address of your device and hardcode it into your app. However, this approach has many obstacles that make it difficult to use:

• Network Volatility: Your router might assign you a new IP address tomorrow, forcing you to update your code constantly.
• The SSL Headache: Modern mobile operating systems and many OAuth providers (like Google or Auth0) strictly require HTTPS. Running a local development server with valid SSL certificates is a notorious configuration nightmare.
• Broken OAuth flows: Most authentication providers refuse to redirect to a non-secure http address or a random local IP, effectively locking you out of testing login features on a real device.

The Solution: Cloudflare Tunnel as a Secure Bridge

This is where Cloudflare Tunnel changes the game. Instead of poking holes in your firewall or wrestling with self-signed certificates, Cloudflare Tunnel creates a secure, outbound-only connection between your local machine and the Cloudflare edge.

It provides you with a public, HTTPS-enabled URL (e.g., https://random-word.trycloudflare.com) that automatically points to your local port. To your mobile device, your local backend looks like a standard, secure production API. It bypasses network restrictions, satisfies SSL requirements, and—when paired with a simple automation script—makes "localhost" development on physical devices completely seamless.

1. Architecture Overview

In order to understand why this setup is so effective, it is better to visualize the data flow. Traditionally, your mobile device would try to ping your laptop directly over Wi-Fi that is often blocked by firewalls or complicated by internal IP routing.

Workflow Summary: The Secure "Middleman"

The Cloudflare Tunnel acts as a persistent, encrypted bridge between your local environment and the public internet. Here is how the traffic flows in a standard development session:

1. The Connector: You run a small cloudflared daemon on your development machine. It establishes an outbound connection to Cloudflare’s nearest edge server. Because it is outbound, you don't need to open any ports on your home or office router.
2. The Public Endpoint: Cloudflare provides a temporary, unique HTTPS URL (e.g., https://example-tunnel.trycloudflare.com). This URL is globally accessible.
3. The Mobile Request: Your React Native app that is running on a physical iPhone or Android sends an API request to that HTTPS URL. To the phone, this looks like any other secure production website.
4. The Local Handoff: Cloudflare receives the request and "tunnels" it down the active connection to your machine. The cloudflared tool then forwards that request to your local backend whether it's running on .NET at port 44358, Node.js at 3000, or Rails at 3000.
5. The Response: Your backend processes the request and sends the data back through the same tunnel to the phone.

By sitting in the middle, Cloudflare handles the SSL termination and the Global Routing, ensuring your backend is reachable regardless of whether your phone is on the same Wi-Fi as your laptop.

2. Prerequisites

Before we bridge the gap between your mobile device and your local machine, ensure your development environment is equipped with the following core components.

To follow this guide, you will need:

• Node.js & Package Manager: A stable version of Node.js (LTS recommended) and either npm or yarn to manage dependencies and run the automation scripts.
• Expo CLI: Ensure you have the latest version of expo installed globally or within your project. We will be using this to manage the development server and build the application.
• Cloudflared CLI: This is the critical "connector" tool from Cloudflare. You’ll need it installed on your local machine to establish the tunnel.
  • Quick Tip: You don't need a paid Cloudflare account; the Quick Tunnels used in this guide are free and require no login.
• A Running Backend API: Your local server (e.g., .NET, Node.js, Django, or Rails) should be active and listening on a specific port (like 44358 or 3000).

3. Step-by-Step Implementation

Now, let’s configure the automation that makes this workflow "set it and forget it."

Phase A: Backend Configuration (The OAuth Handshake)

Modern mobile authentication often relies on OAuth 2.0 or OpenID Connect. For the login flow to succeed, your backend must "trust" the redirect URI sent by the mobile app. ABP applications are an example for such handshake.

Even though we are using a Cloudflare URL for the API calls, the auth-session of Expo typically generates a localhost redirect for development. You must update your backend configuration (e.g., appsettings.json in a .NET TemplateTwo setup) to allow this:

File: src/YourProject.DbMigrator/appsettings.json

{
  "OpenIddict": {
    "Applications": {
      "Mobile_App": {
        "ClientId": "Mobile_App",
        "RootUrl": "exp://localhost:19000"
      }
    }
  }
}

Note: By setting the RootUrl to exp://localhost:19000, you ensure that once the user authenticates via the tunnel's secure page, the mobile OS knows exactly how to hand the token back to your running Expo instance.

Phase B: The "Magic" Script (Automating the Tunnel)

The primary headache with free Cloudflare Tunnels is that they generate a random URL every time you restart the service. Manually copying https://shiny-new-url.trycloudflare.com into your frontend code every morning is a productivity killer.

We solve this with a Node.js automation script that launches the tunnel, "listens" to the terminal output to find the new URL, and automatically injects it into your project's configuration.

File: react-native/scripts/tunnel.js

const { spawn } = require('child_process');
const fs = require('fs');
const path = require('path');

// Target files for automation
const tunnelConfigFile = path.join(__dirname, '..', 'tunnel-config.json');
const environmentFile = path.join(__dirname, '..', 'Environment.ts');

// 1. Launch the Cloudflare Tunnel pointing to your local API port
const cloudflared = spawn('cloudflared', ['tunnel', '--url', 'http://localhost:44358']);

let domainCaptured = false;

cloudflared.stdout.on('data', data => {
  const output = data.toString();
  console.log(output); // Keep logs visible for debugging

  if (!domainCaptured) {
    // 2. Regex to catch the dynamic "trycloudflare" URL
    const urlMatch = output.match(/https:\/\/([a-z0-9-]+\.trycloudflare\.com)/);
    if (urlMatch) {
      const domain = urlMatch[1];
      
      // 3. Save to a JSON file for the app to read
      fs.writeFileSync(tunnelConfigFile, JSON.stringify({ domain }, null, 2));
      
      // 4. Update the fallback value in Environment.ts directly
      let envContent = fs.readFileSync(environmentFile, 'utf8');
      envContent = envContent.replace(
        /let tunnelDomain = '[^']*'; \/\/ fallback/,
        `let tunnelDomain = '${domain}'; // fallback`,
      );
      fs.writeFileSync(environmentFile, envContent, 'utf8');
      
      console.log(`\n✅ Tunnel Synchronized: ${domain}`);
      domainCaptured = true;
    }
  }
});

By capturing the trycloudflare.com domain programmatically, we treat the tunnel like a dynamic environment variable. This ensures that your mobile app, your backend OAuth settings, and your API client stay in perfect sync without a single keystroke from you.

Phase C: Environment Integration

To make this work within your React Native code, your Environment.ts file needs to be "smart" enough to look for the generated config file. We use a try/catch block so the app doesn't crash if the tunnel isn't running.

File: react-native/Environment.ts

let tunnelDomain = 'your-default-fallback.com'; // fallback

try {
  // Pull the latest domain from the script's output
  const tunnelConfig = require('./tunnel-config.json');
  if (tunnelConfig?.domain) {
    tunnelDomain = tunnelConfig.domain;
  }
} catch (e) {
  console.warn('⚠️ No active tunnel config found. Using fallback.');
}

const apiUrl = `https://${tunnelDomain}`;

export const getEnvVars = () => {
  return {
    apiUrl,
    // Other environment variables...
  };
};

This setup creates a "Single Source of Truth." When you run the script, it updates tunnel-config.json, and your app instantly points to the correct secure endpoint.

4. Integration with Expo Development Builds

While you can technically use the standard Expo Go app for basic API testing, professional React Native workflows, especially those involving secure authentication and custom networking, rely on Expo Development Builds.

Why Development Builds are Essential for This Workflow

Standard Expo Go is a "one-size-fits-all" sandbox. However, as your app grows, it needs to behave more like a real, standalone binary. Development Builds are preferred for two main reasons:

• Custom URL Schemes: For OAuth flows (like the one configured in Phase A), your app needs to handle specific deep links (e.g., myapp://). Expo Go has its own internal URL handling that can sometimes conflict with complex redirect logic. A Development Build allows you to define your own scheme, ensuring the Cloudflare-tunneled backend knows exactly where to send the user back after login.
• Native Dependency Control: If your app uses native modules for secure storage, biometrics, or advanced networking, Expo Go won't support them. A Development Build includes your project's specific native code while still giving you the "hot reloading" developer experience of Expo.

Configuring the Build for Tunnelling

To ensure your development build is ready for the Cloudflare tunnel, you'll typically use the expo-dev-client package. This transforms your app into a powerful developer tool that can switch between different local or tunneled environments on the fly.

Pro Tip: When you run npx expo start, your Development Build will look for the apiUrl we configured in Environment.ts. Since our script has already injected the Cloudflare URL, the physical device will connect to your local backend through the tunnel the moment the app loads.

5. Execution Workflow

To get your entire stack synchronized, follow this specific launch order. This ensures the tunnel is active and the configuration files are updated before the React Native app attempts to read them.

Step 1: Start the Backend

Fire up your API (e.g., .NET, Node, Go). Ensure it is listening on the port defined in your tunnel.js (e.g., 44358).

Step 2: Launch the Tunnel

In a new terminal, run your automation script.

Wait for the message: ✅ Tunnel Synchronized. This confirms tunnel-config.json has been updated with the new trycloudflare.com domain.

Step 3: Start Expo

Finally, start your Expo development server:

npx expo start

Open the app on your physical device by scanning the QR code. Your app is now communicating with your local machine over a secure, global HTTPS bridge.

6. Troubleshooting & Best Practices

Even with automation, networking can be finicky. If your app isn't reaching the API, check these common roadblocks:

Common Pitfalls

• Port Mismatches: Ensure the port in your tunnel.js script (e.g., 44358) exactly matches the port your backend is listening on. If your backend uses HTTPS locally, ensure the tunnel command reflects that (e.g., https://localhost:port).
• Firewall & Ghost Processes: Sometimes a previous cloudflared process hangs in the background. If you can't start a new tunnel, kill existing processes or check if your local firewall is blocking cloudflared from making outbound connections.
• Expired Sessions: Free "Quick Tunnels" are temporary. If you leave your computer on overnight, the tunnel might disconnect. Simply restart the script to generate a fresh, synced URL.

Security Note

Cloudflare Tunnels create a publicly accessible URL. While the random strings in trycloudflare.com provide "security through obscurity," anyone with that link can hit your local API.

• Development Data Only: Never use this setup with production databases or sensitive PII (Personally Identifiable Information).
• Disable When Idle: Close the tunnel terminal when you aren't actively developing to shut the "bridge" to your machine.

7. Conclusion & Future-Proofing

By replacing hardcoded local IPs with a dynamic Cloudflare Tunnel, you’ve transformed a clunky, manual process into a "Set it and forget it" workflow. You no longer have to worry about shifting Wi-Fi addresses or SSL certificate errors on physical devices. Your development environment now mirrors the behavior of a production app, providing more accurate testing and faster debugging.

The Road to Production: EAS

This tunneling strategy is the perfect companion for EAS (Expo Application Services). As you move toward testing internal distributions, you can use these same environment patterns to point your EAS-built binaries to various staging or development endpoints.

With a secure bridge and an automated config, you are no longer tethered to a simulator. Grab your phone, head to a coffee shop, and keep building—your backend is now globally (and securely) following you.

Managing local libraries and path references in Angular projects has evolved significantly with the introduction of the new Angular application builder. What once required manual path mappings, fragile symlinks, and node_modules references is now more structured, predictable, and aligned with modern TypeScript and workspace practices. This guide walks through how path mapping works, how it has changed, and the best ways to link and manage your local libraries in brand new Angular ecosystem.

Understanding TypeScript Path Mapping

Path aliases is a powerful feature in TypeScript that helps developers simplify and organize their import statements. Instead of dealing with long and error-prone relative paths like ../../../components/button, you can define a clear and descriptive alias that points directly to a specific directory or module.

This configuration is managed through the paths property in the TypeScript configuration file (tsconfig.json), allowing you to map custom names to local folders or compiled outputs. For example:

// tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "@my-package": ["./dist/my-package"],
      "@my-second-package": ["./projects/my-second-package/src/public-api.ts"]
    }
  }
}

In this setup, @my-package serves as a shorthand reference to your locally built library. Once configured, you can import modules using @my-package instead of long relative paths, which greatly improves readability and maintainability across large projects.

When working with multiple subdirectories or a more complex folder structure, you can also use wildcards to create flexible and dynamic mappings. This pattern is especially useful for modular libraries or mono-repos that contain multiple sub-packages:

// tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "@my-package/*": ["./dist/my-package/*"]
    }
  }
}

With this approach, imports like @my-package/utils or @my-package/components/button will automatically resolve to the corresponding directories in your build output. This makes your codebase more maintainable, portable, and consistent. This is useful especially when collaborating across teams or working with multiple libraries in the same workspace.

Step-by-Step Examples of Path Configuration

As this example provides a glimpse for the path mapping, this is not the only way for the aliases. Here are the other ways to utilize this feature.

1. Using package.json Exports for Library Mapping

   When developing internal libraries within a mono-repo, another option is to use the exports field in each library’s package.json

   This allows Node and modern bundlers to resolve imports cleanly when consuming the library, without depending solely on TypeScript configuration.

   // dist/my-lib/package.json
   {
     "name": "@my-org/my-lib",
     "version": "1.0.0",
     "exports": {
       ".": "./index.js",
       "./utils": "./utils/index.ts"
     }
   }
   

   import { formatDate } from "@my-org/my-lib/utils";
   

   This approach becomes especially powerful when publishing your libraries or integrating them into larger Angular mono-repos. Because, it aligns both runtime (Node) and compile-time (TypeScript) resolution.

2. Linking Local Libraries via Symlinks

   If you want to use a local library that is not yet published to npm, you can create a symbolic link between your library’s dist output and your consuming app.

   This is useful when testing or developing multiple packages in parallel.

   You can create a symlink using npm or yarn:

   # Inside your library folder
   npm link
   
   # Inside your consuming app
   npm link @my-org/my-lib
   

   This effectively tells Node to resolve @my-org/my-lib from your local file system instead of the npm registry.

   However, note that symlinks can sometimes lead to path resolution issues with certain Angular build configurations, especially before the new application builder. With the latest builder improvements, this approach is becoming more stable and predictable.

3. Combining Path Mapping with Workspace Configuration

   In a structured Angular workspace, especially one created with Nx or Angular CLI using multiple projects, you can combine the approaches above.

   For instance, your tsconfig.base.json can define local references for in-repo libraries, while each library’s package.json provides external mappings for reuse outside the workspace.

   This hybrid setup ensures that:

   • The workspace remains easy to navigate and refactor locally.
   • External consumers (or CI builds) can still resolve imports correctly once libraries are built.

   For larger Angular projects or mono-repos, Workspaces (supported by both Yarn and npm) offer a clean way to manage multiple local packages within the same repository. Workspaces automatically link internal libraries together, so you can reference them by name instead of using manual file: paths or complex TypeScript aliases. This approach keeps dependencies consistent, simplifies cross-project development, and scales well for enterprise or multi-package setups.

Each of these methods has its strengths:

• TypeScript paths: This is great for local development and quick imports.
• package.json exports: This is ideal for libraries meant to be distributed.
• Symlinks: These are convenient for local testing between projects.

Choosing the right one, or even combining them depends on the scale of your project and whether you are building internal libraries, or a full mono-repo setup.

How Path References Worked Before the New Angular Application Builder

Angular used to support path aliases to the locally installed packages by referencing to the node_modules folder like this:

// tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "@angular/*": ["./node_modules/@angular/*"]
    }
  }
}

However, this approach is not recommended, hence not supported, by the TypeScript. You can find detailed guidance on this topic in the TypeScript documentation, which notes that paths should not reference mono-repo packages or those inside node_modules: Paths should not point to monorepo packages or node_modules packages.

Giving a real life example would explain the situation better. Suppose that you have such structure:

• Amain angular app that consumes several npm dependencies and holds registered local paths that reference to another library locally like this:

  // angular/tsconfig.json
  {
    "compileOnSave": false,
    "compilerOptions": {
      "paths": {
        "@abp/ng.identity": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/src/public-api.ts"
        ],
        "@abp/ng.identity/config": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/config/src/public-api.ts"
        ],
        "@abp/ng.identity/proxy": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/proxy/src/public-api.ts"
        ]
      }
    }
  }
  

  This simply references to this package physically https://github.com/abpframework/abp/tree/dev/npm/ng-packs/packages/identity

• This library is also using these dependencies

  // npm/ng-packs/packages/identity/package.json
  {
    "name": "@abp/ng.identity",
    "version": "10.0.0-rc.1",
    "homepage": "https://abp.io",
    "repository": {
      "type": "git",
      "url": "https://github.com/abpframework/abp.git"
    },
    "dependencies": {
      "@abp/ng.components": "~10.0.0-rc.1",
      "@abp/ng.permission-management": "~10.0.0-rc.1",
      "@abp/ng.theme.shared": "~10.0.0-rc.1",
      "tslib": "^2.0.0"
    },
    "publishConfig": {
      "access": "public"
    }
  }
  

  As these libraries also have their own dependencies, the identity package needs to consume them in itself. Before the application builder migration, you could register the path configuration like this

  // angular/tsconfig.json
  {
    "compileOnSave": false,
    "compilerOptions": {
      "paths": {
        "@angular/*": ["node_modules/@angular/*"],
        "@abp/*": ["node_modules/@abp/*"],
        "@swimlane/*": ["node_modules/@swimlane/*"],
        "@ngx-validate/core": ["node_modules/@ngx-validate/core"],
        "@ng-bootstrap/ng-bootstrap": [
          "node_modules/@ng-bootstrap/ng-bootstrap"
        ],
        "@abp/ng.identity": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/src/public-api.ts"
        ],
        "@abp/ng.identity/config": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/config/src/public-api.ts"
        ],
        "@abp/ng.identity/proxy": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/proxy/src/public-api.ts"
        ]
      }
    }
  }
  

  However, the latest builder forces more strict rules. So, it does not resolve the paths that reference to the node_modules causing a common DI error as mentioned here:

  • https://github.com/angular/angular-cli/issues/31395
  • https://github.com/angular/angular-cli/issues/26901
  • https://github.com/angular/angular-cli/issues/27176

In this case, we recommend using a symlink script. You can reach them through this example application: 🔗 Angular Sample Path Reference

These scripts help you share dependencies from the main Angular app to local library projects via symlinks:

• symlink-config.ps1 centralizes which library directories to touch (e.g., ../../modules/Volo.Abp.Identity/angular/projects/identity) and which packages to link (e.g., @angular, @abp, rxjs)
• setup-symlinks.ps1 reads that config and, for each library, creates a node_modules folder if needed and symlinks only the listed packages from the node_modules of the app to avoid duplicate installs
• remove-symlinks.ps1 cleans up by deleting those library node_modules directories so they can use their own local deps again
• In angular/package.json, the symlinks:setup and symlinks:remove npm scripts simply run those two PowerShell scripts so you can execute them conveniently with your package manager.

Best Practices and Recommendations

As we have explained each way of path mapping, this part of the article aims to summarize the best practices. Here are the points you need to consider:

• Prefer workspace references for large projects and mono-repos.
• Use TypeScript path aliases only for local development convenience.
• Strictly avoid referencing node_modules directly; let the Angular builder manage package resolution.
• Maintain consistent library structures with clear package.json exports for reusable libraries.
• Automate symlink creation/removal if needed to reduce manual errors.

Here is the list of common pitfalls and how you could troubleshoot them:

• DI errors after path configurations for typescript config: Ensure that only one copy of each library is resolved. Avoid duplicate modules by checking node_modules and symlinks.
• IDE not recognizing aliases: Confirm that tsconfig.json or tsconfig.base.json includes the correct paths configuration and that your IDE is using the correct tsconfig.
• Build errors with old paths: Migrate paths pointing to node_modules to either workspace references or local library paths.
• Symlink issues in CI/CD: Use automated scripts to create/remove symlinks consistently; do not rely on manual linking.
• Module resolution conflicts: Check library dependencies for mismatched versions and align them using a package manager workspace strategy.

As Angular’s build system continues to mature, developers are encouraged to move away from outdated path configurations and manual symlink setups. By embracing workspace references, consistent library exports, and TypeScript path mapping, teams can build scalable, maintainable applications without wrestling with complex import paths or dependency conflicts. With the right configuration, local development becomes faster, cleaner, and far more reliable.

Frontend development keeps evolving at an incredible pace, and with every new update, our implementation standards improve as well. But even as tools and frameworks change, the core principles stay the same, and one of the most important is reusability.

Reusability means building components and utilities that can be used in multiple places instead of using the same logic repeatedly. This approach not only saves time but also keeps your code clean, consistent, and easier to maintain as your project grows.

Angular fully embraces this idea by offering modern features like standalone components, signals, hybrid rendering, and component-level lazy loading.

In this article, we will explore how these features make it easier to build reusable UI components. We will also look at how to style them and organize them into shared libraries for scalable, long-term development.

🧩 Breaking Down Components for True Reusability

The first approach to make an Angular component reusable is to use standalone components. As this feature has been supported for a long time, it is now the default behavior for the latest Angular versions. Keeping that in mind, we can ensure reusability by separating a big component into smaller ones to make the small pieces usable across the application.

Here is a quick example:

Imagine you start with a single UserProfileComponent that does everything including displaying user info, recent posts, a list of friends, and even handling profile editing.

// 📖 Compact user profile component
import { Component } from "@angular/core";

@Component({
  selector: "app-user-profile",
  template: `
    <section class="profile">
      <div class="header">
        <img [src]="user.avatar" alt="User avatar" />
        <h2>{{ user.name }}</h2>
        <button (click)="editProfile()">Edit</button>
      </div>

      <div class="posts">
        <h3>Recent Posts</h3>
        <ul>
          @for (post of user.posts; track post) {
          <li>{{ post }}</li>
          }
        </ul>
      </div>

      <div class="friends">
        <h3>Friends</h3>
        <ul>
          @for (friend of user.friends; track friend) {
          <li>{{ friend }}</li>
          }
        </ul>
      </div>
    </section>
  `,
})
export class UserProfileComponent {
  user = {
    name: "Jane Doe",
    avatar: "/assets/avatar.png",
    posts: ["Angular Tips", "Reusable Components FTW!"],
    friends: ["John", "Mary", "Steve"],
  };

  editProfile() {
    console.log("Editing profile...");
  }
}

Instead of this, you can create small components like these:

• user-avatar.component.ts
• user-posts.component.ts
• user-friends.component.ts

// 🧩 user-avatar.component.ts
import { Component, input } from "@angular/core";

@Component({
  selector: "app-user-avatar",
  template: `
    <div class="user-avatar">
      <img [src]="avatar()" alt="User avatar" />
      <h2>{{ name() }}</h2>
    </div>
  `,
})
export class UserAvatarComponent {
  name = input.required<string>();
  avatar = input.required<string>();
}

// 🧩 user-posts.component.ts
import { Component, input } from "@angular/core";

@Component({
  selector: "app-user-posts",
  template: `
    <div class="user-posts">
      <h3>Recent Posts</h3>
      <ul>
        @for (post of posts(); track post) {
        <li>{{ post }}</li>
        }
      </ul>
    </div>
  `,
})
export class UserPostsComponent {
  posts = input<string[]>([]);
}

// 🧩 user-friends.component.ts
import { Component, input, output } from "@angular/core";

@Component({
  selector: "app-user-friends",
  template: `
    <div class="user-friends">
      <h3>Friends</h3>
      <ul>
        @for (friend of friends(); track friend) {
        <li (click)="selectFriend(friend)">{{ friend }}</li>
        }
      </ul>
    </div>
  `,
})
export class UserFriendsComponent {
  friends = input<string[]>([]);
  friendSelected = output<string>();

  selectFriend(friend: string) {
    this.friendSelected.emit(friend);
  }
}

Then, you can use them in a container component like this

// 🧩 new user profile components that uses other user components
import { Component } from "@angular/core";
import { signal } from "@angular/core";
import { UserAvatarComponent } from "./user-avatar.component";
import { UserPostsComponent } from "./user-posts.component";
import { UserFriendsComponent } from "./user-friends.component";

@Component({
  selector: "app-user-profile",
  imports: [UserAvatarComponent, UserPostsComponent, UserFriendsComponent],
  template: `
    <section class="profile">
      <app-user-avatar [name]="user().name" [avatar]="user().avatar" />
      <app-user-posts [posts]="user().posts" />
      <app-user-friends
        [friends]="user().friends"
        (friendSelected)="onFriendSelected($event)"
      />
    </section>
  `,
})
export class UserProfileComponent {
  user = signal({
    name: "Jane Doe",
    avatar: "/assets/avatar.png",
    posts: ["Angular Tips", "Reusable Components FTW!"],
    friends: ["John", "Mary", "Steve"],
  });

  onFriendSelected(friend: string) {
    console.log(`Selected friend: ${friend}`);
  }
}

The most common problem of creating such components is over-creating new elements when you actually do not need them. So, it is a design decision that needs to be carefully taken while building the application. If misused, it can lead to:

• a management nightmare
• unnecessary lifecycle hook complexity
• extra indirect data flow (makes debugging harder)

Nevertheless, this makes the app more scalable and maintainable if correctly used. Such structure will provide:

• a clear separation of concerns as each component will maintain decided tasks
• faster feature development
• shared libraries or elements across the application

🚀 Why Standalone Components Matter

As Angular has announced standalone components starting from version 17, they have been gradually developing features that support reusability. This important feature brings a great migration for components, directives, and pipes.

Since it allows these elements to be used directly inside an imports array rather than through a module structure, it reinforces reusability patterns and simplifies management.

Back in the module-based structure, we used to create these components and declare them in modules. This still offers some reusability, as we can import the modules where needed. However, standalone components can be consumed both by other standalone components and modules. For this reason, migrating from the module-based structure to a fully standalone architecture brings many benefits for this concern.

🧠 Designing Components That Scale and Reuse Well

The first point you need to consider here is to encapsulate and isolate logic.

For example:

1. This counter component isolates the concept of incrementing/decrementing so the parent component will not take care of this logic except showing the result.

   import { Component, signal } from "@angular/core";
   
   @Component({
     selector: "app-counter",
     template: `
       <button (click)="decrement()">-</button>
       <span>{{ count() }}</span>
       <button (click)="increment()">+</button>
     `,
   })
   export class CounterComponent {
     private count = signal(0); // internal state
   
     increment() {
       this.count.update((v) => v + 1);
     }
     decrement() {
       this.count.update((v) => v - 1);
     }
   }
   

2. This component isolates the styles and makes the badge reusable. Styles in this component will not leak out to others, and global styles will not affect it.

   import { Component, ViewEncapsulation } from "@angular/core";
   
   @Component({
     selector: "app-badge",
     template: `<span class="badge">{{ label }}</span>`,
     styles: [
       `
         .badge {
           background: #007bff;
           color: white;
           padding: 4px 8px;
           border-radius: 4px;
         }
       `,
     ],
     encapsulation: ViewEncapsulation.Emulated, // default; isolates CSS
   })
   export class BadgeComponent {
     label = "New";
   }
   

3. The search component below is a very common example since it handles a business logic exposing simple inputs/outputs

   import { Component, input, output } from "@angular/core";
   
   @Component({
     selector: "app-search-box",
     template: `
       <input
         type="text"
         [value]="query()"
         (input)="onChange($event)"
         placeholder="Search..."
       />
     `,
   })
   export class SearchBoxComponent {
     query = input<string>("");
     changed = output<string>();
   
     onChange(event: Event) {
       const value = (event.target as HTMLInputElement).value;
       this.changed.emit(value);
     }
   }
   

Encapsulation ensures that each component manages its own logic without leaking details to the outside. By keeping behavior self-contained, components become easier to understand, test, and reuse. This isolation prevents unexpected side effects, keeps your UI predictable, and allows each component to evolve independently as your application grows.

At this point, we can also briefly mention smart and dumb components. Smart components handle business logic, while dumb components take care of displaying data and emitting user actions.

This separation keeps your UI structure scalable. Smart components can change how data is loaded or handled without affecting presentation components, and dumb components can be reused anywhere since they just rely on inputs and outputs.

// smart component (container)
@Component({
  selector: "app-user-profile",
  imports: [UserCardComponent],
  template: `<app-user-card [user]="user()" (select)="onSelect($event)" />`,
})
export class UserProfileComponent {
  user = signal({ name: "Jane", role: "Admin" });

  onSelect(user: any) {
    console.log("Selected user:", user);
  }
}

// dumb component (presentation)
@Component({
  selector: "app-user-card",
  standalone: true,
  template: `
    <div (click)="select.emit(user())" class="card">
      <h3>{{ user().name }}</h3>
      <p>{{ user().role }}</p>
    </div>
  `,
})
export class UserCardComponent {
  user = input.required<{ name: string; role: string }>();
  select = output<{ name: string; role: string }>();
}

🔁 Reusing Components Across the Application

As there are many ways of reusing a component in the project, we will go over a real-life example.

Here are two very common ABP components that can be reused anywhere in the app:

//...
import { ABP } from "@abp/ng.core";

@Component({
  selector: "abp-button",
  template: `
    <button
      #button
      [id]="buttonId"
      [attr.type]="buttonType"
      [attr.form]="formName"
      [ngClass]="buttonClass"
      [disabled]="loading || disabled"
      (click.stop)="click.next($event); abpClick.next($event)"
      (focus)="focus.next($event); abpFocus.next($event)"
      (blur)="blur.next($event); abpBlur.next($event)"
    >
      <i [ngClass]="icon" class="me-1" aria-hidden="true"></i
      ><ng-content></ng-content>
    </button>
  `,
  imports: [NgClass],
})
export class ButtonComponent implements OnInit {
  private renderer = inject(Renderer2);

  @Input()
  buttonId = "";

  @Input()
  buttonClass = "btn btn-primary";

  @Input()
  buttonType = "button";

  @Input()
  formName?: string = undefined;

  @Input()
  iconClass?: string;

  @Input()
  loading = false;

  @Input()
  disabled: boolean | undefined = false;

  @Input()
  attributes?: ABP.Dictionary<string>;

  @Output() readonly click = new EventEmitter<MouseEvent>();

  @Output() readonly focus = new EventEmitter<FocusEvent>();

  @Output() readonly blur = new EventEmitter<FocusEvent>();

  @Output() readonly abpClick = new EventEmitter<MouseEvent>();

  @Output() readonly abpFocus = new EventEmitter<FocusEvent>();

  @Output() readonly abpBlur = new EventEmitter<FocusEvent>();

  @ViewChild("button", { static: true })
  buttonRef!: ElementRef<HTMLButtonElement>;

  get icon(): string {
    return `${
      this.loading ? "fa fa-spinner fa-spin" : this.iconClass || "d-none"
    }`;
  }

  ngOnInit() {
    if (this.attributes) {
      Object.keys(this.attributes).forEach((key) => {
        if (this.attributes?.[key]) {
          this.renderer.setAttribute(
            this.buttonRef.nativeElement,
            key,
            this.attributes[key]
          );
        }
      });
    }
  }
}

This button component can be used by simply importing the ButtonComponent and using the <abp-button /> tag.

You can reach the source code here.

This modal component is also commonly used. The source code is here.

//...
export type ModalSize = "sm" | "md" | "lg" | "xl";

@Component({
  selector: "abp-modal",
  templateUrl: "./modal.component.html",
  styleUrls: ["./modal.component.scss"],
  providers: [SubscriptionService],
  imports: [NgTemplateOutlet],
})
export class ModalComponent implements OnInit, OnDestroy, DismissableModal {
  protected readonly confirmationService = inject(ConfirmationService);
  protected readonly modal = inject(NgbModal);
  protected readonly modalRefService = inject(ModalRefService);
  protected readonly suppressUnsavedChangesWarningToken = inject(
    SUPPRESS_UNSAVED_CHANGES_WARNING,
    {
      optional: true,
    }
  );
  protected readonly destroyRef = inject(DestroyRef);
  private document = inject(DOCUMENT);

  visible = model<boolean>(false);

  busy = input(false, {
    transform: (value: boolean) => {
      if (this.abpSubmit() && this.abpSubmit() instanceof ButtonComponent) {
        this.abpSubmit().loading = value;
      }
      return value;
    },
  });

  options = input<NgbModalOptions>({ keyboard: true });

  suppressUnsavedChangesWarning = input(
    this.suppressUnsavedChangesWarningToken
  );

  modalContent = viewChild<TemplateRef<any>>("modalContent");

  abpHeader = contentChild<TemplateRef<any>>("abpHeader");

  abpBody = contentChild<TemplateRef<any>>("abpBody");

  abpFooter = contentChild<TemplateRef<any>>("abpFooter");

  abpSubmit = contentChild(ButtonComponent, { read: ButtonComponent });

  readonly init = output();

  readonly appear = output();

  readonly disappear = output();

  modalRef!: NgbModalRef;

  isConfirmationOpen = false;

  modalIdentifier = `modal-${uuid()}`;

  get modalWindowRef() {
    return this.document.querySelector(
      `ngb-modal-window.${this.modalIdentifier}`
    );
  }

  get isFormDirty(): boolean {
    return Boolean(this.modalWindowRef?.querySelector(".ng-dirty"));
  }

  constructor() {
    effect(() => {
      this.toggle(this.visible());
    });
  }

  ngOnInit(): void {
    this.modalRefService.register(this);
  }

  dismiss(mode: ModalDismissMode) {
    switch (mode) {
      case "hard":
        this.visible.set(false);
        break;
      case "soft":
        this.close();
        break;
      default:
        break;
    }
  }

  protected toggle(value: boolean) {
    this.visible.set(value);

    if (!value) {
      this.modalRef?.dismiss();
      this.disappear.emit();
      return;
    }

    setTimeout(() => this.listen(), 0);
    this.modalRef = this.modal.open(this.modalContent(), {
      size: "md",
      centered: false,
      keyboard: false,
      scrollable: true,
      beforeDismiss: () => {
        if (!this.visible()) return true;

        this.close();
        return !this.visible();
      },
      ...this.options(),
      windowClass: `${this.options().windowClass || ""} ${
        this.modalIdentifier
      }`,
    });

    this.appear.emit();
  }

  ngOnDestroy(): void {
    this.modalRefService.unregister(this);
    this.toggle(false);
  }

  close() {
    if (this.busy()) return;

    if (this.isFormDirty && !this.suppressUnsavedChangesWarning()) {
      if (this.isConfirmationOpen) return;

      this.isConfirmationOpen = true;
      this.confirmationService
        .warn(
          "AbpUi::AreYouSureYouWantToCancelEditingWarningMessage",
          "AbpUi::AreYouSure",
          {
            dismissible: false,
          }
        )
        .subscribe((status: Confirmation.Status) => {
          this.isConfirmationOpen = false;
          if (status === Confirmation.Status.confirm) {
            this.visible.set(false);
          }
        });
    } else {
      this.visible.set(false);
    }
  }

  listen() {
    if (this.modalWindowRef) {
      fromEvent<KeyboardEvent>(this.modalWindowRef, "keyup")
        .pipe(
          takeUntilDestroyed(this.destroyRef),
          debounceTime(150),
          filter(
            (key: KeyboardEvent) =>
              key && key.key === "Escape" && this.options().keyboard
          )
        )
        .subscribe(() => this.close());
    }

    fromEvent(window, "beforeunload")
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe((event) => {
        if (this.isFormDirty && !this.suppressUnsavedChangesWarning()) {
          event.preventDefault();
        }
      });

    this.init.emit();
  }
}

This concept differs slightly from the others mentioned above since these components are introduced within a library called theme-shared, which you can explore here.

Using shared libraries for such common components is one of the most effective ways to make your app modular and maintainable. By grouping frequently used elements into a dedicated library, you create a single source of truth for your UI and logic.

However, over-creating or prematurely abstracting small pieces of logic into separate libraries can lead to unnecessary complexity and dependency management overhead. When every feature has its own “mini-library,” updates and debugging become scattered and difficult to coordinate.

The key is to extract shared functionality only when it is proven to be reused across multiple contexts. Start small, let patterns emerge naturally, and then move them into a shared library when the benefits of reusability outweigh the maintenance cost.

⚙️ Best Practices and Common Pitfalls

✅ Best Practices

1. Start with real reuse: Extract components only after the pattern appears in multiple places.
2. Keep them focused: One clear responsibility per component—avoid “do-it-all” designs.
3. Use standalone components: Simplify imports and improve independence.
4. Promote through libraries: Move proven, stable components into shared libraries for wider use.

⚠️ Common Mistakes

1. Premature abstraction: Don't create components before actual reuse.
2. Too many input/output bindings: Overly generic components are hard to configure and maintain.
3. Neglecting performance: Too many micro-components can hurt performance.
4. Ignoring accessibility and semantics: Reusable does not mean usable—always consider ARIA roles and HTML structure.

📚 Further Reading and References

As this article has mentioned some concepts and best practices, you can explore these resources for more details:

• Angular Components Guide
• Standalone Migration Guides, ABP Angular Standalone Applications
• Smart vs. Dumb Components
• Angular Libraries Overview

You can also check these open-source libraries for a better understanding of reusability and modularity:

• Angular Components on GitHub
• ABP NPM Libraries

🏁 Conclusion

Reusability is one of the strongest architectural foundations for scalable Angular applications. By combining standalone components, signals, encapsulated logic, and shared libraries, you can create a modular system that grows gracefully over time.

The goal is not just to make components reusable. It is to make them meaningful, maintainable, and consistent across your app. Build only what truly adds value, reuse intentionally, and let Angular's evolving ecosystem handle the rest.

Angular has consistently introduced new features to boost application performance, from lazy-loaded components to reactive change detection with signals. This article explores key optimization techniques, including lazy loading, on-demand element loading, signals-based state management, code splitting and tree shaking, and advanced change detection strategies. By understanding and implementing these practices, developers can significantly improve initial load time of the applicarion and overall responsiveness.

1. Lazy Loading Approach

As the name implies, lazy loading provides the elements only when they are needed, differentiating it from eager loading. By enabling this feature for routes or modules, the bundle size gets smaller and the loading time decreases.

🧘🏼‍♀️ Lazy Loaded Components

The first way to integrate lazy loading into your application is to load components this way. First, you can create a component using this command ng g component book, and it will look like a regular standalone component:

import { Component } from '@angular/core';

@Component({
  selector: 'app-book',
  imports: [],
  templateUrl: './book.html',
  styleUrl: './book.scss'
})
export class Book { }

Then, you can declare a routing for the component and use loadComponent instead of component to load it lazily.

//app.routes.ts
import { Routes } from '@angular/router';
export const APP_ROUTES: Routes = [
  {
    path: 'book',
    loadComponent: () => import('./book/book').then(c => c.Book),
  },
];

Once you navigate to the books route, the component will be loaded. Lazy loading a component is a key technique for reducing the initial bundle size of your application. Instead of including code of the component in the main bundle that is downloaded when a user first visits your site, Angular creates a separate, small bundle for the Book component. This bundle is only downloaded and parsed by the browser when the user actually navigates to the /book route. This approach results in a faster initial load time and a more responsive user experience, as the browser does not have to process a large amount of unnecessary code upfront. The import() syntax is a dynamic import, which tells a module bundler like Webpack or Vite to create a separate chunk for the imported file, enabling this lazy-loading behavior.

🚲 Lazy Loaded Modules

If you still continue using the module-based structure, you can load the modules lazily as well. However, this approach will be marked as deprecated in the future. For this reason, we recommend a migration where you can follow related steps.

First, you need to create a module using such command ng g module book. Then, you can create a component and connect to this module using this command ng g component book --module book. The final result will be like this:

//book.module.ts
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { BookComponent } from './book.component';

@NgModule({
  declarations: [],
  imports: [
    CommonModule,
    BookComponent
  ]
})
export class BookModule { }

//book.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-book',
  imports: [],
  templateUrl: './book.component.html',
  styleUrl: './book.component.scss'
})
export class BookComponent {}

Then, you can declare a routing for the module and use loadChildren instead of component to load it lazily.

//app-routing.module.ts
import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
const routes: Routes = [
  {
    path: 'book',
    loadChildren: () => import('./book/book.module').then(m => m.BookModule),
  },
];
@NgModule({
  imports: [RouterModule.forRoot(routes, {})],
  exports: [RouterModule],
})
export class AppRoutingModule {}

2. Code Splitting and Tree Shaking

Code splitting and tree shaking are two powerful techniques that work hand-in-hand to ensure your users download and execute only the JavaScript they truly need.

📘 Code Splitting

Code splitting is the process of breaking a large JavaScript bundle into smaller, more manageable chunks. Instead of sending one massive file to the browser at load time, Angular delivers only what is necessary at the moment.

Loading components or modules lazily, using deferrable views and signals are examples of code splitting.

📈 The benefits are:

• Faster initial load time (reduced bundle size).
• More efficient use of network bandwidth.
• Scales better as applications grow in features.

📘 Tree Shaking

Tree shaking is a form of dead code elimination. It analyzes your imports, detects which parts of a library or file are unused, and removes them from the final build. The metaphor comes from shaking a tree: the dead leaves fall off, leaving only what’s alive (used code).

import { usefulFunction } from './helpers';
import { unusedFunction } from './helpers';

usefulFunction();

Here, unusedFunction is never called. With tree shaking, the Angular compiler ensures that this unused code won’t appear in the final production bundle.

📈 The benefits are:

• Reduced JavaScript size.
• Less parsing and execution time for the browser.
• Lower memory usage.

Code Splitting decides when to load code, while Tree Shaking decides what code gets included in the first place. Together, they ensure the Angular app is both lean and efficient.

3. Loading Elements on Demand using @defer block

The aim of using this view kind is also to reduce the initial bundle size of the application. Angular documentation claims that the initial load becomes faster, and it enhances the Core Web Vitals (CVW), especially for Largest Contentful Paint (LCP) and Time to First Byte (TTFB).

In order to use this block, your component needs to be standalone, and you cannot re-use the component outside of the deferring block. Here is how you can use it in your template:

@defer {
  <large-component />
}

You can also propose loading, error, and placeholder states out of the box.

@defer {
  <large-component />
} @loading {
  <img alt="loading..." src="https://raw.githubusercontent.com/abpframework/abp/fdd71f2be791350404bc2635ad5c0cd31b431e51/docs/en/Community-Articles/2025-09-25-Supercharge-Your-Angular-App-A-Developer%27s-Guide-to-Unlocking-Peak-Performance/loading.gif" />
} @placeholder {
  <p>Placeholder content</p>
} @error {
  <p>Failed to load large component.</p>
}

The framework also provides content loading based on triggers. These are on and when. Basically, the on property option relies on the user interaction, and the when property relies on the specified condition.

4. Using Signals for State Management

Angular introduced signals as part of its reactivity model to make state management and change detection more precise and performant compared to the traditional Zone.js-based approach. Signals shift Angular from a 'check everything on every event' model to a 'react only to what changed' model. This makes applications more efficient, faster, and often simpler to reason about. Here are the benefits of signals in terms of performance optimization:

✅ Reduces unnecessary work and makes faster UI updates.

Traditionally, Angular relies on zone-based change detection, which means that any asynchronous event (e.g., click, HTTP request, timer) triggers a full change detection cycle across the entire component tree. Since Angular knows exactly which component property depends on which reactive value, this allows Angular to update only the affected components/elements when the signal changes, instead of re-checking everything.

✅ Dependencies are tracked explicitly.

A signal records its dependencies at runtime. When a computed signal or template expression reads a signal, Angular automatically tracks that dependency. If the value changes, only consumers of that signal re-run. So, the unrelated computations are prevented, and the performance is optimized.

✅ The updates are synchronous and predictable.

When you set a new value in a signal, all dependent computations and template updates happen immediately and predictably. So, it is easy to debug and determine the performance in that sense.

5. Change Detection

Angular uses a change detection mechanism to keep the view in sync with the component state. By default, Angular uses the default change detection strategy for every component.

Default Strategy Mechanism

When an event happens (like a user input, HTTP response, setTimeout, etc.), Angular runs change detection. It starts from the root component and traverses every component in the tree to check if any bound data has changed. Angular compares the current property values with the previous ones for each component. As can be perceived, if something changed, Angular updates the DOM. Even if a change occurs in one component, Angular will still go through all components down the tree unless properly optimized.

The good side is that it keeps the UI of the application constant with the state no matter where the change is coming from. However, it becomes a bottleneck for large applications as all components are going to be checked.

Optimizing the Default Strategy

Even with the Default strategy, you can improve performance by:

• Breaking up elements into smaller, reusable ones, so Angular checks smaller trees.
• Using track in @for blocks to prevent re-rendering on unchanged list items.
• Not adding heavy computations on templates or making them into smaller ones in services.

The other change detection strategy is OnPush. This will allow you to make checks when needed. By this means, Angular would check only if:

• an input reference is changed
• an event is triggered
• or you trigger it manually by using markForCheck utility

Manual Change Detection Triggers

Angular provides these controls by ChangeDetectorRef class injection.

markForCheck()

This marks the component along its ancestors as dirty. The component will be checked in the next change detection cycle. In this example case, a component uses the OnPush strategy, and something is updated directly (e.g. a service emits a new value without changing the input() reference).

private cdr = inject(ChangeDetectorRef);

updateData() {
  this.data.someProp = 'newValue';
  this.cdr.markForCheck();  // schedule re-check
}

detectChanges()

Immediately runs change detection synchronously on the component and its children. In this example, the DOM is reflected by the change immediately that could be after a dialog closing, or measuring the size of the element.

private cdr = inject(ChangeDetectorRef);

updateData() {
  this.data.someProp = 'newValue';
  this.cdr.detectChanges();  // run CD immediately
}

In short:

• Use markForCheck() when performance is the key and you want to stay within the normal change detection cycle of Angular.
• Use detectChanges() when you absolutely need the update immediately after the change occurs.

Conclusion

By implementing these strategies, developers can build Angular applications that are not only feature-rich but also fast and efficient. Lazy loading, code splitting, and tree shaking work together to reduce initial load times, while signals and optimized change detection ensure the application remains responsive and performant as it grows in complexity. Embracing these modern Angular features is crucial for delivering a high-quality user experience and maintaining a scalable codebase.

We are excited to announce that ABP now supports Angular’s standalone component structure in the latest Studio update. This article walks you through how to generate a standalone application, outlines the migration steps, and highlights the benefits of this shift over traditional module-based architecture.

Why Standalone?

Angular's standalone component architecture, which is introduced in version 14 and made default in version 19, is a major leap forward for Angular development. Here is why it matters:

🔧 Simplified Project Structure

Standalone components eliminate the need for NgModule wrappers. This leads to:

• Fewer files to manage
• Cleaner folder organization
• Reduced boilerplate

Navigating and understanding your codebase becomes easier for everyone on your team.

🚀 Faster Bootstrapping

Standalone apps simplify app initialization:

bootstrapApplication(AppComponent, appConfig);

This avoids the need for AppModule and speeds up startup times.

📦 Smaller Bundle Sizes

Since components declare their own dependencies, Angular can more effectively tree-shake unused code. Result? Smaller bundle sizes and faster load times.

🧪 Easier Testing & Reusability

Standalone components are self-contained. They declare their dependencies within the imports array, making them:

• Easier to test in isolation
• Easier to reuse in different contexts

🧠 Clearer Dependency Management

Standalone components explicitly define what they need. No more hidden dependencies buried in shared modules.

🔄 Gradual Adoption

You can mix and match standalone and module-based components. This allows for incremental migration, reducing risk in larger codebases. Here is the related document for the standalone migration.

Getting Started: Creating a Standalone Angular App

Angular CLI makes it easy to start:

ng new my-app

With Angular 19, new apps follow this bootstrapping model:

// main.ts
import { bootstrapApplication } from "@angular/platform-browser";
import { appConfig } from "./app/app.config";
import { AppComponent } from "./app/app.component";

bootstrapApplication(AppComponent, appConfig).catch((err) =>
  console.error(err)
);

The app.config.ts file replaces AppModule:

// app.config.ts
import { ApplicationConfig, provideZoneChangeDetection } from "@angular/core";
import { provideRouter } from "@angular/router";
import { routes } from "./app.routes";

export const appConfig: ApplicationConfig = {
  providers: [
    provideZoneChangeDetection({ eventCoalescing: true }),
    provideRouter(routes),
  ],
};

Routing is defined in a simple Routes array:

// app.routes.ts
import { Routes } from "@angular/router";

export const routes: Routes = [];

ABP Studio Support for Standalone Structure

Starting with the latest release (insert version number here), ABP Studio fully supports Angular's standalone structure. While the new format is encouraged, module-based structure will continue to be supported for backwards compatibility.

To try it out, simply update your ABP Studio to create apps with the latest version.

What’s New in ABP Studio Templates?

When you generate an app using the latest ABP Studio, the project structure aligns with Angular's standalone architecture.

This migration is split into four parts:

1. Package updates
2. Schematics updates
3. Suite code generation updates
4. Template refactors

Package Migration Details

Migration has been applied to packages in the ABP GitHub repository. Here is an example from the Identity package.

🧩 Migrating Components

Components are made standalone, using:

ng g @angular/core:standalone

Example:

@Component({
  selector: 'abp-roles',
  templateUrl: './roles.component.html',
  providers: [...],
  imports: [
    ReactiveFormsModule,
    LocalizationPipe,
    ...
  ],
})
export class RolesComponent implements OnInit { ... }

🛣 Updating Routing

Old lazy-loaded routes using forLazy():

{
  path: 'identity',
  loadChildren: () => import('@abp/ng.identity').then(m => m.IdentityModule.forLazy({...}))
}

Now replaced with:

{
  path: 'identity',
  loadChildren: () => import('@abp/ng.identity').then(c => c.createRoutes({...}))
}

🧱 Replacing Module Declarations

The old setup:

// identity.module.ts
@NgModule({
  imports: [IdentityRoutingModule, RolesComponent, UsersComponent],
})
export class IdentityModule {...}

//identity-routing.module
const routes: Routes = [...];
@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule],
})
export class IdentityRoutingModule {}

New setup:

// identity-routes.ts
export function provideIdentity(options: IdentityConfigOptions = {}): Provider[] {
  return [...];
}
export const createRoutes = (options: IdentityConfigOptions = {}): Routes => [
  {
    path: '',
    component: RouterOutletComponent,
    providers: provideIdentity(options),
    children: [
      {
        path: 'roles',
        component: ReplaceableRouteContainerComponent,
        data: {
          requiredPolicy: 'AbpIdentity.Roles',
          replaceableComponent: {
            key: eIdentityComponents.Roles,
            defaultComponent: RolesComponent,
          },
        },
        title: 'AbpIdentity::Roles',
      },
      ...
    ],
  },
];

ABP Schematics Migration Details

You can reach details by checking ABP Schematics codebase.

📚 Library creation

When you run the abp create-lib command, the prompter will ask you the templateType. It supports both module and standalone templates.

"templateType": {
  "type": "string",
  "description": "Type of the template",
  "enum": ["module", "standalone"],
  "x-prompt": {
    "message": "Select the type of template to generate:",
    "type": "list",
    "items": [
      { "value": "module", "label": "Module Template" },
      { "value": "standalone", "label": "Standalone Template" }
    ]
  }
},

ABP Suite Code Generation Migration Details

ABP Suite will also be supporting both structures. If you have a project that is generated with the previous versions, the Suite will detect the structure in that way and generate the related code accordingly. Conversely, here is what is changed for the standalone migration:

❌ Discarded module files

// entity-one.module.ts
@NgModule({
  declarations: [],
  imports: [EntityOneComponent, EntityOneRoutingModule],
})
export class EntityOneModule {}

// entity-one-routing.module.ts
export const routes: Routes = [
  {
    path: "",
    component: EntityOneComponent,
    canActivate: [authGuard, permissionGuard],
  },
];

@NgModule({
  imports: [RouterModule.forChild(routes)],
  exports: [RouterModule],
})
export class EntityOneRoutingModule {}

// app-routing.module.ts
{
  path: 'entity-ones',
  loadChildren: () =>
    import('./entity-ones/entity-one/entity-one.module').then(m => m.EntityOneModule),
},

✅ Added routes configuration

// entity-one.routes.ts
export const ENTITY_ONE_ROUTES: Routes = [
  {
    path: "",
    loadComponent: () => {
      return import("./components/entity-one.component").then(
        (c) => c.EntityOneComponent
      );
    },
    canActivate: [authGuard, permissionGuard],
  },
];

// app.routes.ts
{ path: 'entity-ones', children: ENTITY_ONE_ROUTES },

Template Migration Details

🧭 Routing: app.routes.ts

// app.routes.ts
import { Routes } from '@angular/router';

export const APP_ROUTES: Routes = [
  {
    path: '',
    pathMatch: 'full',
    loadComponent: () => import('./home/home.component').then(m => m.HomeComponent),
  },
  {
    path: 'account',
    loadChildren: () => import('@abp/ng.account').then(m => m.createRoutes()),
  },
  ...
];

⚙ Configuration: app.config.ts

// app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(APP_ROUTES),
    APP_ROUTE_PROVIDER,
    provideAbpCore(
      withOptions({
        environment,
        registerLocaleFn: registerLocale(),
        ...
      })
    ),
    provideAbpOAuth(),
    provideAbpThemeShared(),
    ...
  ],
};

🧼 Removed: shared.module.ts

This file has been removed to reduce unnecessary shared imports. Components now explicitly import what they need—leading to better encapsulation and less coupling.

Common Problems

You may encounter these common problems that you would need to manage.

1. Missing Imports

In standalone structure, components must declare all their dependencies in imports. Forgetting this often causes template errors.

2. Mixed Structures

Combining modules and standalone in the same feature leads to confusion. Migrate features fully or keep them module-based.

3. Routing Errors

Incorrect migration from forLazy() to createRoutes() or loadComponent can break navigation. Double-check route configs.

4. Service Injection

Services provided in old modules may be missing. Add them in the component’s providers or app.config.ts.

5. Shared Module Habit

Reintroducing a shared module reduces the benefits of standalone. Import dependencies directly where needed.

Conclusion

Angular’s standalone component architecture is a significant improvement for scalability, simplicity, and performance. With latest version of ABP Studio, you can adopt this modern approach with ease—without losing support for existing module-based projects.

Ready to modernize your Angular development?

Update your ABP Studio today and start building with standalone power!