DEV Community: Arthur Groupp

Mastering Angular’s httpResource: Why Services Beat Components

Arthur Groupp — Thu, 04 Sep 2025 07:20:24 +0000

Data fetching has always been a tricky balancing act in Angular:
Where should the logic live — inside the component or abstracted elsewhere?

With the introduction of httpResource in Angular 19, this question is more relevant than ever. httpResource provides a reactive, signal-driven way to work with HTTP calls — but if misused, it can quickly tangle business logic with UI code.

In this article, we’ll explore what httpResource does, the temptation of in-component usage, and why service-based abstraction is the key to maintainable, scalable applications.

Why `httpResource` Matters

At its core, httpResource is a reactive wrapper around Angular’s HttpClient.
Instead of manually subscribing to Observables, httpResource integrates seamlessly with the signals ecosystem — meaning its results can be consumed by computed, effect, linkedSignal, or directly in templates.

Some key properties:

Eager execution: Unlike HttpClient, which only fires on subscription, httpResource eagerly triggers requests when its reactive dependencies change.
Automatic cancellation: If dependencies change mid-request, the in-flight request is canceled and a new one is issued.
Full HttpClient support: Interceptors and all other features still apply.

Example of a simple reactive resource:

userId = input<string>();
user = httpResource(() => `/api/user/${userId()}`);

Whenever userId changes, a fresh request is dispatched automatically.

The Temptation: Quick In-Component Usage

The most straightforward way to use httpResource is directly in a component:

@Component({ /* ... */ })
export class MyUserComponent {
  userId = input<string>();
  userResource = httpResource(() => `/api/user/${this.userId()}`);
}

It works — but this convenience comes at a cost.

By mixing data-fetching logic into the component:

You violate single responsibility — components should focus on rendering and interaction, not on orchestrating HTTP calls.
Business logic becomes scattered and harder to reuse.
Testing gets messy: mocking component state and HTTP behavior together is more complex.

For tiny apps or prototypes, this pattern might be acceptable. However, in real-world applications, it creates tight coupling and long-term maintenance headaches.

The Better Way: Abstract `httpResource` into Services

A cleaner approach is to define httpResource inside dedicated services, not components.

This service-based pattern offers several advantages:

Separation of concerns: Components stay UI-focused while services handle data logic.
Reusability: Multiple components can consume the same resource logic.
Simpler testing: Service logic can be tested independently of UI behavior.
Consistency: Teams can share and maintain standardized resource definitions.

Example: Service-Based Resource

// user.service.ts
@Injectable()
export class UserService {
  // A shared resource for all consumers
  readonly usersResource = httpResource(() => `/api/users`);

  // Factory method for reactive user fetching
  createUserResource($userId: Signal<string>) {
    return httpResource(() => (
      $userId() ? `/api/user/${$userId()}` : undefined
    ));
  }
}

// user-details.component.ts
@Component({ /* ... */ })
export class UserDetailsComponent {
  readonly userId = input<string>();
  readonly #userService = inject(UserService);

  readonly userResource = this.#userService.createUserResource(this.userId);
}

When Might In-Component Be Okay?

To keep this balanced:

Demos, prototypes, or playgrounds — quick feedback matters more than clean architecture.
Truly one-off fetches — where introducing a service would be unnecessary overhead.

But beyond these cases, service abstraction almost always pays off.

Conclusion: Future-Proof Your Angular Apps

Angular’s httpResource is a big step forward for reactive data fetching. But its power can become a liability if used naively inside components.

By moving your resource definitions into services, you get:

Cleaner components
Reusable data logic
Easier testing and scaling

👉 Next time you reach for httpResource, ask: “Should this live in a component — or does it belong in a service?”
Chances are, the service wins.

This simple shift will prepare your codebase for growth, teamwork, and the evolving Angular ecosystem.

Effective Debouncing in Angular: Keep Signals Pure

Arthur Groupp — Tue, 10 Jun 2025 14:45:38 +0000

Introduction

Debouncing is a foundational technique in front-end development, especially when working with high-frequency events like user input. It helps control the rate of function calls, ensuring that performance-intensive operations — such as server requests — don’t trigger excessively as users interact with the UI. A classic example is a search bar: as the user types, the application waits until they’ve paused before sending a request to fetch matching results. Another familiar case is an autocomplete panel, where each keystroke could theoretically initiate a query — but shouldn’t.

In Angular applications, especially those using the new reactive primitives introduced with Signals, developers often ask: “How do I debounce a signal?” At first glance, this might seem like a natural extension of reactive programming. However, applying debounce logic directly to Angular signals is fundamentally flawed.

The key reason is that Angular signals are not streams but value containers. While RxJS streams represent a sequence of values over time, signals represent the latest value at any given point. Treating signals like streams and attempting to debounce them leads to convoluted patterns, subtle bugs, and a misunderstanding of their core design.

Why Debouncing a Signals Directly Is an Antipattern

To understand why debouncing a signal is an antipattern, we need to be clear about what Angular signals are — and what they aren’t.

