Hey there, Angular fans! So, signals are a fairly new concept in Angular but I’m sure many of you out there are using them often. And if you’re anything like me, when using writable signals, you’ve probably found yourself wondering when to use the set() vs. the update() method. Well, in this tutorial, we’re diving into this question to help you understand why you may want to use one over the other.
The new linkedSignal primitive in Angular 19 is a pretty handy new feature. In a previous tutorial we looked at the basics, but in this tutorial, we’ll take it a little further and look at a more advanced feature where we will compare the new and old values of the source signal to provide “smart” signal updates. Ok, let’s get started.
Hey there Angular folks, and welcome back! In this tutorial, we’re tackling an exciting update in Angular: how to modernize your components by migrating from the traditional @ContentChild and @ContentChildren decorators, and QueryList, to the new signal-based contentChild and contentChildren functions.
Angular 19 is here and that means that it’s time to learn some new stuff. In this tutorial, we’re getting hands-on with Angular’s latest signal feature, the linkedSignal() function. It’s a powerful way to create signals that are both writable, and that automatically update based on changes in other signals without improperly using the effect() function. Let’s dive right in and see how this new function can streamline reactive updates in your Angular Apps!
If you’ve been working with Angular for very long, you’re probably pretty familiar with the @ViewChild and @ViewChildren decorators. Well, if you haven’t heard yet, the framework is moving away from these decorators in favor of the new viewChild and viewChildren signal query functions. This means that it’s time for us to make the switch! In this tutorial we’ll take an existing example of both decorators and convert them each to the new respective functions.
Effects in Angular are pretty new but have definitely stirred up some controversy in their short time as part of the framework. Basically as far as I understand it, the main goal with the effect function is to handle things related to signals, that you really have no way to do otherwise. And as the Angular docs point out, “effects are rarely needed in most application code”. But there are some totally valid use cases.
Hey there, Angular folks, and welcome back! If you're still using @Input decorators and ngOnChanges() for managing states, this tutorial is for you! We’ll take two simple forms that are enabled and disabled programmatically based on an @Input and refactor them to use Angular’s latest signal-based approach.
Signals are a pretty big deal in Angular now a days. I’ve created several videos on them recently because there’s a lot to consider when using them. As you use them more over time, you’ll probably run into scenarios where you need to execute code when signal values change. Now, one way to do this is to use computed signals which is something I’ve covered in the past, but there is a possibility that even this won’t work for your situation. We’ll if this is the case, there is another possibility. You can use the effect function.
Signals are now a core concept in the Angular framework. When you build components, directives, and services, you’re going to want use them going forward. And as you do, at some point you’ll likely ask yourself the question: how can I create a signal based on the values from another signal? Well, in this post, I’m going to show you how, and it won’t take very long either!
If you work in Angular and haven’t heard yet, many things are in the process of switching away from decorators over to signals. I’ve already shown you how component or directive inputs have changed over from the @Input decorator to signals with the input() function. In this post we’ll take a look at how we can convert the @ViewChild and @ContentChild decorators over to signals with the viewChild() and contentChild() functions. We’ll take an example application that I previously created for a demo about the @ViewChild and @ContentChild decorators, and we’ll switch them over to the new signal functions producing the same end result. Ok, let’s get to it!
Signals are changing the way we do many things in Angular. You’ve likely encountered Observables if you’ve worked in the framework for very long. They’re a pretty handy way to stream values emitted over time to subscribers providing a way to react to these events as needed. But often when using them, we also need to trigger Change Detection in order to properly update items within views. With Signals, Observables are not being replaced, they still have use cases, but we can actually transform them into signals when needed. This can help with Change Detection and can often simplify the code overall. In this post we’ll convert a couple of Observables from an existing example over to Signals. Alright, let’s check it out.
In newer versions of Angular, a pretty significant change is coming with Signals. If you work with Angular and haven’t heard about them yet, you’re in the right place. In this post you’ll learn what they are, at a high level, and you’ll learn how to use the new signal-based inputs along with the new output function in components. We’re going to take a look at an example using the existing @Input and @Output decorators and we’ll convert it over to signals and the output function. I’ve been using signals a lot lately and I can assure you, It’s a change. Definitely a different way of thinking. Alright, let’s get to it!