DEV Community: Daniel Glejzner

Always unsubscribe. No exceptions. Debate closed.

Daniel Glejzner — Thu, 11 Apr 2024 21:16:37 +0000

So many years with Angular.
So many years with RxJS.

Yet people still fight over "when NOT to unsubscribe".

Truth is. It's not even worth the conversation.

Just unsubscribe always. Simple.

I have recently posted the same advice on my social media(X/LinkedIn).

While majority agreed without a doubt. About 10% decided that it's a perfect opportunity to showcase deep and expert knowledge of how there is NO NEED to always unsubscribe.

The prime and crown example:

HttpClient cold observable

I have been told that:

It's a terrible advice
It's a big overhead to always unsubscribe
People should never follow this advice
It's absolutely wrong
It's redundant code
It's a bold assumption
Go ask Angular Team and so on...

Yes technically HttpClient completes automatically in like 99% of cases.

However this doesn't mean that you have to deliberately find and safe guard places where you subscribe to HttpClient Observable to avoid unsubscribing.

Simple "Why":

It doesn't make any sense
There is 0 overhead to unsubscribe since you have to do it in other places as well ( should be in your blood already cmon!"
Value consistency over "being smart about things"
Never think about when not to unsubscribe and focus on important things.
Value consistency...
Value consistency...

Not convinced? Advanced "Why":

Citing a friend, because i could have not put it together in a batter way:

Additionally this conversation has been "silently" resolved in one of the GitHub issues from 2022. Feedback from "Engineering" means response from devs.

source: https://github.com/angular/angular/issues/46542

And finally in new Angular docs website. It's clearly stated that:

Once the response returns, Observables from HttpClient usually complete (although interceptors can influence this).

Because of the automatic completion, there is usually no risk of memory leaks if HttpClient subscriptions are not cleaned up. However, as with any async operation, we strongly recommend that you clean up subscriptions when the component using them is destroyed, as the subscription callback may otherwise run and encounter errors when it attempts to interact with the destroyed component.

source: https://angular.dev/guide/http/making-requests#http-observables

Now you can use this resource if your teammates keep nitpicking that you are unsubscribing from HttpClient Observables. Or any other they think it's "safe" not to do it.

Tip: Avoid subscribing in first place, do everything to end up with async pipe.

PS: as of Angular v16 - the best way to unsubscribe is by using takeUntilDestroyed()

Like my stuff? Follow me on LinkedIn or X
Big things happening at angularspace.com ( Early Access )

⭐ Angular Space Writer Mentorship Program

Daniel Glejzner — Wed, 27 Mar 2024 14:00:14 +0000

Announcing the Angular Space Writer Mentorship Program

Exclusive to Angular Space Registered Members!

I’m thrilled to announce the Angular Space Writer Mentorship Program, where community members can transform their article ideas into educational masterpieces with the help of industry experts.

How It Works 👇

#1 Submit Your Idea

Use a form to propose the article💡 you want to write for Angular Space ( To be published soon).
We are going to take limited amount of ideas in phases
to ensure that you are taken care of!
If we reject your idea you are going to receive explanation why and guidelines for selecting new idea! ( First Learning opportunity ) 🧑‍🎓

#2 Technical Review

Once your article idea is approved, you need to send us a draft focusing on technical educational value you want to pass ( focus on code 😄 ).
One (or multiple) Technical Mentors ⭐ is/are going to take care of you from now on to validate the technical correctness of the code and the concept. Ensure that the content is suitable for an article and will truly educate our readers.
You are already in the process, every mistake you make will be a learning opportunity 🧑‍🎓.
You are going to cooperate with Mentors until the result is satisfying. Mentors are going to be there to help you with every question and doubt!

#3 Content Delivery Review

After passing the Technical Review, we know the code is solid, and the technical message is educational.
Now, Content Delivery Mentors ⭐ work on clarifying descriptions, improving content delivery, adding impactful titles, and ensuring the article is both engaging, informative and well structured.
This is a crucial part that many don’t fulfil in a correct way. **You also need to learn to sell 💰 **your technical expertise so it impacts highest amount of devs along the way. More fun and engaging = more views.
“But Views and Likes are not important or a metric of good article” — correct ✅. However without views/likes your content is going to have limited reach and your educational effort is going to impact small amount of devs ☹️…
Once the fun and engaging part is ✅, you attracted many to read. Your content now get’s exposed to the it’s foundational core. The technical/educational part — the part you value the most!

#4 Final Review

The article undergoes a comprehensive review of both its technical and content delivery elements. Final touches are added if needed and it’s queued for publication! 👏

High-Level Vision 👁️

Win-Win-Win 🏆

We aim for impact, leveraging our expertise to maximize contributions to the open-source community. Your article will not only be a learning experience for you but also a valuable asset for Angular Space and the tech community.
As you navigate through each stage of the process, you’ll refine your technical knowledge, learn from any mistakes, and improve upon your original ideas.
Learn to write in a way that is technically sound and accessible, creating content that readers can understand, enjoy, and trust.
Mentors will practice and enhance their mentoring skills, ensuring the high quality of the content published under Angular Space’s name.
Angular Space gains insightful educational content, while the tech community can rely on these articles to be credible and valuable, thanks to the mentorship seal of approval.

Everyone wins! Everyone gains something in the process 😃

And of course, when your article is ready for publication, not only will your name be featured as the author, but the mentors who’ve supported and guided you will also be acknowledged for their contributions.

You can publish your work on dev/medium etc. We do not own any rights to your content. We are going to ask you for courtesy Angular Space Mentorship Program info placement + Mentors who reviewed your article at the end when you decide to publish in different places as well.

Join us in this unique mentorship opportunity to write, learn, and make a lasting impact!

Join us now! --> https://www.angularspace.com/

or join waitlist directly!

https://tally.so/r/wMzALE

I’m going to publish the registration form soon! Make sure to keep an eye on Angular Space, E-mails, my tweets/posts on X 😎

What is Angular Query?

Daniel Glejzner — Sat, 03 Feb 2024 22:43:14 +0000

Short breakdown 👇

Angular Query is used for syncing server data with client applications.

Without any unneeded abstractions.

Ideal for

grids
tables
listings
etc…

We have 2 packages to look at

ngneat/query
tanstack/angular-query-experimental

ngneat is unofficial adapter

supporting RxJS & Signals by @ngneat_org @NetanelBasal

TanStack one is official

developed by @Arnoud_dv @tan_stack
for now supports only Signals
RxJS support planned for the future

Both are using TanStack Query Core.

🟨 Core Concepts 🟨

1. Queries

Declaratively manage data fetching.
Letting Angular Query handle the timing and specifics of server communication.

2. Mutations

Handle data modification
Integrating queries for a consistent data management

🧹 Cache & Cleanup 🧹

1. Cache Management

Data maintenance and retrieval is handled by Query Client & Query Cache.

2. Query Keys

A system for identifying and managing data dependencies across components.

3. SWR

Ensures data freshness by smartly revalidating data behind the scenes without sacrificing performance.

💻 Significant DX improvements 💻

Reduced boilerplate Out of the box
Intelligent caching and data management strategies
Giant performance boost in writing async code
Pairs fantastic with component state management libraries

Basic usage with ngneat/query:

Service usage:

    import { injectQuery } from '@ngneat/query';

    @Injectable({ providedIn: 'root' })
    export class TodosService {
      #http = inject(HttpClient);
      #query = injectQuery();

      getTodos() {
        return this.#query({
          queryKey: ['todos'] as const,
          queryFn: () => {
            return this.http.get<Todo[]>(
              'https://jsonplaceholder.typicode.com/todos',
            );
          },
        });
      }
    }