A signal in Angular is a reactive value. It reflects the current state of something at a given point in time. When the value changes, any consumers get the notification and react accordingly. But the signal itself doesn’t represent the timeline of changes — just the current one.

This signal definition makes signals conceptually very different from streams. Like an RxJS Observable, a stream represents a sequence of values emitted over time—each “next” call pushes a new event downstream. This distinction is critical: debounce is a time-based operator designed for streams, not values.

Let’s look at a misguided example:

const $query = signal('');  
const $debouncedQuery = debounce($query, 300);

The idea here might be to create a delayed computed version of the $query , but this violates the nature of a signal. The $debouncedQuery would now be a hybrid: not a clean, synchronous signal, but something pretending to behave like a stream. Even if you implemented a custom workaround (e.g., using setTimeout inside a computed), you’d lose predictability:

You can’t cancel pending debounce timers when the component is destroyed.
This introduces async lag into a system designed for synchronous propagation.
This confuses future maintainers who expect signals to be immediate and synchronous.

Furthermore, applying debounce inside a computed() or effect() makes the timing logic entangled with rendering logic, which is a recipe for complexity and bugs.

The Solution

Debounce needs to sit before the signal, not inside or on it. Signals result from some input; they should reflect the already-processed (i.e., debounced) value. Trying to bolt debounce onto a signal treats it like an observable stream, which it simply isn’t.

Rather than trying to debounce a signal, let’s debounce the source of the values — usually a DOM event or user interaction — before updating the signal. This preserves the core philosophy behind signals: they reflect the current value of the state without embedding time-based logic.

Enough theory. Let’s code.

Let’s walk through how we can implement ideas from above in the example of the input that delivers the search term for further API calls.

First things first, let’s implement the initial setup that will allow us to type and see what we are typing.

@Component({  
  selector: 'app-root',  
  template: `  
    <input type="search" name="q" />  

    <p>Search Term: {{ $query() }}</p>  
  `,  
})  
export class App {  
  readonly $query = signal('');  
}

We certainly will see nothing now in the results paragraph, but it’s a good start we need.

The next step will be to create the directive that will decorate the <input> HTML element.

@Directive({  
  selector: '[debounceTime]',  
})  
export class Debounce {  
  readonly value = model<string>();  
}

And apply it to the input element of the App component. Don’t forget to import it.

<input type="search" name="q" debounceTime [(value)]="$query" />

As you can see, we have already bonded the query to the value model of the directive.

Let’s implement the handler for the input event of the directive host and the value binding.

@Directive({  
  selector: '[debounceTime]',  
  host: {  
    '[value]': 'value()',  
    '(input)': 'handleInput($event.target.value)',  
  },  
})  
export class Debounce {  
  readonly value = model<string>();  

  handleInput(value: string): void {  
    this.value.set(value);  
  }  
}

Starting now, our directive functions like a proxy setting and receives value from the host, allowing us to see the search term as we type.

It's time for the real stuff. Let’s implement the debouncing mechanism in the directive.

@Directive({  
  selector: '[debounceTime]',  
  host: {  
    '[value]': 'value()',  
    '(input)': 'handleInput($event.target.value)',  
  },  
})  
export class Debounce {  
  #debounceTimer?: ReturnType<typeof setTimeout>;  

  readonly debounceTime = input(0, { transform: numberAttribute });  
  readonly value = model<string>();  

  handleInput(value: string): void {  
    clearTimeout(this.#debounceTimer);  

    if (!value || !this.debounceTime()) {  
      this.value.set(value);  
    } else {  
      this.#debounceTimer = setTimeout(  
        () => this.value.set(value),  
        this.debounceTime()  
      );  
    }  
  }  
}

The code above is pretty straightforward and self-explanatory. The value update is wrapped in the setTimeout function that is being canceled while the user is typing. The debounce time is provided through the directive input. (By the way, does anybody remember efforts to achieve the same with the input and RxJS pipe?)

Now, we need to add the debounce time to the input attribute in milliseconds, and we are done.

<input type="search" name="q" debounceTime="300" [(value)]="$query" />

If the user will type now, the search term will be debounced by 300 milliseconds. You can see that in the search term paragraph.

Conclusion

Debouncing remains essential for improving performance and user experience, particularly when handling high-frequency user inputs in Angular applications. However, it’s crucial to remember that Angular signals represent state snapshots, not streams of events, and thus are inherently incompatible with direct debounce operations.

As demonstrated, the optimal strategy involves applying debounce logic at the source level — typically DOM events or user interactions. This preserves the purity and simplicity of signals, ensuring they remain synchronous, predictable, and free from embedded timing logic.

The complete code of the example can be found here.

Special thanks to @eneajahollari for the inspiration to write this article.

Signals vs. Observables: Can One Truly Replace the Other?

Arthur Groupp — Sun, 27 Aug 2023 07:37:45 +0000

In Angular 16, the introduction of the reactive primitive known as 'signals' served as a significant addition to the developer's toolbox, leading to shifts in established practices. However, this also sparked confusion among many developers. Some hastily began to convert all observables in their applications to signals, while others did the reverse. This analysis seeks to clarify how Angular applications should navigate this new landscape.

