Angular is a development platform for creating applications using modern web standards. Angular includes a wealth of essential features such as mobile gestures, animations, filtering, routing, data binding, security, internationalization, and beautiful UI components. It's extremely modular, lightweight, and easy to learn.

angular

This course is perfect for those looking for a lightweight alternative to NgRx Store that scales effortlessly.

In this NgRx signal store lesson, you'll be defining the structure of the store's state, initializing it with default values, and creating the store instance.

Create an NGRX Signal Store with initial value using withState

We'll explore three ways to provide the NGRX Signal Store in this lesson:

1. Make the store available to the entire application via the root injector.
2. Provide the store within a route
3. Provide the store within a component

Provide the NGRX Signal Store within a Component, a Route, or globally

In this lesson, we learn how to retrieve and display data from an NgRx signal store in an Angular component template. 

You'll also see how typical component state properties like `isLoading` or `error` can be migrated into the signal store to centralize data management

Retrieve and display the NGRX Signal Store state inside an Angular Component

In this lesson, we learn how to quickly debug NgRx signal stores by accessing properties directly in a component's template and using the Angular json pipe for a readable output.

Run quick and dirty NGRX Signal Store debugging

Let's learn about deep signals in NgRx signal stores! 

In this lesson, we'll see how they optimize performance for nested objects by minimizing change notifications and streamlining updates in your Angular app.

Use NGRX DeepSignal instances efficiently in Angular applications

In this lesson, create computed properties for deriving state-based values in NgRx Signal Stores.

Computed properties allow you to encapsulate complex logic to maintain clean component architecture. 

Define NGRX Signal Store Computed Signals

In this lesson, you'll learn to update your NGRX Signal Store by defining updater methods in withMethods. 

In your custom methods, you can use the patchState method from NGRX to update your store without directly modifying it. 

Update NGRX Signal Store state using withMethods calls

In this lesson, you’ll learn how to manage nested state updates efficiently using patchState, and Immer’s produce function to ensure immutability.

The produce function in Immer takes the current state and a function that modifies a draft of that state. After the modifications, produce returns a new, immutable state object that incorporates the changes made to the draft. 