Component usage with Observables:


    @Component({
      standalone: true,
      template: `
        @if (todos.result$ | async; as result) {
          @if (result.isLoading) {
            <p>Loading</p>
          }
          @if (result.isSuccess) {
            <p>{{ result.data[0].title }}</p>
          }
          @if (result.isError) {
            <p>Error</p>
          }
        }
      `,
    })
    export class TodosPageComponent {
      todos = inject(TodosService).getTodos();
    }

Component usage with Signals:


    @Component({
      standalone: true,
      template: `
        @if (todos().isLoading) {
          Loading
        }
        @if (todos().data; as data) {
          <p>{{ data[0].title }}</p>
        }
        @if (todos().isError) {
          <p>Error</p>
        }
      `,
    })
    export class TodosPageComponent {
      todos = inject(TodosService).getTodos().result;
    }

Docs:

ngneat: https://github.com/ngneat/query

TanStack: https://tanstack.com/query/latest/docs/framework/angular/overview

Follow me on X for more: https://twitter.com/DanielGlejzner

4 Laws of RxJS Observables

Daniel Glejzner — Thu, 02 Nov 2023 13:16:28 +0000

This is crucial to understand! Online materials can often be incorrect.

Very short but meaty writeup.

🏆 Here are 4 Laws of Observables 🏆

Law 1

• All Observables are lazy, without exception.

Law 2

• Observables are either cold, serving a single execution context per subscription in a unicast manner.

• Or hot, serving one or more subscribers with the same execution context, in a multicast manner.

Law 3

• Subject is both an Observable and an Observer

• The Observable part is multicast, but still lazily executed only when the first subscriber comes.

• The Observer part is the one created eagerly that allows us to call .next() and send data through the Subject;

• The Observer part does not imply that the execution context of the Observable is 'alive' before the first subscription is made.

Law 4

• There are stateful Subjects, like BehaviorSubject or ReplySubject, which extend the Observer part.

• Adding support for holding 1..n previous states, which the Observable part will multicast to potential subscribers.

By reading this, do you think that RxJS is a complex subject (pun intended :D)?

Angular Team announced plans to potentially make RxJS optional in the future.

Would you like to keep RxJS mandatory?
Or optional is the right way to go?

Microtask Queue + RxJS + Angular

Daniel Glejzner — Sat, 07 Oct 2023 05:04:44 +0000

The What, When, and Why

When working with Angular, you can experience complex mechanisms that are not initially visible. When understood, can significantly enhance your application’s performance.

Learn about interplay between the Microtask Queue, RxJS, and Angular’s change detection mechanism.

Microtask vs. Macrotask

Before diving deep, it’s essential to differentiate between microtasks and macrotasks. Observables, a core part of RxJS, are microtasks in async scenario.

This ensures they execute quicker than macrotasks, such as setTimeout. But why does this matter?

RxJS and Asynchronicity

Observable values (async scenario) in RxJS are processed after promises. This sequence affects the execution order, which can be crucial when dealing with asynchronous operations.

Angular’s Change Detection

Angular’s change detection mechanism is designed to run after the microtask queue is emptied.

This ensures that the view updates only after all the microtasks, including observables, have been processed.

It’s a subtle yet powerful design choice that ensures consistency in the UI.

The Role of Zone.js

Zone.js plays a significant role. It monitors asynchronous operations and ensures that Angular’s change detection is triggered post the completion of microtasks.

RootZone (outerZone)

At the foundation of Zone.js is the root zone. This is the top-level zone that provides the basic mechanisms to track asynchronous operations.

Forking and Hierarchical Structure

Zones in Zone.js are hierarchical. This means that new zones are created by "forking" an existing zone. When you fork a zone, the new zone inherits the behaviours of its parent but can also have additional behaviours or modifications.

This hierarchical structure allows for a cascading system where child zones can benefit from the tracking mechanisms of their parent zones while also introducing specific behaviours.

NgZone (innerZone)

In the context of Angular, the framework doesn’t directly use the root zone. Instead, Angular creates its specialized zone by forking the root zone.

This forked zone, known as NgZone or sometimes referred to as the "inner zone," is augmented with Angular-specific behaviors. It's within this NgZone that Angular tracks changes and decides when to run its change detection.

The ability to fork zones and create this hierarchical structure is powerful. It allows for modular and layered tracking of asynchronous operations.

For instance, while the root zone might provide basic tracking, child zones (like NgZone) can introduce application-specific behaviors without affecting the broader tracking mechanisms.

In Angular’s case, the NgZone ensures that the framework can efficiently track changes and update the UI, building upon the foundational capabilities of the root zone.

A Typical Sequence

Let’s break down a typical sequence of events:

A user interacts, perhaps with a button click.
This interaction triggers an event.
An API call is made in response.
Promises and Observables (async scenario) are pushed into the Microtask Queue.
Functions scheduled with setTimeout go into the Macrotask Queue.
Within the Microtask Queue, promises resolve first.
Observables then emit their values.
Data is processed using RxJS operators.
Angular checks for changes in the data.
The UI is updated with fresh data.
Finally, functions in the Macrotask Queue, like those scheduled with setTimeout, execute.

Not that hard huh?

The interplay between the Microtask Queue, RxJS, and Angular is a complex work of internal mechanisms.

But understanding this is invaluable. It not only aids in performance optimizations but also helps in resolving potential race conditions.

These nuances can make the difference between a good application and a great one.

Angular is getting New Template Syntax

Daniel Glejzner — Sat, 01 Jul 2023 10:44:51 +0000

Update 2023–10–07: I have updated this to the final syntax form with @

New Template Syntax, Built-In Control Flow, a farewell to structural directives? Not a lot has been changing in recent years. Angular has been stable for some devs and stagnant for others. Now it’s moving forward at light speed. But where exactly is it headed?

Angular proposes a transition from the current structural directives (NgIf, NgForOf, NgSwitch) to a new built-in syntax. If you’re not already following the RFCs (Request for Comments), please do. In meantime I am going to help you understand what’s coming.