Understanding the Basics

Before diving into the intricacies, let's establish some foundational definitions:

Stream: A stream is a sequence of asynchronous events or values.
Signal: As described in the core team's RFC, a signal is a wrapper around a value that is capable of notifying interested consumers when that value changes.

From these definitions, we deduce a critical distinction: while a signal primarily encapsulates a value and can notify subscribers (akin to a stream) about its changes, a stream can represent a sequence of values or even events without an inherent value. Consequently, while every signal has the potential to produce a stream, not all streams are supposed to originate from signals.

Practical Implications

When it comes to state management, signals excel. They allow us to define an initial value, update it as needed, and have the application seamlessly mirror these adjustments in the template.

However, challenges arise when there's no initial value, or the value is irrelevant. Consider button clicks as an example. Here, there's no "initial click," and the event's value is usually inconsequential. We're primarily interested in the event itself. While traditional JavaScript recommends callbacks for such scenarios, RxJS introduced event streams, enhancing flexibility through operator pipelines. Given this context, signals might not be the best fit. Using them to update values that won't influence outcomes could be seen as misapplying the tool.

HTTP Requests: A Unique Stream Scenario

HTTP requests are a peculiar kind of stream. They don't begin with an initial value and emit only once. Promises handle this beautifully. At present, Angular employs RxJS for HTTP operations. While future implementations may differ, there's little rationale, as of now, for migrating these to signals. Despite its singular emission, an HTTP request remains a stream, not merely a value wrapper.

Conclusion

The architecture of contemporary Angular applications is undoubtedly evolving, adding layers of complexity. This places a greater onus on developers and architects, compelling them to select patterns whenever they incorporate reactivity judiciously.
Given the insights provided, when confronted with the choice between signals and observables, consider the nature of the reactive primitive you're aiming to represent. Discern whether you're dealing with a state or an event, and let that guide your decision-making process.

Extending components, directives and services in Angular 14

Arthur Groupp — Wed, 01 Jun 2022 08:40:59 +0000

First, avoid it as much as possible. Extending components by itself is bad practice because it’s confusing code and adds more issues than actually helps. However, sometimes it can be helpful to combine common logic of similar components or directives into abstract class that they all will extend.

Let’s say, we have two components like this:

Of course, these components can be combined into one, but let’s assume that this is not the case and they have much more logic and templates specific to each.

Let’s modify our components and put shared logic into abstract base class that they will extend.

Much DRYer. The problem with this approach is dependencies. Since our base class has dependencies, it can’t inject it by itself because it doesn’t exist. Therefore, we must inject all those dependencies by ourselves in child classes and supply it to super().

Inject function

Starting with version 14 of Angular we can use function inject() to obtain instances of injection tokens in other functions, components, services, almost everywhere. This opens us great possibility to avoid repeating of these injections in derived classes. From now on, we can add static method to our base class that will initialize its dependencies.

Conclusion

I widely use abstractions and this feature excited me much. I was looking for the ability to avoid manual injections for a long time and now here it is.

Photo by Andrew Seaman on Unsplash

Types in Typescript plainly

Arthur Groupp — Thu, 17 Mar 2022 12:40:39 +0000

From the beginning, Typescript was presented as JavaScript improvement with addition of types. But why? More restrictions make less flexibility. We want to do whatever we want. For example, in JavaScript I can do the following:

let a = 42;
a = 'bunny';
let b = a / 2;

This code is legit in JavaScript. However, what will happen during runtime? b will get the value of NaN, not a number. And, if somewhere later on in our program we'll use b it can bring us to runtime error. In Typescript this code will not compile because we can't assign string value to variable, that is number. As a result, it will save us much debugging time and struggle with bugs.

Strict types allow preventing many runtime errors during development stage. Typescript allows usage of scalar and compound types. All scalar types are derived from JavaScript and equivalent to them. Compound types are extension of JavaScript object. By that, it shows the issues at compilation moment instead of runtime.

Compound types

Typescript allows describing the shape of application data by classes, interfaces and types. Classes are regular JavaScript classes and OOP is out of scope of this article. Additionally, Typescript suggests us to use interfaces and types. The key difference with classes is that interfaces and types are deleted by compiler. This limits their usage. For example, we can use keyword new with classes only. When we need to decide if we need to use a class or interface, we need to answer the question "Do I need to create an instance of this type?" The difference between interface and type is that we cannot extend type, but we can combine it with other types using logical operators (&, |). Classes can implement multiple interfaces and this is the only way of multiple inheritance in Typescript.

Annotation

By default, just declared variable has type any, that is self-explanatory. It means that we can assign value of any type to this variable. And it is definitely unacceptable in our world of law and order. To make variable strictly typed, we need to annotate it. Annotation is telling the compiler which type of data we can assign to this variable.

let a: number;
let b: boolean;

If we won't annotate the variable, it will have type any. In strict mode of the compiler (that must be default in all of our projects), we will get error about it.

Inference