Check out the [ngrx-immer](https://github.com/timdeschryver/ngrx-immer) package!

Simplify NGRX Signal Store advanced patchState usecases with Immer immutable utility

In this lesson, you’ll learn to use patchState for executing multiple state updates.

The example in this video updates the same `filters` slice in both updates. But, where this feature really shines is when you need to make updates across several different slices of state!

Use NGRX Signal Store methods to run batch updates

One of the main advantages of using the NGRX signal store is centralizing your state and reducing the complexity of your components. 

In this example, you'll move all the logic related to filtering into its own child component. Then, you'll see how signals allow you to access and manage state across your component tree.

Share state and perform updates from within component subtree using NGRX Signal Store

Learn how to encapsulate private state and methods within NGRX Signal Store by using prefixing their keys with an underscore `_`. 

Note, that this only makes them private on a type level. They will still be available in the JavaScript runtime.

Make state, computed or method private in NGRX Signal Store

In this lesson, you’ll learn how to integrate external services with NGRX Signal Store with Angular’s inject API.

To make this work we'll be covering: 

- Angular's injection context, which is the scope within which Angular’s dependency injection (DI) mechanism is active and capable of providing dependencies.
- How we inject the service in a default value to ensure that the injection happens properly within the injection context.

Use an external Angular provider within withComputed or withMethod

In this lesson, you’ll learn to integrate external services with NgRx Signal Store using RxJS operators for reactive state management. 

You'll be making adding an additional call to withMethods in your signalStore to group methods related to an external HTTP service. Then, you'll bring in `rxMethod` from the `@ngrx/signals/rxjs-interop` package. 

Within `rxMethod` you can use RxJs methods. In this example we'll be using `pipe`, `switchMap`, and `tap`. 



Initialize the NGRX Signal Store state from using RxJS Observables and rxMethod

The `withMethods` call that we're using for our HTTP service logic is starting to get complex with logic that deals with both high and low level details. 

It'd make sense at this point to move some of the low-level logic into it's own `withMethods` call and make it available via private methods. 

Implement a simple State Machine using NGRX Signal Store

Use lifecycle hooks in the NGRX signal store to manage your store's state when it's initialized and destroyed. 

In this example, you'll see how we can use the `onInit` hook to load a list of employees when the store is initialized with its associated component.

Configure lifecycle hooks for an NGRX Signal Store using withHooks

NGRX Signal Store supports both async/await and Promise APIs. 

Using async/await, you'll learn how to handle calling a method from a service that uses fetch to retrieve external data.

Initialize the NGRX Signal Store state from external APIs using Promises or Async/Await

So far we've been debugging by displaying json in our template. 

But, if we want more fine-grained control, we'll want to bring in `withDevtools` from the package [@angular-architects/ngrx-toolkit](https://github.com/angular-architects/ngrx-toolkit) and include it in our store to get a Redux-style debugging experience. 

Configure Redux-style debugging for NGRX Signal Store

Learn everything you need to know to take advantage of signals and be prepared for signal-based components

Modernize State Management in Angular with Signals

Angular Dependency Injection (DI) Explained

Learn how the latest JavaScript features can help you improve your codebase.

Learn the Latest ECMAScript Features (ES2024, ES2023, ...)

Scalable Signals Angular Architecture with NGRX Signal Store

https://app.egghead.io/api/v1/lessons/angular-create-an-ngrx-signal-store-with-initial-value-using-withstate/subtitles

[00:00] Start by installing the dependencies. So we're going to run n g add and here at ngrx/signals since this is the name of the package. And optionally, we can specify the version we're interested in. In our case, the most recent one, latest. So we're going to wait until the corresponding
[00:19] modules get installed and the package. Json file gets updated. So after the install is complete, we should see that in dependencies, there is one new entry, which is add ngrx slash signals, in this case, in version 18. So all dependencies are installed already within one
[00:39] single package. So let's proceed to creating the store itself. I have opened the employee store TS file in employees directory or model, whatever. Since we are going to create an employees listing, which is going to load the data, display the object details, do some calculations, do some filtering,
[00:59] and so on and so forth. So we're going to use a function that is called signal store imported from NGRX signals. So the API that we're going to use here is going to use a composition where we're going to provide feature a, provide feature b. And, basically,
[01:19] whatever we provide at the very beginning is going to be wrapped, composed with whatever are the other steps. So the first and most important features which we're going to use is actually with state. So what is basically the data, the state of our store that we're going to use? Here, we could
[01:39] simply put an JavaScript object over here, but it's most probably a better idea to provide a type or a TypeScript interface that is going to define what our employee state is. So let's create type employee state, which is going to simply store some of the data and
[01:59] the filters themselves. So let's create the property items, which is going to store the employee objects array. And let's create some filters that we're going to use, like, later. And there would be a name filter, which is simply a string. So we're going to be filtering by first
[02:19] names and last names. And we're going to, filter the employee objects by their salary, which we cannot see over here yet, though every employee has their salary. And there might be a from salary, which is the lowest possible value of a
[02:38] salary, and the to salary, so the highest possible value. So we're going to create a typescript record over here. So for both the from and the to properties, and their value is going to be simply a number. Now we're going to create a object literal, which is going to,
[02:58] have the type of employee state. So let's call it initial state, and let's annotate this with the employee state type. And here, TypeScript will guide us through creating all the required properties. So initially, we don't have any items yet. They haven't been loaded. We're
[03:18] not providing any initial data right here. So the property that we're missing is obviously filters. So let's create, filters, which is going to include the name itself, and let's initially define the name, filter, which is going to be an empty string, and the salary, which is going to be
[03:38] a from. Let's say that, just for the sake of simplicity, the lowest possible salary value could be 0, and the highest possible value could be 10,000 in this dataset. So having defined what is the type and what is the literal which
[03:58] is bound, which is annotated to the type, what we're going to do simply is to put that this initial state is going to be used within the with state feature. And what we're going to do here is simply export const employees store and this equals to
[04:17] the store that we have created. If we hover over typescript types, we will see that NGRX is capable of figuring out what the under lying types are such as signals or deep signals, which we're going to, take a look at slightly later. So this is how we create an NGRX
[04:38] signal store.

https://app.egghead.io/api/v1/lessons/angular-create-an-ngrx-signal-store-with-initial-value-using-withstate/transcript

https://app.egghead.io/api/v1/lessons/angular-provide-the-ngrx-signal-store-within-a-component-a-route-or-globally/subtitles

[00:00] There are a few different ways to provide the NGRX signal store within our application. But before we configure the providers, let's first inject the signal store into the component that is going to directly make use of it. So for this reason, let's walk into app slash employees slash employee listing component. That's the component that we can
[00:20] see displayed on the right hand side. It has a very simple template and very simple code that is loading the external data via HTTP. What we want to do here is to create a simple property called store for simplicity and inject the signal store, which is a Angular service. So
[00:39] we're using the inject function imported from Angular core the same way as we inject all services. And what we want to provide here is the employee store. This is a class. This is a service, which we're going to see just in a while. After saving the file, we will see that Angular is going to explode
[00:59] since there are simply no providers yet for this injectable since we haven't configured any of them. So what we're going to do in the first attempt is to provide it globally in the root injector. So the same way as we are using the provided in option in the
[01:18] injectables, the same way or in a very similar way we can do it within the signal store declaration as the first parameter. So the first parameter is not going to be a function, but it's going to be a configuration object where what we provide is simply provided in, which is going to include the
[01:38] root option. So after saving the file, we will see that the application runs correctly. So the component does have the service injected, but what we also want to see is that when we walk into the employee listing component, as we can see right here, right now, we will see that there is a
[01:58] signal store and we also want to see where does it come from. So if we scroll over here, we can see that there is a employee listing component, which does include the service that is injected, the signal store. And where does it come from? It's basically the root injector.
[02:19] The other way which we can take a look at it is to head over to injector tree tab within the Angular dev tools. And here in the environment hierarchy, if we zoom it out a little bit and we click on the root injector, we will see that there is quite a bit of
[02:38] different injectables over here. And if we filter it by signal store, we'll see that, yeah, signal store is available right here. So this is providing the store globally within the root injector. Another way to provide the n g r x signal store is to provide it within a route.
[02:58] So we're going to remove it from the route injector, and we'll walk into the app routes file, the one that configures the routing entries, the ones that we have over here, employees. So depending on our needs, we might include the provider's option. Let's say that in our case, this is going to be
[03:18] the employee's path, which would make the providers available for all children roots. So here within the providers, we're just putting the employee store and we'll save it. And right now, Angular is back and working. So if we take a look at the employees listing, and again, we
[03:38] were taking a look at the signal store. Let's see where does the instance come from. Then we can see that the employee listing component, which is certainly available within the router outlet, the instance comes from the root employees injector. So let's take a look at the injector tree. And here, we'll
[03:58] see within the environment hierarchy that for the root injector under the root injector, there is a root employees injector, and the one includes the signal store right here on the right hand side. So this is the second option. Let's configure the last option, which is providing the store
[04:17] within a component. So first, let's remove the provider from the roots. And before I hit save and get the null injector error, let's know that employee listing is a child of employee page components. So what we're going to do is to keep employee listing injecting the service, but it is
[04:37] its parent which is going to provide it. So let's first remove it from the roots. And within the employees page component, let's just put the provider section where we're going to include the employee store. And after saving, we'll see that the application
[04:58] works correctly and when we move to the injector tree. And now let's take a look at the element hierarchy. We'll see that within the employee page component, there is a signal store that is directly being used by the employee listing.
[05:18] Be aware that whatever we create using the signal store function is a class that is a regular Angular injectable. So we can see that when we take a look at the sources and we would look for the signal store function definition where we can see that
[05:37] there is a class signal store that is an injectable and it is directly returned from the function within the NGRX signal store sources. In other words, NGRX signal store behaves just as regular services in Angular.

https://app.egghead.io/api/v1/lessons/angular-provide-the-ngrx-signal-store-within-a-component-a-route-or-globally/transcript

https://app.egghead.io/api/v1/lessons/angular-retrieve-and-display-the-ngrx-signal-store-state-inside-an-angular-component/subtitles

[00:00] In order to retrieve and display the data from n g r x signal store within a component, let's head over to components template. In the simplest possible scenario, what we can do is to access the injected store directly and read one of the existing properties of the store. In our case, we have already
[00:19] defined only the with state features. So we have 2 properties, the items and the filter. Let's take items. If we take a look, we'll see that each of these properties is a native Angular signal. This is what n g r x signal store creates under the hood. Now just as with any other Angular signals, if we want to grab their most
[00:39] recent value, we just need to call them as if they were functions. Now I'm not going to put it here, not yet, at least. And let's open the network dev tools tab just to show that whenever this component is initially displayed, there is an HTP request that is being made. This is being
[00:59] executed by RxJS observable stream. Here we've got the this employee's dollar, which is an HTP call to the external API. Never mind that We're going to remove this code anyway. And this stream is being subscribed here using the async pipe. So we're
[01:19] going to replace it entirely step by step with NGRX signal store. So if we uncomment this line and we'll basically cut away this piece over here and we'll simply put the function that reads the signal value, then we will see, first, that there is
[01:39] no request being made. And second, since our store property, the items property is empty, there is simply no data for the component to display. So for this reason, we're going to import a mock employees, which is an array that just includes some hard
[01:59] coded object. This is just for the sake of the while, so we're going to remove it slightly later. So initially, our store is going to include some 50 elements just to have anything to display over here. So let's walk back to our component. We can see that, yes, these objects are being
[02:19] displayed. We can also see that there is a loader popping up over here. This is caused by the fact that we have some of the properties defined here. There always come the question, how much data do we want to be located within the store? How much data do we want to be put inside a component locally? So in
[02:39] our case, we're going to move all these information, all this data into the store. So let's comment out the engine edit. Let's comment out all these HTTP related things, and there are also 2 properties that we're going to migrate into the store. So currently, we
[02:59] had only the items itself, but we didn't have the definition for the properties for the is loading and for a potential error. So we're going to have an is loading additional property within the employee store, state object. So is loading is going to be either true or false,
[03:18] and there is also going to be additional property, the error. Either there is an error or there is no. And subsequently, we need to include these 2 new properties within the is loading. So initially, yes, we are loading. And that initially, there is
[03:38] no error, for instance. Since right now we have all the mocks available, then we can just slightly change it to make it is loading false. Now, let's go back to our component. When we save the file, we will see that the is loading property is
[03:58] being highlighted because it it doesn't exist anymore, of course. So what we need to do is to do the very same thing. So we're going to access the store, and now we have 4 properties. The is loading and the error is available. So what we want to do is to call the is loading since
[04:18] this is a Angular signal, and we will see that, yes, at this point, this loading is being used for displaying the loader or not. And finally, if we go back here and toggle that is loading to true or false, then we can see that the corresponding value is
[04:38] being displayed accordingly.

https://app.egghead.io/api/v1/lessons/angular-retrieve-and-display-the-ngrx-signal-store-state-inside-an-angular-component/transcript

`console.log` is one of the handiest tools in the JavaScript developers toolkit. You can use it to inspect the data you are working with during different points in the data flow you're exploring. 

But...

If you're only using `console.log`, you are missing out on the full power of the console object. There are many properties that `console` comes with and we'll be doing a brief exploration of each: 

- **console.info**: Outputs an informational message to the console. In the browser, these messages are typically unstyled.
- **console.warn**: Outputs a warning message. In the browser, it's usually accompanied by an exclamation mark and a stack trace.
- **console.error**: Outputs an error message with a stack trace.
- **console.assert**: Takes a condition and outputs a message if the condition is false, useful for assertions in code.
- **console.clear**: Clears the console, useful when the console is overcrowded with logs.
- **console.count**: Logs the number of times that this particular call to count() has been called, useful for tracking how often a block of code is executed.
- **console.time** / **console.timelog** / **console.timeEnd**: Allows for basic performance monitoring by starting a timer, logging the elapsed time, and stopping the timer.
- **console.group** / **console.groupEnd**: Groups together a series of console messages, indenting them for better readability.
- **console.table**: Displays tabular data as a table, making it easier to read complex object structures.
- **console.dir**: Provides an interactive listing of the properties of a specified JavaScript object, useful for inspecting objects.
- **console.trace**: Outputs a stack trace to the console, which can help track down where a function was called.

Each of these methods can be used to streamline the process of debugging JavaScript code, whether you're working in a browser or in a Node.js environment. Using these methods appropriately can help you understand your code's behavior and find errors more quickly.

https://app.egghead.io/api/v1/lessons/angular-run-quick-and-dirty-ngrx-signal-store-debugging/subtitles

Explore the Console Object for Enhanced JavaScript Debugging

[00:00] With it, we can log strings, we can log objects, we can log arrays, and any other data type that we want to see. But if you've only ever used a log method of the console object, you've been missing out. Firstly, we have console.info, warn, and error.

[00:18] When working in Node, these don't make much difference. But when using the browser's tools, these are styled slightly differently. info will be unstyled, warn will have an exclamation mark and also comes with a call stack, as is error.

[00:33] We could also have our log filter out warnings or errors and have more control over what's going on. Sometimes you'll want to assert that something is true, and console.assert does just that. It takes a condition, so let's test name equals Kevin, and if it's false, we can pass in a message.

[00:51] So here I'm asserting that the name is set to Kevin, and I've got an error message, not the right name, only if the assertion fails. So as soon as I change this from Kevin to Kath, I'm going to get an assertion field and an assertion message.

[01:06] This can be super helpful when we're debugging, because we can test the values and only log when it doesn't match our expectations. When the console starts to get a little busy, we get console.clear, which allows us to clear the console. We've also got console.count. This can be super handy to check how often a function is called.

[01:26] So I've created a function called counting. If it equals zero, I'm going to return. Otherwise, I'll invoke my count and decrement by one. Now, you notice it gets from one to eleven, and that's because I've called console.count before. But if I pass in a string, I can have a separate counter.

[01:42] And so we can have multiple counters going on throughout our code, so we can be counting things without having to create variables, log those variables out, and use those in different ways. We also have the ability to time. So console.time and console.timelog, which will print the current time,

[02:00] or console.timeend, which will print the current time and then end the timer, can show us how long it takes to run a piece of code. So from when I invoked this timer to when I ended the timer, I see it's 0.6 milliseconds. We can use timing functions to help us find ways to optimize our code, to test it before we over-optimize.

[02:20] Next, we've got console.group. Console.group groups together a series of console.log messages. So we've got console.group, which is bracketed with console.groupend. And any log message inside of here, so name, Kevin, location, Northern Ireland, will be helpfully indented,

[02:38] and we can see them more easily in our console. So console.group is really helpful to be able to group together log messages that have a common purpose. If I have a user object, we know that we can console.log that. But there's another method that we can pass an object to, which is console.table,

[02:57] which creates a table from the key values, which allows us to be able to see the data more clearly. It also gives us the same object logged out, so we get both. Console.dir gives us an interactive list of the properties of a specified JavaScript object. So we can pass in any object that we're currently working with,

[03:17] and we can get logged out an interactive list of its properties that we can explore in our console. And last but not least, console.trace will give us a stack trace wherever we are in our code. So even without throwing an error, we can see a stack trace to see what's going on. So there we go. Don't just use console.log.

[03:36] Use info.warn and error to be able to format your messages differently. Assert to test that the values are what you expect them to be. Clear to clear the console if it's getting too much. Count to create one or more counters to know when code's being invoked.

[03:51] Time, time.log and time.end to be able to profile your code. Group and group.end to be able to group together similar console messages. Table to be able to see an object in a table mode. Dir to have an interactive list of properties. And trace to be able to get a stack trace at any point in your code.

https://app.egghead.io/api/v1/lessons/angular-run-quick-and-dirty-ngrx-signal-store-debugging/transcript

https://app.egghead.io/api/v1/lessons/angular-use-ngrx-deepsignal-instances-efficiently-in-angular-applications/subtitles

[00:00] When retrieving data from NGRX signal store, you will find out that some of the properties are represented by simple angular signals, whereas some others such as filters property in our case are represented by deep signals. What's a deep signal? Well, it's a technique to improve performance
[00:19] for nested objects. Where does the difference come from? So when trying to read the is loading property, NGRX knows that, well, this is just a simple property. So it's not going to wrap it into anything other. It's just going to be a signal. Same with error. Since this is basically
[00:40] a plain property, what it's going to do is to represent it as if it was just a signal, nothing specific here. However, filters is represented by an object or in some other cases as a TypeScript record. So what TypeScript is going to do and and your x is going to do is to wrap it with a deep
[00:59] signal. So with deep signals, we can do 2 things. Either we can go deeper and read this as if it was just a ordinary signal or yet another deep signal in case of salary property, or try to read the deep signal as a whole. So reading deep signal as a whole is simply invoked
[01:19] by calling the deep signal as if it was a function. So let's see how this would look like. So this is the filters. We can see that there is a name, salary, blah, blah, blah. Everything is displayed over here. And the other possibility that we can do right now is that we would go deeper into the
[01:39] filters. Now we can see that since filters, that filters deep signal is a function, we can see things like apply, bind, call color, etcetera, and all other properties that exist on all JavaScript functions. But there is also something that is called name and salary, and these are basically the properties that come from the filters objects. So
[01:59] they are also represented here. Now, since name is just a plain string, this is going to be simply a signal. So we can call it in just a regular manner, just with angular signals. So this is the one. And another possibility that we can do is to walk into the salary. And since salary
[02:18] is not just a property, it's a record. So this means it's an object, yet again, it's going to be a deep signal. So what we can do with this, again, the same as before. Either we read the deep signal as a whole, which we'll see over here, or we can walk down into the object just as we
[02:38] did before. So in this case, we've got the from and to properties, and we expect that the from and to properties would be available here. And since from is just a number property, this is going to be just a signal. When working with NGRX signal stores, signals, and deep signals, there is one important thing that
[02:58] you should be aware of. Let's take a look at this line and actually this line with the salary deep signal. So in order to walk into the from property, there are actually 2 possibilities. One possibility is that we walk into the signal itself, the plain old signal, and basically to read it directly. But
[03:18] another possibility is to do what we have the line above and that we would unwrap the salary deep signal. And since this returns this object, basically walk into the from property. Now they're all going to return the very same value. So there is no difference in whatever is being returned.
[03:38] However, there might be a difference in how often would the signal or a deep signal notify that there is a change. So what are the reasons for the from signal to notify its dependence that there was anything being changed? Well, it could be only a new
[03:58] value available under this simple number property. However, in case of a deep signal, the whole object or a nested object or a nested nested object, etcetera, is being unwrapped. So basically, for this object, for this signal to notify that something has changed,
[04:18] there is a whole record that should change. So all in all, whenever you're dealing with deep signals, it makes more sense to basically go as deep as possible and then to unwrap at the very last moment. Because if we do it this way, if we unwrap plain
[04:37] signals, there is less reasons for the signal to notify that there is a change and there are less reasons for effects and computers to re execute. Let's visualize it. So what we have in our store is the items is loading and the error properties, which are simple signals.
[04:57] Now filters, since this is an nested object, this is a deep signal. Within the deep signal, there is name, which is just a plain old property with a string value, which is just an ordinary signal. And the salary, which is yet another nested object, which is
[05:17] yet again a deep signal, which includes just 2 simple properties with primitive number values from and to. Note that even though an array is an object in JavaScript and TypeScript, NGRX signal store is not going to wrap the items property, which includes
[05:37] an array of objects with a deep signal. This will remain just an ordinary angular signal.

https://app.egghead.io/api/v1/lessons/angular-use-ngrx-deepsignal-instances-efficiently-in-angular-applications/transcript

https://app.egghead.io/api/v1/lessons/angular-define-ngrx-signal-store-computed-signals/subtitles

[00:00] Go back to the file which includes the definition of the signal store. And at the very end of the definition, add a call to the with computed, which is also imported from ngrx slash signals. Now the with computed will accept a callback function. The callback function will have the
[00:20] state, which is injected by ngrx signal store, and this includes everything that we have built so far. And since we have called only the with state one providing the 4 properties, then the only things that we can use is basically the 4, properties which are either signals or deep signals, the
[00:40] things that we have seen before. What we return from here is an object that will include a computed 1, computed 2, whatever we provide over here. Now the first computed which we are going to provide over here is simply going to be a count. So the count is going to
[00:59] be the length of the items array. Now this is just going to be a plain old Angular computed imported from Angular core. And the definition is simply going to use whatever we've got within the state. So what we're interested in our case
[01:20] is to consume the item signal so we can destructure the state object and basically fetch the things that are interesting to us. So what we're going to do here is return items, call the items since this is a signal, and this returns an array. And
[01:39] from this array, we can simply get the length. Now having this one created, we can go back to our component and display the computer that we've created. We can already use this one here with the count, employees dot length. So here we are referencing
[01:59] the variable, but we can replace it with the store dot and here comes the count. Now since this is a signal, a ridomi signal, nevertheless, a signal, we still need to just call this as if it was a function. And here we can see that the computed has
[02:19] also already been read. Let's create one more computed. And this is going to be the items which are going to be filters by the value of filters dot name. Now we have the collision of the name since items has been already used somewhere over here. So what we can do is to
[02:39] do a very simple refactor that items are going to be replaced with loaded items just to denote that this comes from the external API. As you can see, everything over here is type safe, so we can do refactors safely. And the items is going to be just another computed
[02:59] call. And here, we will just create the function that clears whatever is going to be the expression returned. And as you can see, the object returned from the with computed just returns a pack of whatever computed we need to define. We're going to start our calculations with defining
[03:19] what are the items that have been already loaded and depending on whether the name filter has been created or the salary filters has been, created or defined, we're just going to filter them out. So the first if statement is going to depend on what
[03:39] is the filters dot name value. So for this reason, we also need to destructured here within the with computed. Know that all the computers that we create here, they kind of share whatever is going to be used from the definition of the state. So right here, we just need to access the
[03:59] filters. And we're going to walk into the if statement only if the filters dot name is truthy. So in this case, we can also check whether the length is being positive. So it doesn't make a big difference. In this case, still, what is important is that instead of
[04:19] unwrapping the entire filters deep signal, what we're going to do is to unwrap the very little thing that we need. In this case, basically, the filters dot name signal. And if this is truthy, which means that the user have created the filter's name
[04:38] value, it's been defined, then we're just going to filter all the items that have been loaded. So that would be result dot filter. And now, for every employee that is available within the dataset, what we're going to do is the search name that we have created
[04:58] is the filters dot name, and let's dump it into the 2 lowercase. So as you can see, this is basically plain JavaScript or plain typescript. And the thing that we return from here is that either this is the first name that included or the last name that includes it. So e
[05:18] dot first name dot to lowercase includes whatever is the phrase that we are looking for, and this is the search one or, basically, the very same thing but using the last name. So here, we're just going to
[05:38] replace the first name with the last name. Let's save it and let's see what we've got here. So there is a slight error with the property ID that doesn't exist or never. This is caused because from the items computed, we don't return what we should return, which is the result itself, and now everything should be
[05:58] up and running. So the last thing that we need to do is actually to display the items over here, which has already been done. So let's see what would happen if we changed the value of the filters here, let's say, to make it, let's say, Bert. Let's see whether the
[06:18] items get filtered, and yes, they do. And the very last thing is making use of the filters dot salary, which is going to be yet another if statement here and there, which is if filters dot salary dot from,
[06:38] if there is a value like this, then what we're going to do is simply result, reassign result dot filter. And for every employee, we're interested in e dot salary being either greater or equal than filters dot
[06:57] salary dot from, so the lowest possible salary, and a very similar formula. I'll just copy it. If the 2 is defined, then what we're checking here is that the e dot salary is lower than or equal than
[07:17] salary dot 2. So what is important when it comes to the design is that the computed could include quite a bit of all this logic as we can see over here, but it really isn't important for the component itself because the component is just going to consume it.
[07:37] So there is quite a bit of encapsulation.

https://app.egghead.io/api/v1/lessons/angular-define-ngrx-signal-store-computed-signals/transcript

https://app.egghead.io/api/v1/lessons/angular-update-ngrx-signal-store-state-using-withmethods-calls/subtitles

[00:00] Go to the definition of the signal store and at the very end, add one more feature. This time it's called with methods. Again, import it from ngrx/signals. Now with methods is similar to with computed in a way that it accepts whatever is the content of the store that we have
[00:19] created in all the steps so far. So we have all the properties provided, thanks to with state, and we have the computed provided, thanks to the with computed. And similar to with computed, with methods is about to return an object that will include all potential methods
[00:39] that actually update something. In our case, we're going to update the filters. So we're going to update the name filter and the salary filter or filters. So what we'll do right now is to provide the name update filters name, which is going to
[00:58] be simply the string value. So here we can use a types of lookup just to look up what is the type, so employee state. Now let's walk into filters and grab the type of the name so that there is, one single source of the definition of the type. And what we want to do right now is
[01:18] not to directly modify the value of the store. No. We don't want to do this. We want to use the patch state, a separate function also imported from ngrx slash signals. Patch state accepts the definition of the store in the first parameter. And in the second parameter,
[01:38] it accepts a updater callback which creates a new state value on top of the previous state value. And we're going to patch only a slice of this object. So as you can see within the store parameter, this is a signal based structure. So we have the signal
[01:58] properties and we have deep signals. However, after going through the path state function and passing what the stories, the store again includes the signals. The state is basically a bare JavaScript plain object. So no signals, no deep signals, just the values. And what is important in this case, we are patching
[02:17] only a slice just as the name suggests. So if you want to modify, let's say, only the error, this would be the only property that we would define over here. If you want to modify the name property within the filters property, then we don't care about these properties. Loaded items is
[02:37] loading an error are not interesting for us. We will only apply what is the new value of the filters so that all the remaining ones will basically remain with whatever value they had. So we're going to define that the new value of filters is whatever we had with
[02:57] the filters so far, filters. And we're going to spread it. And after we have spread whatever the value is, now we just provide so that, okay, the new value is whatever we have passed, thanks to our parameter. So this is the new value, or we could
[03:17] also make it even shorter doing this way. So our update filters name, method is already available within our employee store. So let's proceed to the employees listing component, and we'll make use of this
[03:36] method. So let's quickly create an input value. So there would be an input type text, which is going to include also the placeholder that this is basically a name search or name filter. And what we want to put over here is
[03:57] that the current value that we're going to use is actually going to be taken directly from the store if we want. Of course, we can provide an encapsulated function. So this is going to be store dot filters dot name. So whenever the value of the stored filters dot name
[04:16] changes, then this will be reflected by the input. And whenever there is a change, so it depends whether we want to use the change event or, in this case, input so that we don't have to lose the focus so that the input element does trigger an event. So whenever there is a keystroke, the event would be passed in case of the
[04:36] input event. And here, we would provide a method on the component. Let's say we would call it update name, and let's pass the event, which is the native event. So we just need to provide what is the definition of this update name method. So update name method
[04:56] accepts an event, which is a native Dom event. And what we're doing right now is that we want to access the store, and this is the method that we have just created. So it accepts a name of type string, and we have an event. So one thing that we could do is basically that
[05:16] the new value is simply the event dot target. And we want to access the value parameter, but due to types of related things, we would need to, make it available so that we can, for instance, use the type assertion so that this is an
[05:36] input HTML input element. And finally, what we do right here is new value. So let's see how this works. We've got the name search. And as we type something, we can see that filtering works correctly.

https://app.egghead.io/api/v1/lessons/angular-update-ngrx-signal-store-state-using-withmethods-calls/transcript

https://app.egghead.io/api/v1/lessons/angular-simplify-ngrx-signal-store-advanced-patchstate-usecases-with-immer-immutable-utility/subtitles

[00:00] Let's also add a similar way to update the salary filters, so that would be updates salary from and updates salary to. I'm going to copy function later on when we've got one defined. So const new value is going to be since salary is a number we're going to
[00:20] parse the integer from whatever we get from the dom. So here we would simply get the value of the HTML input element. And we would define a function where we have this dot store. And let's say, the function, the method that we'll define in just a moment is going to be called
[00:40] update filters salary, just to make things simple. And we want to have one method that would update both the from and the to. So we would pass that. In this case, we are updating the from. So that would be basically from, and here comes the new value. And accordingly, we would have
[01:00] another method that would do the very same thing, and that would be update salary to. Okay. We've got the salary from and the salary 2. So we would also create accordingly the inputs. So let's quickly add input type equals. Here comes the number since we want to use
[01:20] the features of the HTML Impost. Let's say that we're going to increase by 1,000, and there would be a place holder, which is salary from and salary to. Now we're going to synchronize the values in a very similar manner. So the value is going to be accessed
[01:39] directly from the store. Of course, there could be a method on the component level that capsulate this, but we don't need it. So store dot filters dot salary. And since this is salary from, let's just put the from 1 and invoke it. And, of course, we also need to synchronize it the other way
[01:59] around. So here we would have the method that we have just created, which is the update salary from and update salary to. So in this case, this is update salary from, and let's just pass the event. And similar, we would have the salary too. So
[02:19] type number step 1,000 salary 2, store filters salary 2, and update salary 2. So this is the dump, the HTML part, and what we are missing is the definition of the method. So let's now walk back to the employee store definition. So
[02:39] again, as with computed can include multiple computed, the same with methods can also include lots of different methods created. So in our case, the value that we want to pass here is going to support both the from and the to. So what we're going to use here is the
[02:58] employee state, the filters lookup, and we want to walk into the salary part. But what is important? In one case, we want to update only the from. In other case, we want to update only the to. Maybe there would be a need to update both so we can make it a partial so we can effectively use TypeScript features.
[03:19] And we're going to patch the state again similar as above. Patch state accepts the store parameter, and the second parameter going to be the function that is going to update the state into a new value. And again, since we are updating the filters, we
[03:38] don't need to worry about these, the other attributes since they are just going to be copied. Only what we pass here is going to replace the whole slice. So what we're going to pass here is that. This is a new object that will include the filters. The filter over here would include
[03:58] whatever was the state of the filters. And now we need to provide that, yes, there is also the salary because if we update, let's say, only the from and there was a to define, we cannot destroy it. So for this reason, unfortunately, we also need to go one level
[04:18] deeper, and that would be destructuring the state dot filters dot salary. And finally, the value that we pass here, which is either the from number, the to number, or both. So that would be dot dot dot value. As
[04:38] you can see, this doesn't look very good. Well, it works. But it's not really something that would be very convenient to work with. So in such use cases where we need to support multiple nested levels of immutability, it could make sense to reach out to a specialized library, in our case, Ymer, which is going
[04:57] to significantly simplify the way that we need to walk into the nested objects and nested arrays. So what Ymer provides is, first foremost, one method that has different flavors and different APIs, the method is called produce. So we are going to write mutating
[05:17] code, and Ymer is going to guarantee that the original object doesn't get mutated. So this is the code that we've had to write manually using the patch state, and here comes the alternative that comes from AMER. We invoke the produce function and
[05:37] pass whatever the current state is. Now we know what the state is because the patch state will basically inject it to us. And we're going to mutate, not the state, but the draft. The second parameter to produce is a callback function. So we can modify the draft, we can mutate it,
[05:57] and the overall result of the produce function is going to be the state which should be immutable, and it will remain immutable. And everything that we have changed on the draft is going to be remembered and applied back into the state object in an immutable fashion. So what do we want to mutate
[06:17] in this case? Well, in this case, this is just going to be draft dot filters dot salary. And bear in mind that if we know what is the shape of the state objects, then Immer and its typescript types knows that the draft is going to be a writable draft of
[06:37] the very same structure. So the draft is a writable structure of the whole state, filters is a writable draft of a piece of the object salary is yet again, a writable draft of a smaller nested piece and so on and so forth. So in a not really correct way, we could basically replace
[06:57] whatever was the salary with the value. But this case, TypeScript yells at us that this could include the from or the to or both or even none of them, and salary has the required pieces. So, basically, undefined is not assignable to number. So to make it correct, we could use, for instance, object assign
[07:17] that whatever was present on the drafts dot filter dot salary, please overwrite it with whatever we have within the value. So if there were 2 properties, then they could get overwritten. What is important in this case is that this piece is
[07:36] mutable. This line is mutable. And the mutated draft is going to be used to create a new state object in an immutable manner, something that PUT state requires. As we can see, everything works correctly and remember to check out the ngrximmer package.

https://app.egghead.io/api/v1/lessons/angular-simplify-ngrx-signal-store-advanced-patchstate-usecases-with-immer-immutable-utility/transcript

https://app.egghead.io/api/v1/lessons/angular-use-ngrx-signal-store-methods-to-run-batch-updates/subtitles

[00:00] The ngrx patch state function allows us not only to run a single update, but to run multiple updates within a single call. Let's create a clear filters method that we're going to implement in just a while. And let's walk to the employee listing component, and we'll create
[00:20] a very simple button, which is going to invoke the method whenever clicked. So let's run the store dot clear filters and here clear filters. So whenever we click the button, the values of the name and salary to salary from should be clear. So let's run the patch state function.
[00:40] We run path state and we pause this tour, this tour that all the methods rely on the same one, and we'll be having to callback functions. So the first one is going to over here update the, clear the name filter
[01:00] and the same one is going to do a similar job, but clear the salary filter. So the first callback is going to update only the filters slice where we pass that this one is currently.state.filters. So whatever we have
[01:20] here and basically that the new name should be empty because we are clearing it simply. And here, it's gonna start very similar way. So filters, which is the destructured state dot filters. So whatever other filters were, and finally, salary. And the
[01:39] initial values that we've got is the from, which is 0 and to, which we just decided that is going to be 10,000. So all in all, this is how we can run batch updates using the patch state function. Let's just make sure that everything works here correctly. So let's just put some
[01:59] interesting numbers over here and when we click the button everything is cleared. In our case, both of the updates relate to the same slice, so they could be, of course, simplified into just one call. When batch updates really shine is when we want to run one update when we touch different slices.

https://app.egghead.io/api/v1/lessons/angular-use-ngrx-signal-store-methods-to-run-batch-updates/transcript

https://app.egghead.io/api/v1/lessons/angular-share-state-and-perform-updates-from-within-component-subtree-using-ngrx-signal-store/subtitles

[00:00] From architecture perspective, NGRX signal store is very useful for moving away the state and state related logic into a specialized service and, basically, slimming down the component size and complexity. But where it also really shines is the ability to share and reuse the state and
[00:19] the logic across a whole group of components. So for this reason, we're going to create a new component, which is called the employee slash employees filters, and we're going to move away everything that relates to the filters into the new component.
[00:39] So let's open the file here to the side, and let's move away all the methods that relate to updating and clearing the filters. So cut and paste. Now since the store is not known yet, we
[00:59] will also need to inject the store the same way. And, of course, let's add the missing imports. And what is important? Both the parent and the child component, they all relate to the same instance that has been provided within the
[01:19] employees page component at the very beginning of the course. So the TypeScript file is already done, and let's also update the HTML part. So let's walk into the template, and here we need to move away these pieces. So the labels, including
[01:39] the input and the button. So let's move it over here. And as we can see, we do have the access to the store because it has been correctly injected. And the last thing that we need is to use the app employees filters, the new component, and the parent component. And since we are working with
[01:58] stand alone components, first, we need to import this one so that employee filters component is being available over here. And in the place where we have removed the filters, let's just put them over here. So after doing this update, we can
[02:18] see that everything works as it used to before. And let's just make sure that when we walk into the Angular components, we can see that the app employees filter component is here within the component structure.

https://app.egghead.io/api/v1/lessons/angular-share-state-and-perform-updates-from-within-component-subtree-using-ngrx-signal-store/transcript

https://app.egghead.io/api/v1/lessons/angular-make-state-computed-or-method-private-in-ngrx-signal-store/subtitles

[00:00] We can make a piece of state, a computed or a method private within ngrx signal store if we prefix a name of a property with a single underscore character. This is a convention that tells ngrx that this thing can be used only within the code of the signal store and not outside of it, especially
[00:20] not on the component level. So let's see an example. Right now, the employee listing component is using the stored items. It's a computed that takes into account all the loaded items loaded from the external API or loaded from the hard codes, never mind, and takes the
[00:40] filters into account. So let's move it into using the loaded items so that as for now, all the filters are going to be ignored. And what we're going to do is to make the loaded items private. So let's update the initial state, but let's also update the corresponding type or interface or
[01:00] whatever you might have and all the places that we're actually using it. So since here we are destructuring the state into using the loaded items, we have to also update it here. And it seems that there is no place where we would use the loaded items within methods. So here we will see that the property loaded
[01:19] items does not exist on this type. Yes. That's true because the property has been renamed, but we will see that if we add the underscore, it still does not exist on the type because it has been removed on TypeScript level. So what is important to realize is that it is not being removed in JavaScript
[01:39] since the property does still exist in runtime and it is available inside the store. So the way it's being processed is using the TypeScript utility type, the omit private, where iterating over all possible keys of whatever the store
[01:59] includes, all the properties are going to be remapped over here so that if the key name starts with the underscore, it is being filtered out using the conditional type. And if it doesn't start with the underscore, it's basically being passed through, and the corresponding value to whatever
[02:19] the key is is just going to be copied from the original type. So as we can see, this is purely TypeScript, so the corresponding property will exist in run time. And we will see that the omit private is being actively used in lots and lots of declarations and places
[02:39] within the signal store function. So let's get back to our code. So we don't want to use the loaded items, so let's back to using the items itself. Let's make one more thing private. As said, each property of the state could be made private. Each element of the width computed could be
[02:59] made private, or each method could be made private. So in this case, let's make the update filters name method private. Let's save it, and let's walk to the employee filters component, which we've created since this one is using this method. So, certainly, this method doesn't exist. So let's
[03:19] update the name to include the underscore. And since TypeScript cannot see the property on the store, since we are outside of the store's definition, let's cheat on TypeScript so that we would put the s any, so that just the compiler will compile the code base anyway, and we will put the debugger statement over here so that we can inspect the
[03:39] code within the browser. So let's just refresh the page and let's put something into the filter so that the update name function gets invoked. And what we can see over here is that the this dot store update filters name, and the loaded items,
[03:59] they all exist over here. So the private elements within the n g r x signal store are being removed only within the compile time.

https://app.egghead.io/api/v1/lessons/angular-make-state-computed-or-method-private-in-ngrx-signal-store/transcript

https://app.egghead.io/api/v1/lessons/angular-use-an-external-angular-provider-within-withcomputed-or-withmethod/subtitles

[00:00] Sooner or later, we will need to integrate our NGRX signal store with some other services that are external to our store. I have created an empty logger service, which has no methods yet. So let's create a log message, example method, which accepts one argument, which is basically anything. And we're simply
[00:20] going to console log whatever the argument was just to have an example method that we would need to invoke whenever some code from the NGRX signal store is being executed. Now we don't want any consumers, for instance, components, to do the gluing between
[00:40] the store and the service itself. We would like the store to be able to invoke the service directly. So what we can do is within the with computed and the with method methods. So what we can do is to extend the callback that is being passed to the with method and
[00:59] add one more parameter to this callback. And in our case, this is going to be our logger. So let's say that this is basically the logger and using the new Angular inject API, we can simply import it from the Angular slash core and ask for the
[01:19] instance of the logger service. Now our logger service is provided in the root injector, so we don't have to worry about the providers in this case. And this is all that we need. So let's take a look at one of the methods that is going to simply make use of this
[01:38] injected service. So within the clear filters method that we have implemented previously, let's just call the logger dot log message and here clear. Start it, and let's print a similar message at the very end of the function. And that would be clear. Finished. Let's also
[01:58] see this in practice. Let's see that it works. So here we've got the console up and running. And if we write something over here and we clear, we can clearly see that both messages has been displayed. Now there is one important thing to note about the usage of the inject function. The inject function has to be called
[02:18] within what is called an Angular injection context. Injection context is we can think of it of a point in time in which Angular is capable of injecting all the providers that are available within the dependency injection mechanism. It means that if you are outside of the injection context, it's
[02:38] basically too late to inject anything. And an example of a situation that is within the injection context is a constructor or a field initializer. And an example of a situation where we are outside of the injection context is inside a method. So whatever we would put here, this is going to
[02:57] fail since this call is outside of the injection context. But, nevertheless, what is important is that this inject is going to be called within the injection context depending on when are we going to inject the store itself. So if this
[03:17] is a field initializer, this is within the injection context. So this one, And again, this is not the with method itself, it's the callback that is passed into the with method. So the callback is also going to be executed at the same time when the store itself is injected. So we
[03:37] are guaranteed that this is indeed within the injection context. Now why is that important? It's because this piece of code is pure Angular code, and NGRX itself has no support for this piece, what so ever. So NGRX is not responsible anyhow for injecting anything. So how
[03:57] this works is because we are using or NGRX design is using a slight TypeScript trick, and that is if we provide a function that can support only 1 parameter and we, of course, pass 1 parameter, this is absolutely fine. However, if we pass a callback that is expecting more than
[04:17] 1 parameter, but only 1 is supported, then TypeScript is going to yell at us saying that there is basically no signature that would match our call. However, things change if we provide a default parameter, which basically makes this parameter as a non required one.
[04:37] Because it's okay to call this function with only one parameter. So if we basically call this whatever we want and provide the initial value, the default value of whatever it is. And in this case, this turns out to be a call to the dependency injection mechanism, which in turn
[04:56] needs to be executed within the injection context. Everything works automatically, even though NGRX could have no support for this whatsoever, as mentioned before. And using the fact that we are combining the syntax and the type compatibility of TypeScript functions, we can apply the very same mechanism
[05:16] also to the with computed, in this case. So here again, within the computed, we could also use the injected services. Now most often, you would need to use the injected services in order to run some side effects within your methods. You should not run your side effects
[05:36] within the computed signals since computers are meant to be pure functions, pure calculations, and should not include side effects.

https://app.egghead.io/api/v1/lessons/angular-use-an-external-angular-provider-within-withcomputed-or-withmethod/transcript

https://app.egghead.io/api/v1/lessons/angular-initialize-the-ngrx-signal-store-state-from-using-rxjs-observables-and-rxmethod/subtitles

[00:00] One of the most common tasks while working with NGRX signal store is integrating it with other services that can perform HTTP requests. In our case, we could create a new run HTTP request method here within the with methods call, and this would work absolutely okay. However, there is a
[00:19] possibility which we're going to use to provide another call to the with methods or with computed, etcetera, that is going to allow us to group together features that are related to each other. So in other words, we can provide another with methods just to provide HTP
[00:40] specialized methods. So it's going to work exactly the same, and the result is going to basically merge, as we could see, feature with a, with b, with c, and so on and so forth. So our store is composing the state and computers and methods and some more method, etcetera, etcetera. So, absolutely, we're going
[00:59] to need the store itself, and we are also going to need the service that is capable of running HTTP requests. In our case, it's the employees HTTP service that I have created before and which implements the get employees method, which is simply going to shoot an HTTP get
[01:19] request. So our new method is going to be called load employees, and this will allow us to remove the hard coded data that we've been using so far. So load employees is a method that is going to have no parameters so far and is going to do something. We'll take a look at this
[01:39] later. And absolutely, we're going to need the instance of this employee's HTTP service. So here we're going to run employees HTTP, which is going to inject, again, the same Angular core, inject. And now let's just import
[01:58] the employees HTTP service class. And here we've got the same as we had the logger before. So we have the setup up and running. What should the load employees do? We are not going to implement this method manually. And instead, we're going to use what is called the
[02:18] rx method, which is imported from ngrx/signals/rxjsinterop. Now rx method is a utility that is going to create a, what is called, reactive method, and it's important for us because of two reasons. 1st is that we have access to all
[02:38] things RxJS. So we will create a pipeline that is going to use all the operators and all the feature that we know from RxJS. And second thing is we can call the created method in 2 different ways. 1st, imperatively, where we can just pass a value whenever we
[02:58] want with whatever value we want. But we can also make the pipeline re execute in a reactive way. And that is by passing not a value, but a value wrapped in a signal, basically a signal or a reactive stream. So that whenever the value within the signal changes,
[03:18] the pipeline is going to be re executed. And analogically, if there is a new value available within the stream, so a new next notification is passed into RxJS stream, the pipeline is again going to be re executed. So this is a really powerful method. Now we mentioned that our load
[03:38] employees is going to be a method that accepts no parameters, so we need to specify what is the type of the value. So in our case, this is going to be void since we pass no parameters into the method. Of course, if we included some parameters in order to reload the real
[03:57] data, there would be some filtering criteria, some parameters to HTTP call. Now the content of the method, and this is absolutely beautiful, this is the native RX JS pipe, which includes all the operators and all the goodness that we know from RX JS. So
[04:17] within the pipeline, we're going to put the switch map just in case if someone wants to click on reload, reload, reload, and we want the old request to be canceled. So we're just going to pause the switch map. Our switch map accepts no parameter. And what we're going to do is, of course, we're
[04:37] going to use the employee's HTTP, and we're going to get all employees just like this. Now that we have implemented the switch map operator, we should take into account the fact that our state includes the loaded items property, the is loading indicator of loading or
[04:57] not, or that an error has happened or not. So, accordingly, to whatever is going on within our stream, we should update our properties accordingly. So let's now move to our reactive stream back again. And what we're going to use just to keep things simple is the tap
[05:17] operator again imported just from our ex JS. And what we need to do over here is to basically take care of the loading state. And here, when we are done with a switch map, whether we succeeded, that would be basically loading the items or an error if there
[05:37] was any error that was thrown. So in the original tap, just as we do with the original tap, now we're not interested in whatever the value was, especially that there is no value. So the callback to tap is basically a parameter less function. What we're going to do here is basically to update the state, which we're
[05:56] doing using the patch state function imported from n g r x signals. And what we're going to pass here is the store itself, and the function that is going to update our state now, we could use the state, although we don't need it in this very case. So we are just patching all the
[06:16] properties that we want to change. So in our case, the is loading is certainly true. And if we are loading, there should be no error at all whatsoever. And if we are loading, then there should be, most probably, no items at this point. Of course, depending on the logic, it could look
[06:36] slightly different. So this is the loading scenario. Now let's move to the scenario in which we handle either the success or the failure buffer is the missing comma. And we're going to use the overload of the tap operator, which allows us to use exact types of notification that we're interested in. And
[06:56] in our case, this is going to be the next for what is going on when we load the items and the error whenever there is an error going on. So, again, when we get the next notification, we shall run the path state. And, again, store, and we can
[07:16] avoid passing the function. So we can immediately define the object literal, which includes only the properties that we want to overwrite. And in our case, this is going to be that the loaded items is what we just received from the server. Now since we
[07:36] got the response, we don't have any is loading indicator, so this one is false. And, also, we have no error since well, basically, there is no error at this point. And one more thing, another patch state. So patch state, store, and what we get
[07:56] here is that is loading is false since the error is happening. So also the error is here. And also, that the loaded items is basically an empty array or whatever representation we could think of. And let's update the initial state. So
[08:16] the initial state is not going to use any mock employees. We're just going to put the empty array or again whatever would be the representation of no data loaded yet. So now let's just call the method. Let's open the employees listing component. And what we
[08:36] want to do simply is to put the button, which is going to run the load employees method. So let's just call it load or actually reload button. And whenever we click this button, what we're going to do is to run the store dot load employees, which
[08:55] is a reactive method that accepts no parameters. So let's see this in action and let's remove the unnecessary parentheses. And, yep, when we click reload, we can see that there was a loading notification and that the data is over here. Let's also take a look at the network tab. So whenever we
[09:15] run the reload function, we can see that there is a new request. And, also, if we carry on clicking the reload, reload, reload, reload, we can see that the previous request is being canceled in favor of another request that proceeds because this is how switch map works.

https://app.egghead.io/api/v1/lessons/angular-initialize-the-ngrx-signal-store-state-from-using-rxjs-observables-and-rxmethod/transcript

https://app.egghead.io/api/v1/lessons/angular-implement-a-simple-state-machine-using-ngrx-signal-store/subtitles

[00:00] In case our implementation gets dirty, we can break it up into more pieces like with methods or with computed. In our case, the load employees method is mixing the responsibilities as it is responsible for the reactivity along with the RX method, the RX JS pipe, and all the
[00:19] operators available here. And it also deals with updating the local state of the store, not to mention that it knows all the details about all the properties available on the store. So in order not to make a rather simple pipeline look really complex
[00:39] and have the high level overview and low level details at the same time, we can try to extract some low level pieces into a separate with state, with method, with computed call, and keep the things that are high level separate from everything that is low level.
[00:59] So for this reason, let's introduce one more with method call just for the sake of readability and easier maintenance in the future. And what we're going to put here is, of course, the score. And we're just going to encapsulate the state updates.
[01:20] So this is actually setting our store into the loading state. So let's just call it set loading. So we need no parameters over here. So we know what to do. Right? So we know that loading is true, error is null, and there are no
[01:39] items. And we want to make this method private since only the internals of the store can walk into the loading state, but no components or services from the outside should be doing it since this is basically the internal implementation details. So this is a perfect
[02:00] place where the underscore convention, the private elements of the store match. So what we can do here is simply store dot set loading. And that's it. So we don't even need any comment over here because the code is self documenting. Now the 2
[02:19] other method that we can introduce is basically the set error. And of course, here we are going to put whatever the error is here. Note that I'm not going to put the null over here since this basically means that we are walking into the loading state or walking into the error state. So we cannot walk into the
[02:39] error state if the error was null. So only this one makes sense. The same as we've got over here. So we don't put the error to be null, like the error needs to be here anyway. So let's just cut it away from here, and let's just do the patch state.
[02:59] And let's also do the very same thing when we can set items or whatever we call it. Now the loaded items that we've got over here are going to be of type employee array, the same type that we've been using so far. And the set items
[03:19] is going to use what we had here in the next tap use, and this is going to be the loaded items. And since we have the underscore set error and underscore set items, our implementation is going to simplify. The app store is
[03:39] going to run the set items or the items themselves and store dot set error with whatever is the error. So this way, we can further simplify and encapsulate the internal items, internal functionalities,
[03:59] and elements of the store, which is absolutely recommended, especially with big and complex stores.

https://app.egghead.io/api/v1/lessons/angular-implement-a-simple-state-machine-using-ngrx-signal-store/transcript

https://app.egghead.io/api/v1/lessons/angular-configure-lifecycle-hooks-for-an-ngrx-signal-store-using-withhooks/subtitles

[00:00] Sometimes we want to enhance our ngrx signal store with defining its own life cycle hooks, similar as components do. So in our case, the employee listing components is quite weird since there is no data loading initially, as we can see. And the user is supposed to first click
[00:20] the reload button for any data loading to proceed at all, which is not a very good behavior for the user. So for this reason, sometimes you will need to import the with hooks yet again from n g r x signal store, which is yet another feature of the n g r x signal
[00:39] store. This one will allow us to provide the 2 hooks, either the on init or the ondestroy. Both have the access to the store. So let's define both. First, the on init and then the on destroy. So first, let's see how do they behave. So
[00:59] first, we will have the in it within the on in it and they destroy. So when they are initialized or when they destroy, this relies on when the injector will be asked to actually create an instance of the store. So let's walk back into
[01:19] the home tab, and let's open the console. Let's reload the application. So when we are inside the home, so the routing for the employees haven't been triggered, the employee page or employee listing component haven't been executed. So there was essentially no need for
[01:39] this employee store instance to be created, especially that this instance haven't been provided in root. So only when we walk into the employees. Now the route has been activated. But again, if we take a look at the app routes, the provider is not on the routing level. In our
[01:58] case, the provider is on the employee page component level. So this component gets displayed. It will include the child employee listing. And for this reason, we can see the init being displayed in the console. Now we can figure
[02:18] out when the destroy is being executed. So since the employee store is provided within this component, it's a matter of this component being destroyed so that we can see that the store is going to be destroyed along with the injector of this component. So let's basically walk out and we can see that,
[02:38] yes, destroy is being displayed. So bear in mind what is the area of availability of your store, where you provide it, and where you inject it. Now what we want to do, essentially, is that our store needs to load the employees initially
[02:58] because this is the expected behavior. So let's open the network tab and let's walk into the employees. We can see that initially the data loading is there, but also when we click the reloads, then subsequent reloads also work correctly.

https://app.egghead.io/api/v1/lessons/angular-configure-lifecycle-hooks-for-an-ngrx-signal-store-using-withhooks/transcript

https://app.egghead.io/api/v1/lessons/angular-initialize-the-ngrx-signal-store-state-from-external-apis-using-promises-or-async-await/subtitles

[00:00] N g r x signal store supports not only the RxJS interop, which includes the RX method and everything RxJS related, but also it supports the async await API, which allows us to use, well, async functions and promise based functions. So let's implement
[00:20] the load employees alternative, which is going to rely on the async await. And for this reason, this is going to be an async function, which is going to include no parameters. And what we're going to do here is, first, we could write bare
[00:40] async code here within this employee store async method, but we can keep things clean and implement the method within the service and then inject the service. So we're going to implement the alternative to get employees. So since we're going to use the fetch API, let's
[01:00] just call this function fetch employees. And since we are basing on the async await API, let's make this function async as well. And let's copy a little bit of parameters. So here we have criteria in case we wanted to do some filtering, sorting, etcetera. So this is employee criteria. And
[01:19] let's start coding. So const response equals. And here we go with the fetch, which is going to use what is the URL over here, API URL slash employees. So this is what we need. And now fetch is returning the promise of a response, so we want to await it
[01:40] right here. And at the very end, what we want to return is simply the response dot JSON. And TypeScript has no means to figure out what is the type being returned from here, from this call, the same way as with the HTTP client dot get
[02:00] dot post or dot any other HTTP methods. We need to specify what is the expected response type. So here we have the generic to specify that, but this is in no way anyhow more type safe than what we're going to do here, which is simply a promise of the employees array. Now our
[02:20] get employees is using the private get page method which is using the underlying create HTTP params which supports which page of the data are we downloading from the server, whether is the 1st page of the results, the 2nd page, etcetera, and what is simply the page size. So whether it's
[02:40] going to be 50 elements per page, 20 elements per page, etcetera. So here, we would like to redo the very same thing in async await approach. So we're going to define what the query string is going to be. So here we would basically define that there would be a
[03:00] query over here. And let's start defining a query. And the best way to define a query in modern JavaScript is to use the new URL search params. And the search params is going to be, of course, all the criteria that we have. The same criteria
[03:20] which we have over here, employee criteria. Right now, we have some nationalities of the employees or office, whatever that is. And we will also support the parameters of this specific API. So this very specific API is using the underscore limit, which is going to be
[03:40] the page size of our parameters. So let's also add the page size parameter page size, which is going to default to 50. And let's also pass the page is which is going to default to 1. So let's put the page size, and let's just make it to
[04:00] string just to make things clean. And also page which is going to be the page dot to string. And what we need to do, like query, is an object right now. So let's just dump it into a string because that's the whole point of this constructor being used so that we
[04:20] have a string over here. So our method is done. This fetch employees. So let's go back to our employee store. Now with this with method section, we are having all the HTTP, and we have already injected the employees HTTP service. So
[04:40] what we want to do is to run the employees HTTP, which is going to fetch employees. Now remember that we are inside the async await API. So what we want to do is to await this call. And when we do await the call,
[04:59] what we get in response is basically the items itself. So when we get the items, what we can do is to run the store dot set items with, of course, the items. But the problem is that there could be things that are going wrong. So for
[05:19] this reason, what we need to do is to check whether there was an error or whether there was no error so far. So what we need to do is to wrap this call with a try catch. So let's also add the try catch and put the error
[05:39] statement over here. And before we walk into the try catch, the same as we did with load and place, there was also a set loading. So we need to walk into the loading state of our state machine, of our simple state machine. So store dot set
[05:59] loading. Now we are inside the try. So if things go well, we would have a success state, the set items call. And now if things go wrong, what we want to do is to do the store dot set error and try to set what the error is.
[06:19] Now we do get an error since things are incompatible. And if we go down very, very, very deep, we will get the error saying that argument of type unknown is not assignable to type error. So what the error is expecting is that this would be actually an error, but what the
[06:39] catch clause is returning is unknown. So for this reason, if there was any case in which this thing would not be an error, like it's not really probable, but technically TypeScript requires us to take care about that is to basically make a small if statement. If this was
[06:59] not an error, basically, wrap it with an error. So let's create let error equals and here we go. This is our condition. So is error an instance of error? If it is, then please just pass through
[07:18] whatever was the error. And now if it was not, then what we can do is basically wrap it into a new instance of the error object saying that, hey, some unknown error occurred. And using the new specification of JavaScript, ECMAScript, we can say that the
[07:38] cause of the original thing was actually whatever was passed over here. And here, we're absolutely sure that either this has already been an error, and if for any reason not, we can just wrap it with an error. And this is what we've got right here. So the only thing that we
[07:58] need to do is to walk into that with hooks, and let's replace the load employees with the load employees async await. And let's see that everything is up and running. NGRX signal store supports async await and promise based APIs.

https://app.egghead.io/api/v1/lessons/angular-initialize-the-ngrx-signal-store-state-from-external-apis-using-promises-or-async-await/transcript

https://app.egghead.io/api/v1/lessons/angular-configure-redux-style-debugging-for-ngrx-signal-store/subtitles

[00:00] So far in order to debug our NGRX signal store, we were using a quick and dirty way to display the state of the store as a JSON object somewhere in the components view. Now let's take a look at a more compelling alternative in a more Redux style, which is called ngrx
[00:20] toolkit. So let's start by installing the package from Angular Architects group where the package is called ngrx toolkit. The setup is very simple since all that we need to do is essentially just put one line. So let's walk into the employee store, and somewhere at the top, we can put a
[00:39] definition of with dev tools. Now what we need to do in this case, since IntelliJ doesn't want to import it for me, I'll just quickly import it from Angular Architects Njurex toolkit. And the thing that we want to import is called with DevTools. Now with dev tools requires
[00:59] us to put just one name string parameter, which is going to denote what is actually our store going to include since we can have multiple stores within a single application. So this is just a name that is going to make it easier in the Redux dev tools to follow
[01:19] what is what. Now this is everything that we need, so let's open the Redux dev tools. And what we can see over here is that there has been a store update action that was already dispatched. There is yet another store update action that has been dispatched. What we can see is that we have moved from
[01:39] loading true and empty array into loading false and loaded items being defined. So let's see what would happen if we started filtering the data, and let's also put some more data. We can see that the data being defined within the NGRX signal store is being
[01:59] updated. So if you want to have more granular control of what is going on within your NGRX signal store, remember that Angular architects have provided a bridge to Redux DevTools.

https://app.egghead.io/api/v1/lessons/angular-configure-redux-style-debugging-for-ngrx-signal-store/transcript

Scalable Signals Angular Architecture with NGRX Signal Store

Tomasz Ducin

Free Community Resource

You might also like these resources:

Modernize State Management in Angular with Signals

Angular Dependency Injection (DI) Explained

Learn the Latest ECMAScript Features (ES2024, ES2023, ...)

Free Community Resource

Course Content

You might also like these resources:

Modernize State Management in Angular with Signals

Angular Dependency Injection (DI) Explained

Learn the Latest ECMAScript Features (ES2024, ES2023, ...)