Revamping Control Flow

Angular team aims to replace the existing structural directives (NgIf, NgForOf, and NgSwitch) with a more modern, macro-like syntax. While the structural directives are not going away completely, because the concept is going to stay — this new way of writing your template is going to be the preferred one. It’s backwards compatible and for some time you are going to be able to use both old template style and new one in different files.

Change aims to cover better readability and provide smother way to adapt for wider audience in Frontend world.

Before

The trackByFunction in Angular is a custom function used for optimizing performance when iterating over large collections using *ngFor. In current syntax it takes only a function, in new way it’s going to work just with properties.

Angular will track changes in the collection based on each item’s id, instead of its identity. This is useful when items in the collection have unique ids, improving efficiency when the collection is updated.

    trackByFunction(index, item) {
      return item.id;
    }

    <div *ngFor="let item of items; index as idx; trackBy: trackByFunction">
      Item #{{ idx }}: {{ item.name }}
    </div>

After

@for (item of items; track item.id; let idx = $index, let e = $even) 
{
  Item #{{ idx }}: {{ item.name }}
}

This new syntax is keeping several implicit variables like $index, $first, $last, $even, and $odd within for row views. These are available for use directly, but can also be aliased using the ‘let’ segment. The new syntax also emphasizes using ‘track’ for loops to improve performance and optimizes list diffing by enforcing tracking.

@for (item of items; track item.id) 
{
  {{ item }}
} 
@empty 
{
  There were no items in the list.
}

One crucial feature introduced is the ‘empty’ block which allows developers to display a template when there are no items in the list. Also, Angular is changing how it handles list diffing. Rather than using the customizable IterableDiffers, Angular will provide a new optimized algorithm for better performance.

If-Else Blocks

If you found the original way of working with ng-container & ng-template alongside *ngIf structural directive not intuitive enough — New Control Flow might have an answer for your troubles.

Before (in theory)

    <ng-container *ngIf="cond.expr; else elseBlock">
      Main case was true!
    </ng-container>

    <ng-template #elseBlock>
      <ng-container *ngIf="other.expr; else finalElseBlock">
        Extra case was true!
      </ng-container>

    </ng-template>
    <ng-template #finalElseBlock>
      False case!
    </ng-template>

After

@if (cond.expr) 
{
  Main case was true!
} 
@else if (other.expr) 
{
  Extra case was true!
} 
@else 
{
  False case!
}

Switch Block

The ‘switch’ block takes place of *ngSwitch which. New way of writing is said to bring in substantial benefits like enhanced template type-checking and no need for container elements to hold condition expressions. Here’s a quick peek at how it would look:

@switch (condition) 
{
  @case (caseA) 
  {
    Case A.
  }
  @case (caseB) 
  {
    Case B.
  }
  @default 
  {
    Default case.
  }
}

What About Migration?

Migration to the new syntax is promised be relatively smooth. Angular team is working on an automated migration schematic to convert from the old to the new syntax. However, developers might need to be cautious about any custom diffing algorithm used in their applications as it could affect the new ‘for’ directive’s behavior.

Future Opportunities

The Angular team envisions extending this new syntax to accommodate more JS loop flavors, including async iteration, and for-in loops. Potential future improvements also include virtual scrolling and destructuring support.

There is also another RFC showing new feature in action — this feature is based new Built-In Control Flow. Checkout RFC for Deferred Loading

FAQ Recap

Let’s quickly address some common concerns developers might have about this new control flow syntax:

Existing structural directives: The current structural directives (NgIf, etc) will continue to work. However, Angular will strongly encourage developers to switch to the new syntax.
Structural directive concept: It will not be removed and remains an essential feature in Angular.
Syntax highlighting: Yes, the Angular Language Service will highlight keywords and expressions within the new control flow blocks.
Effect on query results: The new control flow will not affect query results.
Need to import new control flow: No, it will be built into the template language and automatically available to all components.
Performance: The new control flow might offer marginal improvements, particularly for ‘for’ and diffing.
Custom block groups and directives: At present, the new syntax doesn’t support libraries to define custom block groups, and you can’t add directives to the new control flow blocks.

What do you think?

This proposed syntax change is going to affect the way you write your templates. Do you think it’s needed? Is this change going to improve your DX and bring new devs aboard that prevously preferred to use different frameworks?

My main concerns lie within the transition period. We have a significant change in reactive primitive with Signals and now new Template Syntax is being introduced. It’s definitely coming together to paint a bigger picture that hasn’t been unveiled to us yet. For some time Angular devs are going to get many options to handle reactivity: RxJS, Signals, Promises, Change Detection (zone.js) + 2 ways of writing templates.

It will definitely take a long time to fully transition to the new vision and it’s not like you can speed this process up. Now the question would be, is the cost of these advancements worth what we are getting in the end?

Make sure to let me know and have a discussion!

I hope you liked my article!

If you did you might also like what I am doing on Twitter. I am hosting live Twitter Spaces about Angular with GDEs & industry experts! You can participate live, ask your questions or watch replays in a form of short clips :)

If you are interested drop me a follow on Twitter @DanielGlejzner — would mean a lot :). Thank You!

Oh no! My Coffee cup is empty :( …
… if you want to refill go ahead :) https://ko-fi.com/danielglejzner

Angular with Nx in 2023? Seriously, You Should!

Daniel Glejzner — Wed, 24 May 2023 06:30:00 +0000

Honestly, it’s hard for me see why you wouldn’t want to use Nx for your Angular application. And no, you don’t need a monorepo. Let me break it down for you.

A lot of people find it tough to set up a folder structure and app architecture that’s easy to use, can grow over time, and can be managed by a big team. This is tough for polyrepos and even tougher for monorepos. But whether you’re working with a polyrepo or a monorepo, Nx can help you out.

Briefly — What is Nx?

Nx is a powerful open-source build system that provides tools and techniques for enhancing developer productivity, optimizing CI performance, and maintaining code quality. — Nx docs.

I pulled this straight from the official documents. To me, Nx is like a trusty foundation stone for any Angular app architecture. I’ve built a ton of apps using Nx — and let me tell you, it’s like having a helpful buddy along the way.

Nx nudges you into:

Structuring your codebase into well-defined modules for better manageability
Ensuring a consistent setup through the systematic use of code generation
Avoiding the potential pitfalls of messy dependencies that could compromise the maintainability of your code
Helping you automatically visualize your structure through dependency graph and much much more.

While Nx lays the groundwork for success, it doesn’t promise a win. It’s still up to you to stick with the best practices, pick a method that’s proven in battle (like DDD or FDD), and define *module boundaries, and so on.

Once you’ve got everything set up just right, adding new features and growing your app is a piece of cake. But let’s start with a first step.

The Big Decision