Typescript has a type inference engine built in. It means that it can automatically detect the type of expression. To achieve benefits of this technology, we must initialize variables during declaration.

let a = 42;

a automatically will have type of number. The declaration with annotation will legit as well.

let a: number = 42;

However, we should avoid this way. The following example straightforwardly illustrates the benefit of inference.

const a: string = 'Kirk';

The type of a is string.
If we use inference:

const a = 'Kirk';

the type of a is "Kirk", that makes a much more precise.

Let's look at the following example:

type Names = 'Jim' | 'Spock' | 'Leonard';

function processName(name: Names) {}

const name1: string = 'Jim';
const name2 = 'Jim';

processName(name1);

processName(name2);

Calling function processName with name1 won't compile because argument of type 'string' is not assignable to parameter of type 'Names'.

There are cases when inference doesn’t work well. For example, if we initialize our variable by array of objects, that are instances of classes that extend one base class, we will have array of common type that will be combination of those children's classes. In this case we will want to manually annotate the variable as array of base class.

Sometimes the compiler gets confused. Usually, we should consider it as a gap in types architecture and probably revise it.

Functions

Highly important to specify functions returning types. Of course, Typescript can infer it from return statement. However, when we start to construct our function and annotate it, IDE will help us to return the correct type.

RxJS

Starting with version 7 of RxJS the typing was highly improved. And this is a good reason for upgrade of your projects. There is almost no need any more to annotate projection functions arguments, even after filter.

Conclusion

Understanding and usage of types is cornerstone of modern front-end development. We should always use inference wherever it's possible. We should always specify the return type of our methods and functions. And we should almost never use any.

Photo by Judith Frietsch on Unsplash

Domain Driven Design Implementation Plainly

Arthur Groupp — Tue, 09 Feb 2021 08:09:01 +0000

The idea of the Domain Driven Design in Angular perfectly presented and fully explored by Manfred Steyer in his DDD series. I won’t rewrite here all the theory and will leave it to your own revision of that great work. In this article, I will show my vision of its implementation with Nx-based monorepo.

Law and order

The main idea is to divide your application by the self-contained parts that we are going to call domains.

As the result, we will have organized structure instead of pile of libraries. Every domain will have the libraries inside it to serve its purpose. From now on, at least two tags will accompany every new generated library: domain and type. As you already understood, the domain tag will hold the domain name this library belongs to, and the type will label the category of the library. I suggest using these kinds of categories:

Category	Description	Allowed dependencies
domain-logic	Main logic of the domain. Contains of services, stores and entities data structures. Must provide façade services for maintaining encapsulation.	util
feature	Use case implementation. Contains of page and container components. Refers to domain-logic for data and calculations.	ui, domain-logic, util
ui	Collection of presentational components used in the domain features.	util
util	Collection of helper functions and classes. Usually it must be pure functions in separate file every, to improve the tree shaking functionality.	n/a

To provide this strict dependencies allowance we must set these rules in .eslintrc.json in the root of the repository.

    ...,
    "@nrwl/nx/enforce-module-boundaries": [
        "error",
        {
            "enforceBuildableLibDependency": true,
            "allow": [],
            "depConstraints": [
              {
                "sourceTag": "type:app",
                "onlyDependOnLibsWithTags": ["type:feature", "type:ui", "type:domain-logic", "type:util", "type:data-access"]
              },
              {
                "sourceTag": "type:feature",
                "onlyDependOnLibsWithTags": ["type:ui", "type:domain-logic", "type:util"]
              },
              {
                "sourceTag": "type:ui",
                "onlyDependOnLibsWithTags": ["type:util"]
              },
              {
                "sourceTag": "type:domain-logic",
                "onlyDependOnLibsWithTags": ["type:util"]
              },
            ]
        }
    ],
    ...

Domain or not domain

Must we create the domain for every functionality of the project? No. Domain is self-contained reusable part of the application that includes domain logic and at least one lazy loaded feature. There is no sense to create separate domain for every collection of service consumed by applications, it can be the standalone libraries or it can be domain named shared that will unite all these libraries with category data-access. In last case, we will need to add this category to linting rules.

The domain

Practically domain itself is a folder inside libs folder of monorepo. Inside this folder, we will collect all of the libraries belong to this domain.

So, let’s create one. To start new domain we need to create the library named domain inside directory with our new domain name. Let’s call it feature1:

$ nx g library domain --directory=feature1 --tags="domain:feature1,type:domain-logic"

Congratulations, new domain named feature1 was born.

Now let’s create the library that will hold our features (lazy loaded pages and other container components):

$ nx g library features --directory=feature1 --tags="domain:feature1,type:feature"

Let’s create page called page1 inside features:

$ nx g m page1 --routing --project=feature1-features
$ nx g component page1/page1 --flat --project=feature1-features

This will create folder page1 inside feature1/src/lib with new module and container component called page1.

Now, when we have our first container component, it will apparently need some data, maybe API calls. Time to prepare it inside domain logic library.

Domain Logic