Software projects can be big, small, simple, complex, and have different team setups. So, deciding how to set up your project really depends on a few things like how big your team is, how many apps you’re building, the size of your codebase, and how much code you’re sharing between projects.

Choosing between a polyrepo and a monorepo is a big decision and it’s something your team should sit down and chat about with your lead or architect. It’ll be even better if that person knows their way around Angular applications, team setups, workflows, and all those high-level bits and pieces.

Nx Specific Approach

Now let’s compare Nx monorepo approach vs Nx non-monorepo approach with example of Angular app.

With Nx — In both cases you have to create your features as libraries. Don’t get discouraged by this step. Having things as libs allow Nx to do it’s magic and for you it’s almost the same as simple directories.

Our application will have two libraries, Tasks for task-related functionalities, and Users for user-related functionalities.

Nx Monorepo Setup

Monorepo Approach

Monorepo approach is basically putting all closely related projects into one big box — a single repository.

Sounds scary, isn’t it? That’s why a lot of people immediately disregard Nx — because they think its for monorepo only. It’s not. But I will explain that later — for now let’s focus on monorepo.

Key Steps and Differences:

Creating the workspace: An Nx workspace is created with npx create-nx-workspace@latest — preset=angular-monorepo
Creating the application: We generate an Angular application inside the workspace using npx nx generate @nrwl/angular:app task-manager.
Generating libraries: npx nx g @nx/angular:library tasks, npx nx g @nx/angular:library users
Dependency management: In a monorepo, all apps and libraries share the same node_modules, simplifying dependency management.
Building the application: The command npx nx build task-manager builds the application. Due to Nx's advanced computation caching, build times can be significantly reduced in a monorepo setup. It’s only going to build the part of app that you made changes for.

    task-management/
    ├── apps/
    │   ├── task-manager/
    │   │   ├── src/
    │   │   │   ├── app/
    │   │   │   ├── main.ts
    │   │   │   ├── index.html
    │   │   │   ├── ...
    │   │   ├── angular.json
    │   │   ├── ...
    │   ├── task-manager-e2e/
    │   │   ├── ...
    ├── libs/
    │   ├── tasks/
    │   │   ├── src/
    │   │   │   ├── lib/
    │   │   │   ├── index.ts
    │   │   │   ├── ...
    │   │   ├── ...
    │   ├── users/
    │   │   ├── src/
    │   │   │   ├── lib/
    │   │   │   ├── index.ts
    │   │   │   ├── ...
    │   │   ├── ...
    ├── node_modules/
    ├── package.json
    ├── nx.json
    ├── project.json
    ├── ...

Here, all applications are stored under the apps/ directory, while libraries are stored under the libs/ directory. They share the same node_modules/ directory, which houses dependencies for the entire workspace.

Pros:

Code Sharing: Monorepo allows seamless code sharing across different applications and libraries. This can significantly reduce code duplication in projects with multiple apps sharing common functionality. It’s all there in one repository which makes your IDE aware of literally everything. No more NPM packages to worry about.
Atomic Changes: Changes across multiple projects can be committed all at once (it’s just a “git branch”), making it easier to track. Nx is smart enough to only build/test what has been affected by your change. So for example only 2 out of 20 apps & 5 out of 100 libs.
Unified Build & Test Setup: With all projects in the same place, you can build, test, and release them all together. Setting up and keeping integration tests running smoothly is easier when all projects are under the same roof.
Simplified Dependency Management: All your projects share the same dependencies. In theory there is a way to have multiple different versions — however Nx team strictly encourages single-version policy. So, there’s only one package.json file you need to worry about. It also enforces keeping everything in sync. You have to do more work across all of the apps to make sure everything is working fine after updates — which in the end is good for the project.
Code Consistency: It’s simpler to make sure everyone is playing by the same rules when all your projects are in one place. You can designate ownership of certain apps/parts to teams/people in your organization. You enable easy way to onboard new developers — they can utilize code generators and you make sure the structure is always as expected.
Streamlined Onboarding: It’s easier for new developers to get started when everything’s located in one place.

Monorepo isn’t perfect either. Here are a few things to watch out for:

Cons:

Scalability: As your codebase expands, the time it takes to build and test might also grow. That said, Nx does a solid job in tackling this with its computation caching and affected commands. However — large codebases can still lead to slower IDE performance and longer test, build, and CI times.
Increased Complexity: A monorepo can get complex, especially with large codebases and teams. You need to be very strict and have the rules set right to keep order easily.
Merge Conflicts: With multiple teams working on different applications in the same repository, the potential for merge conflicts increases.
Read Access Control: In the world of Monorepo, everyone typically gets read access to everything. There is no easy way to restrict read access to specific projects. This might not be the best fit if you need more control over who gets to touch what.
Code Reviews: With potentially larger scopes of changes, code reviews might feel overwhelming. You can potentially solve this issue assigning the “codeowners” to certain parts.

Nx Non-monorepo Setup

Polyrepo Approach

Let’s talk about the Polyrepo Approach. Here, each project gets its own personal space — its own separate repository. If you’re a big organization, you might have to juggle between 10–20 separate repositories.

Key Steps and Differences:

Creating the workspace: When creating an Nx workspace for a standalone setup, we use npx create-nx-workspace@latest, select Standalone Application, and name the application task-manager.
Generating libraries: npx nx g @nx/angular:library tasks, npx nx g @nx/angular:library users
Building the application: The command npx nx build task-manager builds the application. The computation caching in Nx also works in a standalone setup but has less impact since there's only one app.

    task-manager/
    ├── src/
    │   ├── app/
    │   ├── main.ts
    │   ├── index.html
    │   ├── ...
    ├── libs/
    │   ├── tasks/
    │   │   ├── src/
    │   │   │   ├── lib/
    │   │   │   ├── index.ts
    │   │   │   ├── ...
    │   │   ├── ...
    │   ├── users/
    │   │   ├── src/
    │   │   │   ├── lib/
    │   │   │   ├── index.ts
    │   │   │   ├── ...
    │   │   ├── ...
    ├── node_modules/
    ├── project.json
    ├── nx.json
    ├── package.json
    ├── ...

Here, the structure is simpler. The application and its source files are at the root of the project. Libraries are still present in a libs/ directory — but you can name that directory however you like. You can also have multiple libs directories.

With non-monorepo appraoch you still get all of that out of the box:

Ready to go Angular application at the root of the Nx workspace (src/app)
Cypress based e2e test (e2e/)
Prettier preconfigured
ESLint preconfigured
Jest preconfigured

Pros:

Simplified Project Structure: Standalone setup has a simpler project structure, making it easier for smaller teams or for those just starting with Nx. One repository equals one project, making it easier to understand and find your way around the codebase.
Isolation: Standalone setup keeps applications isolated from each other. It’s beneficial when the apps don’t have much in common or when strict isolation between them is required. Each repository is its own island, encouraging you to write code that stands alone, which can lead to higher quality code.
Specific Configurations: Standalone applications can have their own specific configurations, providing flexibility when different apps have differing requirements.
Controlled Read Access: You get to decide who gets in and who doesn’t. This means you can limit read access to certain apps or parts of your codebase, making Polyrepos a good choice if different teams or people need different levels of read access.
Manageable Code Reviews: Code reviews are less of a headache, as changes are usually tucked away in specific repositories.

But, polyrepos are not perfect. There can be some bumps along the way.

Cons:

Code Duplication: Sharing code between projects can turn into a copy-paste festival if you’re not careful. Or you can end up maintaining 10 NPM packages across your apps and struggle with keeping everything up to date with latest versions. Standalone setups do not facilitate code sharing as efficiently as monorepos, making them less suitable for projects with multiple apps that share significant functionality.
Multiple Build Configurations: If you have multiple standalone applications, each may require a separate build configuration.
Dependency Management: This can get a bit tricky. Each project has its own package.json file, and you might end up with different versions of third-party dependencies across projects.
Coordinating Changes: Making changes that affect several projects at once can be overwhelming. A single feature or bug fix could need changes in a few different repositories.
Tricky Integration Tests: Setting up and keeping integration tests running smoothly across different repositories can be more of a hassle compared to a monorepo setup.

Go with Nx

Choosing between a monorepo and a non-monorepo (polyrepo) setup really comes down to what your project needs. If you’ve got a big project with a lot of shared stuff, a monorepo could be a good fit. But if your project is smaller or needs to keep things separate, have better control of read access restrictions, then a standalone setup might be the way to go.

Both have their pros and cons — but as mentioned before. Doesn’t matter which one you pick. Nx has something in store for you for both options.

I cannot see any reason not to start Angular project without Nx as companion. For monorepo or polyrepo approach.

I hope you liked my article!

If you are interested drop me a follow on Twitter @DanielGlejzner — would mean a lot :). Thank You!

Angular Job Interview: How Important are Technical Details When Hiring a Developer?

Daniel Glejzner — Fri, 19 May 2023 15:19:29 +0000

Twitter Spaces vs Podcasts?

⚡ Spaces empower the whole Angular community to interact
My goal is to bring experts to you!

Florin Mateescu used this to ask Brecht Billiet and GDE Chau N Tran about importance of:

⚛️ Algorithms & data structures
🗣️ Soft skills
🐲 Years of experience

Full audio in comments

Deactivate Angular NgZone selectively — the easy way

Daniel Glejzner — Wed, 17 May 2023 10:12:16 +0000

A fine-grained control over Angular's change detection mechanism is here and ready to be used!

Signals and change detection optimization is not quite there yet. But even today there are ways to help you manage change detection easily.

The reactive extensions for Angular, RxAngular, provide us with powerful tools to control and optimize our application performance. One of these tools is the unpatch directive.

What is Unpatch Directive?

In Angular, the NgZone service manages the execution of tasks inside or outside Angular’s change detection mechanism. Veteran Angular developers describe this as two zones. By default, Angular runs almost everything inside an Angular Zone, meaning any asynchronous operations like setTimeout, Promise, or any DOM events will trigger Angular's change detection.

While this default mechanism ensures that the UI is consistently updated with the latest changes, it can lead to performance issues when handling high-frequency events, such as mousemove or scroll. These events can trigger a large number of unnecessary change detection cycles.

This is where the unpatch directive steps in. By using unpatch, we can prevent certain events from triggering change detection — improving performance. The directive can be used on any element to which you apply event bindings.

    <button unpatch (click)="triggerSomeMethod($event)">click me</button>

The unpatch directive prevents the 'click' event from triggering Angular's change detection. By default unpatch all registered listeners of the host it is applied on. If you want you to specify exactly what to unpatch - you can provide a list as shown in examples below.

How to utilize `unpatch` in your app

Let’s dive into a real-world scenario where unpatch can significantly boost performance. Imagine we're building a real-time data visualization tool, handling a large number of DOM elements and several high-frequency events like mousemove, scroll, etc.

Initially, we have a component rendering a large dataset in a tabular format. Each row of the table has a hover effect showing additional data.

    <div *ngFor="let data of largeDataSet">
      <div (mousemove)="showAdditionalData(data)" class="data-row">
        <!-- Basic data display -->
      </div>
    </div>

In this scenario, the mousemove event fires very frequently, triggering change detection for the entire component tree. Even if the additional data doesn’t change, Angular still rerenders the component tree, leading to performance issues.

Now, let’s optimize this with the unpatch directive:

    <div *ngFor="let data of largeDataSet">
      <div [unpatch]="['mousemove']" (mousemove)="showAdditionalData(data)" class="data-row">
        <!-- Basic data display -->
      </div>
    </div>

By using unpatch, we're instructing Angular not to run change detection every time the 'mousemove' event fires.

Kanban Board

Imagine a Kanban board application where users can drag and drop tasks between different columns.

    <div class="task" 
         (dragstart)="dragStart($event, task)" 
         (dragover)="dragOver($event)" 
         (drop)="drop($event, column)">
      <!-- Task display -->
    </div>

Here, the dragstart, dragover, and drop events are firing when a user drags a task and drops it onto another column. Each of these events triggers Angular’s change detection, which can lead to performance issues, especially with a large number of tasks.

Now, let’s optimize this with the unpatch directive:

    <div class="task" 
         [unpatch]="['dragstart', 'dragover', 'drop']" 
         (dragstart)="dragStart($event, task)" 
         (dragover)="dragOver($event)" 
         (drop)="drop($event, column)">
      <!-- Task display -->
    </div>

With the unpatch directive, the dragstart, dragover, and drop events will no longer trigger Angular's change detection. As a result, the performance of the application can significantly improve when users are frequently dragging and dropping tasks.

However, please note that you would need to manually trigger change detection if any of these events cause changes that should be reflected in the UI!

Angular’s ChangeDetectorRef service allows you to manually run change detection on a component and its child components. You can use its detectChanges method to manually trigger change detection:

    constructor(private changeDetector: ChangeDetectorRef) {}

    drop(event: DragEvent, column: Column) {
      // logic 

      // manually trigger change detection
      this.changeDetector.detectChanges();
    }

The unpatch directive provided by the RxAngular library is a powerful tool for optimizing Angular applications. By preventing unnecessary change detection cycles, it helps to improve the performance and responsiveness of applications.

Make sure to also check out other goodies that RxAngular offers.

I hope you liked my article!

If you are interested drop me a follow on Twitter @DanielGlejzner — would mean a lot :). Thank You!

Angular 16 is out now: Learn how to Replace RxJS with Signals

Daniel Glejzner — Sat, 06 May 2023 06:41:50 +0000