Domain logic (DL) library is a heart of our new domain. Unlike domain features, it usually doesn’t make sense to have more than one domain logic. The structure of DL supposed to include at least three folders: application, entities and infrastructure.

Folder name	Description	Is exported?
application	Should hold façade services. I recommend creating separate façade service for every feature according to its needs to keep the principle of providing only the data customer demands. Definitely, if different features using similar data there is sense to use the same façade.	Yes
entities	Should hold interfaces, data classes, models, constants and injection tokens. The decision about exporting this folder depends on the demand of these data structures outside.	Yes/No
infrastructure	Should hold all calculations, data access services, guards, interceptors, stores and state management. I don’t recommend to export this folder, keep it as a private of the domain and provide access through the façade services.	No

As an example, we’ll create one infrastructure service and one façade for our page1.

$ nx g service infrastructure/feature1 --project=feature1-domain
$ nx g service application/page1-facade --project=feature1-domain

UI

UI library is the place where we are going to store our presentational components utilized by multiple features of the domain. It can’t be dependent on domain logic or features because neither service can be injected in presentational component. Additionally, this is the good place for Storybook.

I prefer to create every component with it’s own module in separate folder as ng-package. Let’s create UI library:

$ nx g library ui --directory=feature1 --tags="domain:feature1,type:ui"

To be able to import separate packages unlike the whole ui library, we need to make correction of the tsconfig.base.json in the root folder of the repository:

paths: {
    "@<org-name>/feature1/ui/*": ["libs/feature1/ui/src/lib/*"]
}

Conclusion

The Domain Driven Design gives us perfect tool to bring an order into single page applications becoming every day more and more complex. It allows safely sharing the development process between different divisions and still having consistent application.

Of course, it adds much more work and boilerplates but it will be rewarded in future maintenance.

Photo by Sikai Gu on Unsplash

Publishable libraries with Nx Monorepo - part 1

Arthur Groupp — Mon, 20 Jul 2020 12:08:13 +0000

Every developer one day come to a moment when he has number of ideas in different projects that will be great to combine and structure in one or more libraries. I came to this thoughts a few weeks ago and decided to express my last year experience in an open source project that I will constantly supplement in future. Maybe this project will grow up into something useful for other people. Anyway, it gives me opportunity to bring some order on the table.

To whom who is interested in project progress and resulting code – welcome to the repository.

I started this project many times and every time something went wrong. Building, testing, tons of work to bring everything to order and then small change breaks everything. Thanks G-d I meet wonderful people Lars Gyrup Brink Nielsen and Santosh Yadav and their great articles. I opened for myself wonderful world of Nx that solved all my previous problems almost out of the box (not all of them but it’s even more interesting this way).

I decided to base my project on Nx Workspace.

Naming

Choosing name is very important part for the repository creation process. Because we are building repository of publishable libraries, we will need to add them to Npmjs later on. So, the name of the repository will become the name of the organization on Npmjs.

Let’s register one right now. Go to Npmjs and signup/sign in. Then, click on your avatar at the right and open account menu. Click “Add Organization”. Now choose the name for your new organization. It must be unique in the scope of all npm world. Choose wisely, you won’t be able to change it later.

Workspace creation

Now, let’s create the workspace:

$ npx create-nx-workspace@latest <organization_name>

It can take a while to fetch necessary packages, so be patient. Choose “empty” as the answer to “What to create in the new workspace”, “Nx” to “CLI to power the Nx workspace” and “Only use local computation cache”. In a few minutes, we get our blank canvas where we will express our ideas.

Workspace adjustments

I prefer to use the latest versions of my tools, so let’s go into package.json and update the versions of typescript, ts-node and eslint. Then delete node_modules folder and re-install it. Then, let’s remove "private:true" from package.json.

Code formatting

Good code formatting is important. It improves code readability that highly help when you return to your code in a while. Additionally, it helps other people to understand your code quicker. Some people write the code well formatted from the beginning, others write everything in one line and happy with it. Generally, it’s a matter of taste and doesn’t effect on code behavior. I’m perfectionist by my nature and I want everything to be perfect. Great news for me was that my new workspace includes Prettier out of the box. Prettier is the package that allows you to format your code automatically according to rules. The rules are set in .prettierrc file as a json.

I made few changes in it just according to my own preferences. For example, I don’t like parentheses around a sole not necessary type annotated arrow function argument, or I want width of my page to be 110 chars, not 80. This is my .prettierrc:

{
  "singleQuote": true,
  "arrowParens": "avoid",
  "printWidth": 110
}

Initial commit

Nx already created the local git repository inside our workspace. Then, this is the right place to make first initial commit.

$ git commit -a -m "initial commit"

Repository

Now, when the changes are commited, let us add our project to GitHub. First, we need to create the repository on GitHub and then tell our local repository that now its remote is on GitHub.

$ git remote add origin https://github.com/user/repo.git

And push it to origin:

$ git push –u origin master

-u parameter makes git to remember the “remote” and “branch” and allows you all next times just use git push.

Starting to paint

The first set of libraries I plan to create will be universal ones that must work on server and client sides. Until now, our monorepo is empty and can do not much. To teach it how to do useful things we need to install plugins.