Angular 16 is out now: Learn how to Replace RxJS with Signals

Here I have one specific real world example for you, raw code comparison. Nothing more, nothing less!

But but but… Signals & RxJS right — it’s not supposed to replace it?

Couldn’t help myself and spark a little controversy in the title. Example I have is completely replacing RxJS implementation with Signals.

Signals are meant to replace RxJS to simplify your reactive code. However, only synchronous RxJS code — I wouldn’t replace asynchronous parts :).

Search & Pagination (RxJS)

Here is RxJS code of small feature that allows you to search for a user and use pagination. It’s meant to showcase how synchronous RxJS code can be simplified with Signals.

I asked for code review for this parts. While I have been talking with my friends — each one of them found different things to improve in my initial code and had different vision on how this could look like.

Additionally there have been occasional bugs and potential memory leaks. This is exactly why working with synchronous RxJS is not ideal. I also bet that looking at this example you also have a different kind of implementation in mind!

    const users = [
      { id: 1, name: 'Spiderman' },
      { id: 2, name: 'Hulk' },
      { id: 3, name: 'Wolverine' },
      { id: 4, name: 'Cyclops' },
      { id: 5, name: 'Venom' },
    ];

    @Component({
      selector: 'my-app',
      standalone: true,
      imports: [CommonModule, FormsModule],
      template: `
      <input [ngModel]="searchInput$ | async" (ngModelChange)="searchUser($event)" placeholder="Search">

      <ul>
        <li *ngFor="let user of paginatedAndFilteredUsers$ | async">{{ user.name }}</li>
      </ul>

      <button (click)="goToPrevPage()">Previous</button>
      pag. {{ currentPage$ | async }}
      <button (click)="goToNextPage()">Next</button>
    `,
    })
    export class App {
      readonly firstPage = 1;

      itemsPerPage = 2;

      searchInput$ = new BehaviorSubject('');
      currentPage$ = new BehaviorSubject(this.firstPage);

      paginatedAndFilteredUsers$ = combineLatest([
        this.currentPage$.pipe(distinctUntilChanged()), // trigger only when it actually changes
        this.searchInput$.pipe(
          distinctUntilChanged(),
          map((searchText) =>
            users.filter((user) =>
              user.name.toLowerCase().includes(searchText.toLowerCase())
            )
          )
        ),
      ]).pipe(
        map(([currentPage, filteredUsers]) => {
          const startIndex = (currentPage - 1) * this.itemsPerPage;
          const endIndex = startIndex + this.itemsPerPage;
          return filteredUsers.slice(startIndex, endIndex);
        })
      );

      searchUser(searchText: string): void {
        this.searchInput$.next(searchText);
        if (this.currentPage$.value > this.firstPage) {
          this.currentPage$.next(this.firstPage);
        }
      }

      goToPrevPage(): void {
        this.currentPage$.next(Math.max(this.currentPage$.value - 1, 1));
      }

      goToNextPage(): void {
        this.currentPage$.next(
          Math.min(this.currentPage$.value + 1, this.itemsPerPage + 1)
        );
      }
    }

Search & Pagination (Signals)

Exactly the same implementation but done with Signals

    const users = [
      { id: 1, name: 'Spiderman' },
      { id: 2, name: 'Hulk' },
      { id: 3, name: 'Wolverine' },
      { id: 4, name: 'Cyclops' },
      { id: 5, name: 'Venom' },
    ];

    @Component({
      selector: 'my-app',
      standalone: true,
      imports: [CommonModule, FormsModule],
      template: `
      <input [ngModel]="searchInput()" (ngModelChange)="searchUser($event)" placeholder="Search">

      <ul>
        <li *ngFor="let user of paginatedAndFilteredUsers()">{{ user.name }}</li>
      </ul>

      <button (click)="goToPrevPage()">Previous</button>
      pag. {{ currentPage() }}
      <button (click)="goToNextPage()">Next</button>
    `,
    })
    export class App {
      readonly firstPage = 1;

      itemsPerPage = 2;

      searchInput = signal('');
      currentPage = signal(this.firstPage);

      paginatedAndFilteredUsers = computed(() => {
        const startIndex = (this.currentPage() - 1) * this.itemsPerPage;
        const endIndex = startIndex + this.itemsPerPage;
        return users
          .filter((user) =>
            user.name.toLowerCase().includes(this.searchInput().toLowerCase())
          )
          .slice(startIndex, endIndex);
      });

      searchUser(searchText: string): void {
        this.searchInput.set(searchText);
        if (this.currentPage() > this.firstPage) {
          this.currentPage.set(this.firstPage);
        }
      }

      goToPrevPage(): void {
        this.currentPage.update((currentPage) => Math.max(currentPage - 1, 1));
      }

      goToNextPage(): void {
        this.currentPage.update((currentPage) =>
          Math.min(currentPage + 1, this.itemsPerPage + 1)
        );
      }
    }

Now comparison one by one

    //RxJs
    @Component({
      selector: 'my-app',
      standalone: true,
      imports: [CommonModule, FormsModule],
      template: `
      <input [ngModel]="searchInput$ | async" (ngModelChange)="searchUser($event)" placeholder="Search">

      <ul>
        <li *ngFor="let user of paginatedAndFilteredUsers$ | async">{{ user.name }}</li>
      </ul>

      <button (click)="goToPrevPage()">Previous</button>
      pag. {{ currentPage$ | async }}
      <button (click)="goToNextPage()">Next</button>
    `,
    })

    // Signals
    @Component({
      selector: 'my-app',
      standalone: true,
      imports: [CommonModule, FormsModule],
    template: `
      <input [ngModel]="searchInput()" (ngModelChange)="searchUser($event)" placeholder="Search">

      <ul>
        <li *ngFor="let user of paginatedAndFilteredUsers()">{{ user.name }}</li>
      </ul>

      <button (click)="goToPrevPage()">Previous</button>
      pag. {{ currentPage() }}
      <button (click)="goToNextPage()">Next</button>
    `,
    })

    //RxJS
    readonly firstPage = 1;

      itemsPerPage = 2;

      searchInput$ = new BehaviorSubject('');
      currentPage$ = new BehaviorSubject(this.firstPage);

      paginatedAndFilteredUsers$ = combineLatest([
        this.currentPage$.pipe(distinctUntilChanged()),
        this.searchInput$.pipe(
          distinctUntilChanged(),
          map((searchText) =>
            users.filter((user) =>
              user.name.toLowerCase().includes(searchText.toLowerCase())
            )
          )
        ),
      ]).pipe(
        map(([currentPage, filteredUsers]) => {
          const startIndex = (currentPage - 1) * this.itemsPerPage;
          const endIndex = startIndex + this.itemsPerPage;
          return filteredUsers.slice(startIndex, endIndex);
        })
      );

    //Signals
    readonly firstPage = 1;

      itemsPerPage = 2;

      searchInput = signal('');
      currentPage = signal(this.firstPage);

      paginatedAndFilteredUsers = computed(() => {
        const startIndex = (this.currentPage() - 1) * this.itemsPerPage;
        const endIndex = startIndex + this.itemsPerPage;
        return users
          .filter((user) =>
            user.name.toLowerCase().includes(this.searchInput().toLowerCase())
          )
          .slice(startIndex, endIndex);
      });

    //RxJS
    searchUser(searchText: string): void {
        this.searchInput$.next(searchText);
        if (this.currentPage$.value > this.firstPage) {
          this.currentPage$.next(this.firstPage);
        }
      }

    //Signals
    searchUser(searchText: string): void {
        this.searchInput.set(searchText);
        if (this.currentPage() > this.firstPage) {
          this.currentPage.set(this.firstPage);
        }
      }

    //RxJS
    goToPrevPage(): void {
        this.currentPage$.next(Math.max(this.currentPage$.value - 1, 1));
      }

    goToNextPage(): void {
        this.currentPage$.next(
          Math.min(this.currentPage$.value + 1, this.itemsPerPage + 1)
        );
      }

    //Signals
    goToPrevPage(): void {
        this.currentPage.update((currentPage) => Math.max(currentPage - 1, 1));
      }

    goToNextPage(): void {
        this.currentPage.update((currentPage) =>
          Math.min(currentPage + 1, this.itemsPerPage + 1)
        );
      }

Conclusion

Please remember that currently Signals are in developer preview only! However they are here to stay — and I have to say I love how they replace and simplify code initially written with synchronous RxJS in mind.

Disclaimer

If you are reading this in 2024 it means — I haven’t updated this content. You should find me and tell me how bad I behaved. Example here is based on initial developer preview of Signals available in Angular 16 on it’s release date.

This is going to change once full vision of Signals is available. If you tracked RFCs and proposals — you might immediately think that example presented would work differently with input based signals that are still not available to use.

I hope you liked my article!

If you are interested drop me a follow on Twitter @DanielGlejzner — would mean a lot :). Thank You!

Join the Angular v16/17 Development: — Discover How to Collaborate with the Angular Team!

Daniel Glejzner — Wed, 03 May 2023 06:00:00 +0000

The official Signals RFC has ended. But do you know what RFC is? Many people don’t!

I recently got involved in the process of releasing a new version of Angular. In the past, I didn’t get involved because I didn’t know much about it. I didn’t follow the process and barely talked with the community. I was missing out!

Signals RFC officially closed

RFC means “Request for Comments”. The Angular Team wants to hear your opinion on the changes they propose. The Signals RFC got a lot of attention with over 1000 comments.

But compared to the millions of Angular developers around the world, this isn’t much. Many of them don’t take part in shaping Angular’s future or talking with the great community. Which is a shame.

The Angular Team really listens to what people say. They’ve made changes based on feedback, and they’re planning to make more.

Example:

fromSignal and fromObservable renamed to toObservable and toSignal

Voice your concerns and be heard!

Sure, everyone likes a pat on the back, but what the Angular Team values most is constructive criticism. It might be tough to hear, but it’s the best way for them to improve.

Looking at the RFC section can be tough with so many comments and discussions. The technical details are hard enough to understand, let alone keeping up with all the comments.

To help the community understand what’s going on, I started writing articles about recent Sub-RFCs. My goal was to explain things simply but still provide enough information to get people thinking and talking.
Sub-RFC 4 for Angular Signals sparks interesting discussion started by RxJS author — Ben Lesh

Signals Sub-RFC 3 — New Angular Reactive Approach or a Path to Confusion?

Minko Gechev on Angular 16 & 17 — game changer or loss of identity ?

The big summary of concerns

My articles seem to be helping people stay up to date — learn that they can play an active role and talk directly with the Angular Core Team! All it takes is to drop your thoughts in RFC which is located in Discussions section of Angular repo (GitHub).

However, I noticed that many people were still worried about the changes suggested in the RFC. So, I decided to write a summary of all the concerns raised in the comments under the Signals RFC/Sub-RFCs and post it before the deadline.

I have done so without dwelling on technical details as these can change many times.

The main goals were:

to make sure the Angular Team could easily find this summary for future planning.
to help community members understand the possible downsides of the upcoming changes - filtered out of the communication noise in Discussions section under RFC.

With the help of some community members, I managed to do it. You can check it out here: https://github.com/angular/angular/discussions/49685#discussioncomment-5697665

Angular Signals RFC — Closing Summary

Alex Rickabaugh from the Angular Core Team posted a summary. The Angular Team was happy with the active participation and acknowledged some of the concerns raised by community members.

Having this in mind — I also hosted a Twitter Spaces session with Angular experts to discuss the summary. To our surprise, some members of the Angular Core Team joined us and answered our questions!

Angular 16 and Beyond: Bringing The Community Along!

First — Angular Mark Thompson joined and listened to us talking for some time before appearing on the stage. He ensured us that latest changes are not going to leave anybody behind.

Staying Responsible in Angular: Evolving for the Future

After Mark, Alex Rickabaugh joined the conversation to explain more and further assure us that a lot of things have not been decided yet. Angular Team is treating the responsibility for evolving Angular as priority. Final outcome will be influenced by the community.
I recommend replaying the whole space — a lot of valuable info and discussions! https://twitter.com/i/spaces/1lPKqBkRwbbGb?s=20

Results of actions taken

The actions I took brought the community closer together, helped people understand the RFCs, and gave us a chance to talk directly with the Angular Team. This helped calm down many concerned community members and got them excited about the future of Angular. Now they’re planning to get involved in future RFCs to help shape Angular’s future.

What you can do to help along the way?

Pre-RFC Phase

This is where the Angular Team and the community talk about possible new features and improvements.

Actions you can take: Your ideas and feedback are important here.

RFCs Phase

The Angular Team writes formal RFCs to suggest new features or changes. These documents are published on the **Angular GitHub repository** for review and feedback.

Your Role: This is your chance to give your thoughts on the proposed changes.

Sub-RFCs and Discussions

Based on the feedback, the Angular Team might create more Sub-RFCs to adjust the proposed changes or expand on them.

Actions to take: This involves more discussions and changes.

Final Design and Implementation:

After the RFCs and Sub-RFCs are final, the Angular Team starts making the changes a reality. This includes writing code, testing, and updating documentation.

What you can do: You can help by joining in on the implementation process, raising pull requests, reporting issues, and helping with documentation.

Beta and Release Candidate (RC) Versions

Beta and RC versions of new Angular are released to let developers test new features.

Guess what?: Your job here is to test, test, and test some more!

Final Release

After sorting out the issues found during the Beta and RC phases — Angular Team releases the final new version. But your job doesn’t end here.