Let’s use nrwl/node plugin for our first project. This plugin gives us the functionality of creating, testing and building ready to use npm packages.

$ npm install -save-dev @nrwl/node

Scaffold new libraries:

$ nx g @nrwl/node:library lib1 --publishable --importPath="@<organization_name>/lib1" --tags="scope:public,type:util,target:all"
$ nx g @nrwl/node:library lib2 --publishable --importPath="@<organization_name>/lib2" --tags="scope:public,type:util,target:all"

--publishable parameter makes our library literally publishable on npm after building.

Tags are useful if the tags constraints in “.eslintrc” are set up. With these constraints, you can set up which projects can depend on which. We will return to this topic later.

Testing

Now, when we have our new projects in place we can start to fill it with code. Dramatically important part of the development is testing. Good test is not less art then a good code. Sometimes it is even more complex to test the behavior then to build it. The process of building unit test suites in Nx is very simple, all you need to do is to create file with suffix .spec.ts within your project folder and put your test code in it. Nx uses Jest as its default testing framework.

After scaffold of new library, you already have dummy simple test in it, so feel free to use it as an example in future.
To run test:

$ nx test lib1
$ nx test lib2

That is great during development phase. However, we need a way to test all of the projects at once. To achieve this we need to create command in our package.json:

"scripts": {
    ...
    "test:all": "nx affected:test --all --codeCoverage --skip-nx-cache"
}

Now, if you run npm run test:all all test suits will be run through all of the solution.

Building

After writing the code and being satisfied with the tests results, we want to publish our projects, so all other world will enjoy using it as we do. In order to publish we need to build our projects first:

$ nx build lib1
$ nx build lib2

You will find built and ready to publish versions in dist/libs/lib1 and dist/libs/lib2. Now we ready to publish it to npm. You need to go to dist directory of your project

$ cd /dist/libs/lib1

Important! When you publish public package for the first time you need to specify "--access public".

$ npm publish --access public

The rest times when you will publish this package, you can do it with

$ npm publish

Conclusion

We created the monorepo and two publishable libraries. We tested it, pushed source to GitHub, built and published to Npmjs. This is big and at the same time very basic step. Nx present perfect tool that allows us to concentrate on development and not on initial setup.

To be continued

Photo by Tekton on Unsplash

Angular Change Detection Plainly

Arthur Groupp — Mon, 20 Jul 2020 06:16:14 +0000

Change detection is one of the most exciting features of Angular framework. It gives us opportunity to work with data inside application without caring of its display. Actually, it takes values of our component class properties that were bound to template and update DOM every time the values are changed. Perfect! When I saw this for the first time, it was so amazing that I became Angular developer.

In most cases, it just works and you can be just happy with it. However, sometimes things are going wrong and you need to understand what happened.

In two words, Angular patch the browser during load with Zone.js and it gives us this functionality out of the box. There is very detailed and great written article about this mechanics "Angular Change Detection - How Does It Really Work?".

I will not repeat this article, I want to show you how the things work with the help of simple example we going to build.

Let’s go.

Initial setup

In this example, we will create the application that will detect and show us coordinates of mouse click on the screen. Create new Angular application. Create new folder data in app folder and create file coordinates.ts in it. It will be the interface representing Cartesian coordinates.

export interface Coordinates {
  x: number;
  y: number;
}

Generate component coords. In its template set the following:

<p>X: {{coords?.x || 0}}</p>
<p>Y: {{coords?.y || 0}}</p>

And in the component class let’s add input binding

import { Component, OnInit, Input } from '@angular/core';
import { Coordinates } from '../data/coordinates'

@Component({
  selector: 'app-coords',
  templateUrl: './coords.component.html',
  styleUrls: ['./coords.component.css']
})
export class CoordsComponent implements OnInit {
  @Input() coords: Coordinates;
  constructor() { }

  ngOnInit() {
  }
}

AppComponent should be modified a bit too:

import { Component, OnInit } from '@angular/core';
import { Coordinates } from './data/coordinates';

@Component({
  selector: 'my-app',
  template: `<app-coords [coords]="coords"></app-coords>`,
  styles: []
})
export class AppComponent implements OnInit {
  coords: Coordinates = {x: 0, y: 0};

  ngOnInit() {
  }
}

Start the application and you will see

X: 0
Y: 0

on the screen. You can click anywhere on the screen, nothing happens.

Initial setup is done.

Default change detection

Angular provides two change detection strategies. Default and OnPush. First, let’s make things work with Default.

Default change detection strategy detects when component class property or input data change and updates DOM. It's already fires when component send event, but we don't examine it in this example.

Modify ngOnInit of AppComponent this way:

ngOnInit() {
    window.addEventListener('click', (event: MouseEvent) => {
      this.coords = { x: event.x,y: event.y };
    });
}

Now, every time you click on the screen you will see the coordinates of your mouse cursor at the moment of click.