Contribute: Even after the final version is out, there’s always more to do — keep an eye out for potential issues and continue to contribute.

So, are you ready to help shape the future of Angular? Let’s do it together!

Upcoming RFCs

Testing with Signals
Control Flow

I hope you liked my article!

If you are interested drop me a follow on Twitter @DanielGlejzner — would mean a lot :). Thank You!

Minko Gechev on Angular 16 & 17 — game changer or loss of identity ?

Daniel Glejzner — Tue, 18 Apr 2023 08:32:42 +0000

In a recent podcast, Minko Gechev — Lead and manager for Angular developer relations - shared valuable insights into the future of Angular and its planned developments. Let’s go over key takeaways from that interview, focusing on the framework’s future direction.

Hydration API

Angular Lead mentioned the new hydration feature that Angular is introducing, which helps in server-side rendering and improves performance. Angular is now focusing on partial hydration, which will result in faster rendering times for applications.

The goal is to have better SSR support and more seamless transitions between server-rendered and client-rendered content.

Introducing DestroyRef

One of the most notable enhancements discussed by Minko is the introduction of DestroyRef. This feature enables developers to invoke the ngOnDestroy hook more flexibly and integrate it with various parts of the component’s lifecycle.

class ExampleComponent {
  constructor() {
    inject(DestroyRef).onDestroy(() => {
      // do something when the component is destroyed
    })
  }
}

This was previously impossible, as developers had to place the ngOnDestroy code directly in the method itself. DestroyRef will improve integration with libraries like RxJS, making Angular development more efficient.

Angular Material Libraries and Design Tokens

Minko highlighted the impact of design tokens on Angular app development, particularly within Material 3. Design tokens provide developers with greater flexibility for customizing existing Material components.

The Material team at Google will ensure that these tokens remain stable, allowing developers to create finely-tuned components without worrying about frequent changes.

Flattening the Angular Learning Path

Simplifying the Angular learning path is a priority for the Angular Team. Minko outlined several incremental improvements aimed at making it easier for developers to learn and work with Angular.

He says that RxJS is overwhelming for new developers and Angular Team aims to satisfy both sides. If you want to use RxJS go for it, that’s okay. If you don’t want to use it, go with Signals. Mix of both? Feel free.

Example of interop:

const counter: Signal<number> = toSignal(counter$);
const counter: Observable<number> = toObservable(mySignal);

Over time plan is to reduce the RxJS involvement in core parts of the framework. Are both new and existing developers going to be happy with the changes? Looking at recent discussions in RFCs — some veteran developers have major concerns about the approach for the future.

Standalone Components

The introduction of standalone components is a foundational step towards simplifying Angular. This feature will make learning about NgModule and scoping optional for developers working on standalone apps.

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  standalone: true,
  styleUrls: ['./app.component.scss']
})
export class AppComponent {}

There are also improvements expected for how standalone components are handled today.

Simplifying Component Authoring Experience

Minko briefly mentioned that the Angular Team is considering making component, directives, and pipe decorators optional. Aim would be to further simplify the component authoring experience and reduce complexity.

This will result in a simpler, more functional-based approach for creating inputs and outputs.

Angular CLI Simplification

The CLI will be updated to have less conceptual overhead, and improvements will be made to the project structure, making it easier for developers to navigate and work with Angular projects.

Improved Documentation and Learning Experience

Angular Team will focus on creating more engaging and digestible tutorials, helping developers learn Angular more efficiently and enjoyably.

This would be a giant help and improvement over current shape of Angular documentation available today.

In summary, the future of Angular looks promising, with a focus on simplification and improved learning experiences for developers. The introduction of DestroyRef, design tokens, and the flattening of the Angular learning path are just a few of the key developments that will shape the framework’s direction moving forward.

On the other hand it sounds like it brings Angular more towards functional components and closer to main competitors on the framework market — React & Vue.

This is a very brief summary — I recommend watching the whole podcast!

Before I have summarized what is happening around Sub-RFC3 & Sub-RFC4 — looking at how things are shaping up — are you excited about the future of Angular?

Or a little bit worried that the framework might lose it’s identity with all of the changes that are coming?

You have a last chance to participate in Signals RFC! — Angular Team is closing it on Monday, April 24! — see here.

I hope you liked my article!

If you are interested drop me a follow on Twitter @DanielGlejzner — would mean a lot :). Thank You!

DEV Community: Daniel Glejzner

Always unsubscribe. No exceptions. Debate closed.

Truth is. It's not even worth the conversation.

Simple "Why":

Not convinced? Advanced "Why":

⭐ Angular Space Writer Mentorship Program

Exclusive to Angular Space Registered Members!

How It Works 👇

#1 Submit Your Idea

#2 Technical Review

#3 Content Delivery Review

#4 Final Review

High-Level Vision 👁️

Win-Win-Win 🏆

I’m going to publish the registration form soon! Make sure to keep an eye on Angular Space, E-mails, my tweets/posts on X 😎

What is Angular Query?

Short breakdown 👇

We have 2 packages to look at

ngneat is unofficial adapter

TanStack one is official

🟨 Core Concepts 🟨

🧹 Cache & Cleanup 🧹

💻 Significant DX improvements 💻

4 Laws of RxJS Observables

🏆 Here are 4 Laws of Observables 🏆

Law 1

Law 2

Law 3

Law 4

Microtask Queue + RxJS + Angular

The What, When, and Why

Microtask vs. Macrotask

RxJS and Asynchronicity

Angular’s Change Detection

The Role of Zone.js

RootZone (outerZone)

Forking and Hierarchical Structure

NgZone (innerZone)

A Typical Sequence

Not that hard huh?

Angular is getting New Template Syntax

Revamping Control Flow

Before

After

If-Else Blocks

Before (in theory)

After

Switch Block

What About Migration?

Future Opportunities

FAQ Recap

What do you think?

I hope you liked my article!

Angular with Nx in 2023? Seriously, You Should!

Briefly — What is Nx?

Nx nudges you into:

The Big Decision

Nx Specific Approach

Nx Monorepo Setup

Monorepo Approach

Key Steps and Differences:

Pros:

Cons:

Nx Non-monorepo Setup

Polyrepo Approach

Key Steps and Differences:

With non-monorepo appraoch you still get all of that out of the box:

Pros:

Cons:

Go with Nx

I hope you liked my article!

Angular Job Interview: How Important are Technical Details When Hiring a Developer?

Twitter Spaces vs Podcasts?

Deactivate Angular NgZone selectively — the easy way

What is Unpatch Directive?

How to utilize unpatch in your app

Kanban Board

I hope you liked my article!

Angular 16 is out now: Learn how to Replace RxJS with Signals

Angular 16 is out now: Learn how to Replace RxJS with Signals

How to utilize `unpatch` in your app