Feel free to play with it, it’s really amazing. Let’s see what’s happening. Every time you click on screen, the property of AppComponent coords get new object with coordinates. This property is input for CoordsComponent coords property. Every time you click, CoordsComponent get new value on its input and change detection fires.

Let’s make the task for Angular more complex. Let’s keep our object and will change its property values only. In this case, CoordsComponent input won’t change, it will be the same object. Modify ngOnInit:

ngOnInit() {
    window.addEventListener('click', (event: MouseEvent) => {
      this.coords.x = event.x;
      this.coords.y = event.y;
    });
}

Still works! The Default change detection strategy is smart enough to make deep comparison of previous object values and new one, even if we keep the same object. This is exciting. However, every amazing thing in this world has a price. The price of this functionality is the performance. If we have many components on one page with input manipulations all the time, our application can become slow. Certainly, in our coordinate application, we can’t reproduce it, but we need to study it too.

OnPush change detection

OnPush change detection checks input values only. Let’s experiment with it. Modify CoordsComponent:

import { 
    Component, OnInit, 
    Input, ChangeDetectionStrategy 
} from '@angular/core';
import { Coordinates } from '../data/coordinates'

@Component({
  selector: 'app-coords',
  templateUrl: './coords.component.html',
  styleUrls: ['./coords.component.css'],
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class CoordsComponent implements OnInit {
  @Input() coords: Coordinates;
  constructor() { }

  ngOnInit() {
  }
}

Now click somewhere on the screen, nothing is working, you still have zeroes. Let’s return our first behavior of AppComponent:

ngOnInit() {
    window.addEventListener('click', (event: MouseEvent) => {
      this.coords = { x: event.x,y: event.y };
    });
}

Click on the screen and it works! So, this is the main difference between Default and OnPush strategies.

OnChanges

Angular has very useful lifecycle hook called ngOnChanges. It’s a method of component class that fires every time change detection occurs. In this method, you can modify your component state or incoming data every time it changes. To start using it your component class must implement OnChanges interface:

import { 
    Component, OnInit, Input, 
    OnChanges, ChangeDetectionStrategy 
} from '@angular/core';
import { Coordinates } from '../data/coordinates'

@Component({
  selector: 'app-coords',
  templateUrl: './coords.component.html',
  styleUrls: ['./coords.component.css'],
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class CoordsComponent implements OnInit, OnChanges {
  @Input() coords: Coordinates;
  constructor() { }

  ngOnInit() {
  }

  ngOnChanges() {
    console.log('Changes detected');
  }
}

Angular way of doing things

Now, instead of doing things like Javascript ninjas, let’s do everything in Angular way. In AppComponent we will create property mouseCoords$ that will be observable from mouse click event:

mouseCoords$ = fromEvent(window, 'click').pipe(
    map((event: MouseEvent) => ({x: event.x, y: event.y} as Coordinates))
);

Now let’s remove old coords property and bind this one though async pipe to CoordsComponent input

template: `<app-coords [coords]="mouseCoords$ | async"></app-coords>`,

Now, click on the screen, and everything works with OnPush performant strategy.

Conclusion

Change detection is the cornerstone of Angular framework. Understanding of it is highly necessary of being Angular developer. Lots of times I had the situation when nothing works and I have no idea why.

I hope this plainly explanation will help you to understand better what’s going on under the hood and, may be one day, to give correct answer during job interview.

Photo by NeONBRAND on Unsplash

Mappers in RxJS

Arthur Groupp — Fri, 17 Jul 2020 12:24:42 +0000

RxJS became one of the main game changers in the world of modern front-end development. Becoming the foundation for multiple technologies and frameworks, it brings us to the necessity of deep knowledge and understanding how it works and how to use it.

In this article I’d like to discuss RxJS mappers. One of the most usual task when we work with data is transformation. Mapper operators become handy when we need to transform every value one by one.

Let’s start.

Initial setup

You will need to prepare any environment where you can write Typescript code and see the results. Feel free to do it in any of your favorite way, for example, I prefer to use Stackblitz for my experiments. Signup/in and create empty typescript project.

We need to create the first observable for future use. Let's create it with the help of interval function. First, import it:

import { interval } from "rxjs";

interval creates an observable that emits values incrementing by 1 every specified time interval.

For example:

const obs1$ = interval(500)
obs1$.subscribe(console.log);

Will print in the console 0, 1, 2, 3, 4, … every half a second.

If we want to do any modifications of emitted data before subscribing, we must use method pipe of observable object. It accepts operator functions as its arguments.

Why do we need, why not to do it in subscriber function? Using pipe makes our observables much more reusable and subscriptions cleaner.

Let’s limit our emitted values to 5. To achieve this we need the operator takeWhile:

const obs1$ = interval(500).pipe(takeWhile(x => x < 5));

The code is pretty self-explanatory, it creates observable that emit values until the value is less than 5. Due to autoincrement of the values emitted by interval we will get exactly 5 values.

Map

map is the basic transformation operator and we are going to start with it. It looks very familiar from the Array type and works the same. As argument it accepts the function that has the current value as it’s argument and must return another value.

Pretty simple:

obs1$.pipe(
  map(x => x * 2)
)
.subscribe(console.log);

The result will be 0, 2, 4, 6, 8. Exactly the same like

[0, 1, 2, 3, 4].map(x => x * 2).

The difference is that we have this behavior time plane. If you look into console, you will see that you are getting these values not all together, but one by one with interval of 0.5 seconds according to its emitting.

I want to pay your attention on fact that the projection function must return scalar.

What to do if we need to return another observable? For this case, we have switchMap.

Initial setup modification

Let’s apply our new knowledge and modify our obs1$:

const obs1$ = interval(500).pipe(
  takeWhile(x => x < 5),
  map(x => x + 1)
);

Now obs1$ will emit 1, 2, 3, 4, 5

Let’s add second observable

const obs2$ = interval(200).pipe(
  takeWhile(x => x < 5),
  map(x => x + 10)
);

obs2$ will emit 10, 11, 12, 13, 14

SwitchMap

switchMap takes every value of observable created pipe and returns the observable returned by its projection function. Let’s make it out on an example.

obs1$.pipe(
  switchMap(() => obs2$)
)
.subscribe(console.log);

The result will be 10, 11, 10, 11, 10, 11, 10, 11, 10, 11, 12, 13, 14

Why? This is very important part of understanding how switchMap works. So, what’s going on? Every time we have value from obs1$ our subscription subscribes to obs2$. obs1$ has interval 500 and obs2$ has interval 200. It means that we manage to get 2 values of obs2$ between values of obs1$. And when next value of obs1$ comes it unsubscribes us from obs2$ and subscribes again. That’s why we have 10, 11 five times and 12, 13, 14 only once when obs1$ becomes completed.

switchMap is very useful when we need to utilize the value of first observable in the second one. For example, we have Angular router that has parameter that we need to send to API to get correct response. This construction is perfect for this task. We can put pipe on paramMap or queryParamMap and “switch” to new observable that will be returned by HttpClient.

But what if we want to get all obs2$ values? For this case, we have mergeMap.

MergeMap

mergeMap does exactly the same functionality like switchMap except that it doesn’t unsubscribe when new value arrives. Let’s see it:

obs1$.pipe(
  mergeMap(() => obs2$)
)
.subscribe(console.log);

Now we have 10, 11, 12, 10, 13, 11, 14, 12, 10, 13, 11, 14, 12, 10, 13, 11, 14, 12, 10, 13, 11, 14, 12, 13, 14

Total 25 values, 5 times 5, all of them.

Good example of using mergeMap is NgRx effects. When we create effect, we mergeMap action with the related service method.

The values we get are disordered. We get them in order of emit and when new value from obs1$ come it starts new cycle of emitting values of obs2$. Thanks to this, we get part of values from previous cycle and part from new started. What if the values order matters for us? For this case, we have concatMap.

ConcatMap

concatMap works the same way like mergeMap except that fact that it emit the values in order. Example:

obs1$.pipe(
  concatMap(() => obs2$)
)
.subscribe(console.log);

The results will be 10, 11, 12, 13, 14, 10, 11, 12, 13, 14, 10, 11, 12, 13, 14, 10, 11, 12, 13, 14, 10, 11, 12, 13, 14

Exactly what we wanted.

Conclusion

Mappers are the most used operators in data manipulations. Very important to understand principles of its work to pick the correct one in your future tasks. When you plan the usage of mappers, first ask yourself “does my projection function return observable or scalar?” This can become the starting point to choose the correct operator to use.

Photo by National Cancer Institute on Unsplash

DEV Community: Arthur Groupp

Mastering Angular’s httpResource: Why Services Beat Components

Why httpResource Matters

The Temptation: Quick In-Component Usage

The Better Way: Abstract httpResource into Services

Example: Service-Based Resource

When Might In-Component Be Okay?

Conclusion: Future-Proof Your Angular Apps

Effective Debouncing in Angular: Keep Signals Pure

Introduction

Why Debouncing a Signals Directly Is an Antipattern

The Solution

Enough theory. Let’s code.

Conclusion

Signals vs. Observables: Can One Truly Replace the Other?

Understanding the Basics

Practical Implications

HTTP Requests: A Unique Stream Scenario

Conclusion

Extending components, directives and services in Angular 14

Inject function

Conclusion

Types in Typescript plainly

Compound types

Annotation

Inference

Functions

RxJS

Conclusion

Domain Driven Design Implementation Plainly

Law and order

Domain or not domain

The domain

Domain Logic

UI

Conclusion

Publishable libraries with Nx Monorepo - part 1

Naming

Workspace creation

Workspace adjustments

Code formatting

Initial commit

Repository

Starting to paint

Testing

Building

Conclusion

Angular Change Detection Plainly

Initial setup

Default change detection

OnPush change detection

OnChanges

Angular way of doing things

Conclusion

Mappers in RxJS

Initial setup

Map

Initial setup modification

SwitchMap

MergeMap

ConcatMap

Conclusion

Why `httpResource` Matters

The Better Way: Abstract `httpResource` into Services