State management using NgRx

cool yeah hello everyone uh welcome back to the another episode of tech talks with santosh and this is 19th episode and today we have a very special guest nils melhan who's from germany and nils is a freelance software engineer and a trainer he mostly works with technologists and he also has knowledge on angular typescript node.js and including java based spring framework and if he is not working on for for his client he is also working on a tool called scene lab where he is actually using ngrx a lot and this is where this is how he decided to actually write this book and we are going to actually talk about that book as well at the end of the session and you can actually see the cover of the book ngrx reactive state management for angular and today's topic is the same so we are going to talk about angular sorry ngrx uh so welcome means yeah thanks so much for having me yeah uh yeah talking about njx means talking talking about angular right so yeah actually i think there's so much um it works perfectly in tandem but um yeah we'll probably start out by talking about when you want to slap it on top of angular when you need it right but it's definitely the like i think it's i've looked up these stars on github and i think it's one of the most popular state management solutions yeah for angular okay yeah but uh so even uh in all my projects i have used in grx so it's like i have widely used at enterprise as well yeah all of them are not a single one without njx um fascinating yeah so i remember there was only one project on which i worked and it was it was like starting in 2017 so we uh that time i think ngrx was just improving right so we decided not to use any state management and later on we realized that we we actually in a situation that we need some state management and then we couldn't do it i yeah you you can introduce it gradually i i don't really have like practical experience for this but i i uh like even in the book i'm i'm mentioning some concepts for introducing gradually but yeah most of the time you decide at the very beginning right yeah sure so let's start i mean first let's talk about what ngrx is so our so our viewers on on the same page that they they are aware what ngrx means so can you just introduce us what ngrx is yeah sure um it's a bit hard to get the right angle to introduce someone to njx but um first of all it's a state management framework so uh every time you write an application uh you usually have two parts of functionality like how things are computed uh how the program will behave but um a lot of this functionally is often based on state like and there's all kinds of different states when you write modern applications especially when you're writing user-facing applications that have user interfaces and um in web applications uh on top of that you've got like shared state you've got uh client side state you've got state on the server side and um you've got all kinds of states and really hard tasks is synchronizing this state um if you want a perfect introduction to this and uh i love this introduction which uh alexa cushgroup came out with um some time ago you can just go on on youtube and and find his recent talks he's he he's such a he's such a nice introduction to um to all kinds of states and synchronizing these states can get messy um angular has some really good principles for doing this but um i i think that's that's a um that's this thing you've just touched on um most of the time you start at the beginning of your project how to handle state like in bigger projects i think people who are new to angular web technologies they don't really have this decision step you just start off with with an angular application even in bigger projects i've seen you think that angular's batteries included their state management in there and there is there are techniques for managing state but there will be times when things get complicated and then you might want to reach for ngix um i think this is the right angle to introduce this so uh maybe this a good time to share my uh slides so i can i can and show the problem and then we can figure out what um njx um how njx tries to solve this so uh maybe i can move this up yeah um so this would be your regular state management approach in in angular you have all these components floating around um and most of them like in this illustration all components have local states some don't even have local state in your in your application but most of the time you've got these uh member variables in in component classes and like a variable that state um you've got a boolean variable that's said you've got two boolean variables that's more state and when you've got a bunch of these uh things might get messy but usually you've got some variables in each component and you can even connect them like on the on the left side you see that components actually can talk to each other like to the through these input output bindings and then you can have things like shared state and apparent component and you can bind this shared state down to two child components and then you can even share your state across different um components so that i think this is the most basic form of uh state management that you can can have in angular correct me if i'm if i'm wrong on that but um the next step then would be sharing state different from how you organize your view hierarchy like um all these components you see here this would be your view here okay like this top component is the could be the um your root component usually that's the app component and uh all other components uh go in that app component at some point through router outlets you route them into the um into the parent component based on the url and um then you you build up this view hierarchy and you can share state along the view hierarchy but the problem with that would be that if you want to share state on uh from really to distinct points in your view here key if you think we want to share some state from over here all the way to the component over here it would be difficult because we'd have to funnel this state through this component through the uh root component and back to this parent and then we can get down here and would be we'd be polluting uh all these other components just to um synchronize the states in these uh remote remotely um connected components and that's usually making things messy but angular also has a solution for this um services so that's something i'm i'm mostly an angular developer but i'm i'm trying to get some in to react and uh always always looking at view but i think services are pretty unique to angular and then they allow state management that's decoupled from from the view or the organization of your view in react you'd have these things like uh contexts and context property bindings and i think that's pretty close to input output bindings in angular and services um are something different they allow you to manage state completely decoupled from how you manage your components and this way you can easily connect these remote components without fun funneling the state through all of these parents by introducing a service which can share the state for these two components and i think that's this is already pretty sophisticated and usually you can get a long way with this because the main idea here would be separating the the management of state from how you manage your component tree right and many many projects are fine with this and you can even go go further like you can i think that's on the next slide yeah usually the next step on top of that would be introducing um as observables in order to know when you need to update your view like that's usually when you share state you have all of these places where you can update state from but you also need to know okay when does the state update and there's also an angular solution that would be the behavior subject um this is usually the pattern which you you use as the as the baseline you've you've got some subject which holds the state and so this observable abstraction you can have subscribers which then exactly know when something updates and um this is actually pretty similar to the cqrs pattern like the command query responsibility segregation i think that's a hard word to say but short it's cqrs and this is a long-standing pattern from software engineering where you separate commands from from queries like your um subject your observable that would be a query your querying state um that could be all kind of kinds of state i think authentication is usually something we can use as a good example you've got user authentication in this authentication service and the subject is holding the current authentication there could be something in there when you're authenticated so this user in there when you're not authenticated there's no user in there and you can subscribe to it and that would be your query anytime the user logs out and you can you can figure out um what you got to show in in the view and if you want to update the state you can like talk to the service and say all right um set user that would be base pretty basic or you can you can start a a lock in flow through some command and you'd have this separation where you can um really uh introduce asynchronous tasks and you don't have to um and you can easily have multiple components listening to the same state just through this separation where a service would push the data through some observable to any any components or maybe even other services and this will be under the view when you click a button in the view the login button you could uh you could send this command to the service so that would be the next evolution step i think that's something you've seen a lot in projects like this usually the way you go right you've got input output bindings then you say all right we've got to share something right across the component here okay so let's get a service and then oh we gotta know when things update so we we grab some subjects some uh some observables right but when you don't opt for things like ngx or you're not really uh too yeah i don't wanna i don't wanna bring discipline in the mix but uh you can end up uh with this setup so i'm calling this service soup or maybe it's the state management soup um it gets hot so you've got all of these different states floating around you've got all of these service services like next to the authentication service you've got some other stateful services which manage the data you're displaying in the view and this state is actually referencing state you've got on some server-side database other state is supposed to be synchronized with your local storage and you've got all these states uh uh in your application around in the context of your application you've got a you've got a um you've got to synchronize these between different services maybe you can make this easier when you slice these services right or um you've come you come up with um nice concepts to manage this but usually the concept you come up with when you encounter this service soup which you see here where you don't really know what's going on like i i made this up this this isn't uh like particularly based on on some real hierarchy but maybe this ring in comparison to some projects you've been in where um like these little async loops come into the mix and oh we gotta update this state when um some http request returns and then there's this callback which has to run all the time and it has to update this little service down here and oh yeah we've got to still push the data to some components and things might get messy and usually what um the people who've built njx the people who build redux or elm they all come up with some some form of the the flux pattern or redux or the basic principles that underlie njx um and maybe this would be a good point to explore these um but this would be the problem you you gotta have when when you think all right maybe i can do something different here right um that should be probably um the case for projects uh you know right say from the we're beginning okay we don't want to end up here so let's start out with njx right at the start right yeah okay so this is uh actually this image reminds me the first project which i was doing a large enterprise project so this is where we ended so after a year i think that project grew and it became really large and after that we actually ended in the same situation where we needed some state management and then we decided that okay we will actually go ahead and put ngrx in the in the code base but we couldn't i mean of course i left the organization before that but yes it might not always yeah so yeah so this is some form of state management but it isn't really it isn't really formalized you've got this command query separation which is big plus you've got the services that's already a good step but um then things still get hard when your application gets to a big point and then the solution that njx provides um or that njx's base solution um like they've got all these other libraries we can we can touch on but um the main solution is this this store that's based on redux principles or flux principles that would look like that yeah if you should it brings to uh okay so it actually uh ends to our next question which is flux pattern so we often whenever we go through the state management techniques right so even uh when i read about redux uh and then we can i came to ngrx so it was like it says it's a redux based pattern and then when i went to redux it says it's a flux based pattern so what is proof this flux pattern actually is yeah there's no um like i'm i i'm i didn't invent that i didn't i didn't work on njx so um i try my best to uh uh to put this right here but um it has all sorts of names um it's called the pattern is usually called flux and then redux is called is the the most famous implementation of this pattern it's usually it's it's uh it's um dated back to facebook introducing this patent well it's probably been around before then that is actually the pattern uh coined by facebook um we can we can step into this uh into the specific principles of this pattern rather pretty nice side for where they showcase these uh three pins principles but the basic i don't know if this is particularly um a a precondition for redux and this is not um embedded into the principles but the basic idea before going to redux is global state so instead of having all of these services manage some slice of state and synchronize between these services you just say all right just make everything global state we just have one place where state is managed and there we can organize our state appropriately and at the same time we go away from these commands we don't want anyone else telling us uh what's going to um happen with the state so this uh service in the middle that's managing the global state okay has the full authority on managing the global state and it updates uh when it receives events so in this illustration you see that components can send events um send an event um at the same time the service still pushes data to the components and services so you can even do just one of these things so one component could be just consuming and a service could send an event um so we keep this query query concept we keep observables observables are the the foundation of njx and i they also like the foundation of for redux red x doesn't use ics observables but you definitely can subscribe inside redux yeah so components definitely know when they need to update but they don't know why they would be updating they're just now all right there's some new state so i gotta render this this view again and um these events just tell the global service what happened and the global service decides what what should be your next state so maybe that would be a good point to jump into the principle so this global state part yeah all right it says global state so uh take back all of that uh it's embedded right in the first line um so it's called single source of truth um the question would be what's global state so the state is still in your in your browser right it's the web application it isn't global in in in comparison to your database you still have this remote database storage but inside your whole whole application um that's running in the browser or you can you can also use this in other application frameworks but there you say state isn't tied to components it isn't even tied to some chat services but it's just in one place and we've just got this one state i think this is a difference in explaining radox to angular developers and explaining red x to react because you bring these two elements to uh into the mix like for react you're bringing something similar to a service and and global state at the same time and to angular developers you bring like global state having something where you saw all of the state in one place and maybe most maybe some react developers would also be fine having just stayed outside of the new hierarchy um i'm not expert on react uh sorry if i uh gone out of my territory there but yeah the first principle would be single source of truth so these are the principles from redux but you can almost one-to-one match them to towards ngx it's it's almost the same idea go into into framework specific considerations but the basic idea is you have all have this global state um this object tree where you manage all state that's meant for all of the application so you wouldn't put like is this drop down open or not or am i hovering this little headline here you wouldn't put that into um into the global state but uh all of the state that you usually share in a lot of places like authentication state you'd have this in the global state and then the next really big part is that status read only [Music] so uh read only means immutable right and that's something uh it's really um not too familiar maybe to regular angular button and it's it's not something that you get um you get too much driven into when you just start out with basic angular development but i've learned over over years of developing in different different areas that immutability is maybe a bit tedious at the start but in applications like javascript it's embedded to such a good degree that it just helps you all the way through how would help in redux is that uh you don't accidentally mutate someone else's state so state is only read only you can mutate state you can only say all right the last date is outdated we've got a whole new state and now everybody can render their components based on this new um state and this way you don't have any any um state-related bugs like and redux or njx isn't a guarantee for not having any state-related bugs um there's still some points for improvement but um you don't uh you don't um it works very well with uh different with these access subjects and observables where you can just say right anytime something new comes through your observable there's new state to render and won't ever mutate the old state for for any components that didn't update update so there won't be anything um any any any weird runtime concurrency problems where um you actually then mutate the state of someone else and something wrong is showing up so the only way to change state is to make an action and that's that's been we've just had in the other illustrations so you dispatch this event to the to the global state service and um the service computes the next state based on some information uh in this in this action um and then you can have a whole new state like in this example it's an action in red x would look like uh it has an identifier and a payload and based on that i won't go into the api too much of redux it's similar to lgx but we'd rather get the njx variant right and the last principle for redux would be the third principle and that is that changes are made with pure functions pure functions are any functions that only work on their inputs and only specify their result through the return value so a pu function doesn't doesn't grab any any other state it doesn't know about state and it doesn't mutate any objects it um just returns a new value that's only computed by the information embedded into the inputs so um that would be your reducer um so i think reducer isn't like the most approachable word but it's basically a function where you throw the current state in it's just know basically that you throw in the current state you throw in these event information and it comes computes a whole new state for you it doesn't mutate the old state doesn't reach for any any um any uh side effects like it doesn't make http calls it doesn't create a database no local storage in there just the action information gets embedded into the state and these are the three principles and based off of that redux works ngx works this way the m architecture is often referred to as a foundation for for these principles [Music] i think it's good to see this on some kind of illustration maybe probably should have numbered these oh yeah so everything i've said would be embedded in this architecture diagram so this global state service i've talked a lot about that's called the store and that's the centerpiece solution of the njx project njx has other um libraries that don't that are unnecessary necessarily collected connected to the store but the basic idea is having this ngx store and that's the same idea and in redux you have this this door which holds the current state and it has the the ability to accept um except uh events and and they are called actions i think this is a bit inconveniently named i think in hindsight people like the creator of redox and the creators of ngx would have probably named these events um but you can think of actions as a representation of of any events that are like uh interesting to the global state um so maybe a button click that says login and then the store is a observable at the same time so it's underneath it or there's your regular behavior subject which is a observable holding the whole global state in one object and you can use it to upset update your components so your opponent subscribes to your store and it updates and now when you click some some button in your component like the login button you um or maybe maybe start with some something easier than the login like your increments and number or you you add this to do to your application then the this uh action falls into the store and that's where the other principles um really work well um because this pure function i've talked about this changes are made with pure functions the third principle this is your reducer so we have this global state that's the first principle the second principle is that we don't we don't mutate any states so we we have to like compute this next state down here from the current state and we do this with uh pure functions and this the pure function at the at the base of njx and the store that's called the reducer we would use the accept two different arguments that will be the current state and this action you've dispatched into the store from the component so don't care about the right part right now here and when you drop both of these into the reducer it's a it's a function that um adds this to do to your state or and adds this user to to the authentication or increments this number by putting a new number into your state and the result would be the next state and njx will pipe this to your observable all components and the subscribe can update and um all your problems are so solved at that point i i'd love to say it's not that easy but um managing all of the state in one place and you've put you put this constraints these constraints on on your state management makes things actually easier like right now we can't do http requests we can't do any any any storage but just for the state part it's easier at that point because we don't have any surprises we want mutate state that's used in some components and we can perfectly retrace what happens so if you throw an action into the store things will happen once as they happen 100 times and you can always know what happened in hindsight you can actually go back and forth through every application you can look at that later and this makes things um not necessarily easier but uh you you can manage complexity at that point because it's traceable it's you can reason about your code and it's it's easier to test at that point because pure functions as we're about to see later maybe are easier to test than mocking all the shared services and building up this whole um like surrounding of different services in states is way harder than having just one state one input action and making sure that the current next state is computed i really like the concept i mean the most important thing is it's easy to test so you know what is getting changed and when it is getting changed you can just always shuffle between and play the previous inputs and see how your state is being changed so that's that's really good i think yeah yeah definitely um like there's really nice tooling around that um we can we can look at that in a second yeah yeah sure so uh the next question is uh so as we were discussing about reducer and ngrx has something called meta reducer so can you just tell us a little bit about what meta reducer do and why it is used yeah sure we can we can jump and some meta reduces um i think it's an advanced concept so don't uh don't get uh anyone anymore watching don't get just discouraged if this i think this part is already uh like advanced and if we throw meter it reduces on top it gets really uh it doesn't get too much harder but it's it's really powerful but um this is actually what led me uh to like doing open source for njx like not working on the actual project but i've developed um this project uh for implementing under redo based on njx so uh i thought i wanted to develop a an application where you can under redo changes on this graphics tool uh we've talked about in the introduction i knew i needed under reader for this and i thought yeah right if i just go for red x if i just go for ngix i get that straight straight out of the box well it wasn't that easy as most of the time you think uh yeah if i write technology things are going to be a breeze it wasn't that easy but if you think about it um it's really similar to how you um implement under video if you if you have to build it from stress scratch so under really would be going back and forth and pressing ctrl z on your on your keyboard to undo your the latest changes for graphics editors this is something anyone expects to be able to do and if you think about it going back uh one step in time with undo video that's really similar to reverting this reducer mechanism um you have this next state and by pressing ctrl z like this error is actually just supposed to mimic uh the next state going back into the reducer like this happens in ngx regularly in in a loop but if you call it ctrl z should actually just revert the whole application state to the previous one um and that's actually how you can implement the undo under video in ngix um and you can do so based on a meta reducer i can practice a whole um blog post where i explore three different techniques for implementing other videos so go check that out if you're interested and the final result would be the applica the library solution i've i've put out that implements this for you with with some added benefits so i didn't make it as easy as i just said but that would be where you'd be using meta reducers and like i've also got a slide from meta reduces from a talk i did recently oh yeah just use let's use this one so uh this is that is supposed to show the same thing we just saw we've got this action and we've got this state f1 being dropped into our reducer and it produces the next state i've called it s2 and now because changes are made with pure functions we can repeat things as long as we want like we can drop these in at the top again and we can store this state s2 somewhere but we can also store s1 and when we want to implement undo we actually don't want to compute um then like the next state we want to compute the previous state so we'd have to have some place where we store the the previous state so um at that point uh you'd model under redo like just another action when you press ctrl z on your uh keyboard or whatever it is on your keyboard uh this underrated would be dispatched to your store and instead of putting it into your into your regular reducer where you'd be handling like adding to do so managing the authentication you'd be having this meta reducer around it which is a regular reducer but it wraps an existing reducer and this way you can do a check all right if this action that's coming in uh is called undo then i don't come to the next state but i grab the previously saved um state s2 and i just returned that so you can actually in a couple of lines implement a basic undo and also redo functionality so redoing would be going back to the like previous future states it gets messy when you talk about timing and state so yeah there's no real uh like dedicated terms for that but uh yeah under undering means going one step back and redoing means you've done nothing in the middle and you still you want to go into the future you'd say you can implement this into a meta reducer you can implement lots of stuff into meta reducers people are i've got pretty strong opinions on that but um method reduces up on first side pretty handy um for implementing anything that's generic on top of your state like people are implementing uh synchronizing your njx date to the local storage so anytime state comes into your meta reducer the the actual reducers invoked and the resulting state is stored to your local storage in this way you'd have um like autosave functionality for your state and this is actually in the book like in the book i've uh implemented um i've shown a pattern for how to um how to uh serialize um state your ngc state with a meta reducing and then uh after showing this i'm showing a different way of using things the way they are supposed to be because we've just said it's it said you test on the slide you want to work with pure functions so if you know use your meta reducer to do something like impure that would be storing something to local storage because that's some other state yeah um doing doing things that aren't the outside of the scope of the state itself and the action your meta reducer will be impure and then this makes things harder it isn't forbidden you can do it i don't wanna wanna say that that you shouldn't do it but maybe there's some value in exploring different approaches where you uh throw effects into the mix and that's maybe maybe a good point to talk about effects so we have one question uh let's take that so anand has this question is using facade good practice when should we use facade and what are the problems and cons so um what's i think this is a heated discussion so it's always a heated discussion if you're talking about good practices in my or best practices you should always evaluate your use case uh there's a whole chapter on on the facade pattern in my book um i've been a bit uh i've been very straightforward with facades uh i don't think they're necessary when starting out and maybe they even do some um to the underlying principle so the principle in njx is that you have these um like these inversions of control where you don't really um tell the state what to do and you don't really know what happens when you dispatch an action because um the the event itself isn't supposed to know what um its dispatch entails so if you now introduce facades into the mix um fact you got a slide for that so maybe let's explain facades uh before that or maybe we can we can like revisit this question later because it's already pretty advanced i don't know i don't want to uh yeah so yeah we can we can actually come to come back to this because we have to discuss few more things meanwhile i mean uh so meanwhile the viewers who are listening to us you can actually buy the book which nils mentioned on gumroad so it is published and let me just share the link in chat and you can grab grab a copy here yes we can yeah there's there's like i've said a whole chapter on on facades in there so if you're interested um there are great articles out out there and um people tend to like these because they seem similar to where you've been before but when you um embrace ngx i'd say um it's important to embrace this indirection between between state and events and you have these you have these like dumb components components don't really know what's happened what happens when you dispatch actions you don't really know what happens when you dispatch events they just dispatch events and this way uh your architecture gets really extensible because you can um you don't have to mutate your component you don't have to um synchronize more state when you want to add things on top you can just like just depends but you can always add um headless for your events like at some point you maybe don't want to handle some event in a synchronized fashion but then you want to fetch something from your back end based on this event and you can do this without mutating your component you can do this without mutating your architecture and that's really um a big point why you choose ngx and in my opinion if you see yourself using uh reaching for facades all the time um maybe you don't want njx so this isn't um the pinnacle of state management this isn't where you should add up if you do this big enterprise project um it's one way of managing um state and like you in the beginning you said you've talked about this this graphics tool i've i've built with um with a good friend of mine and if you if you this is the website of the um application don't want to promote it or anything but if you think about this the application looks a bit like like any any graphics editor you might know and you have all these different ui elements you have all these different settings and you can move things around and you can even um interact with all the elements in there and we even have different types and all these things are interacting with each other but they don't want to know about each other and you don't want to um and it's always been handy to just have all user interface components dispatch events and we can just think about the state and we can think about displaying things like in a different part of our brain and this is something where i think njx really shines because at the beginning we tried without njx and then we said all right uh maybe we should grab the big guns but uh if you see yourself reaching for um facades you might want to consider if njx is is right for you um but uh something that's really powerful and that's um that's the effect of njx and this thrives on on events in my opinion so anytime we'd had to introduce some asynchronous behavior like auto saving things to the back end based on events or rendering different parts of graphics into other graphics uh effects and the event-based nature of njx was really helpful and working around this with facades wasn't some something we like thought about at any second there yeah go ahead sorry i know i will come back to this question and so as we as we said uh anyways uh nils actually covered it really well so where maybe you may need or may not need facades but yeah so uh let's move on to the next question so in this diagram you discussed about a component actually getting the data right so if we write selectors in ngrx for that so what are the selectors and why it is important yes nexus in this picture because i don't think they are um essential to ngx uh um again not no i'm not an expert on red x or anything um but i think this has been a problem with um redux and react um where you need to subscribe to the state in your global state in your store like um then you you'd say all right we've got this global state and now we need to update all components um across our whole view hierarchy so how do we do this how do components get these state do they get the whole state how do you notify component of components of the off of this and i think this is really nice the integrates with angular because you've already got rxjs you've already got these behavior subjects and now you just have to push this out to components the way components get the data is to select us i'm just going to find this i think that would be this one so we've got the state object and inside you say there can be different things uh i think a regular question that comes up is um uh do i do any multiple stores if i if i've got multiple uh different parts of state so the answer would be no you have just one store all the time one global state but inside the state you can have completely different things like this triangle that would be your authentic it could be your authentication state and this square could be your to-do list but now we've got just one component that's interested in your user state and the way you'd um give the component access to the user's data that would be a selector and the basic form of a selector would be like the terms aren't all too clear on that but i've called it the property selector i think the docs also called it property selectors and this is a function that gets the whole state and just returns some part of it doesn't doesn't shift things around it just uh takes a bit it takes the old state and returns the specific bit that's interesting to a component um and this way you can subscribe to the state and the selectors are like you you pass them to the select method of the njx store and at that point um you've got an observable just for this dedicated piece of state and your component will receive the um newest version of this single slice of state this way you've got your components connected to the store in a reactive manner yeah if things get uh more sophisticated or need to get more sophisticated or like uh now you want to combine these uh different parts of the state together or you want to build up new models um like you've got this perfectly arranged state management but uh what you need for the component would be something different then you can actually different reach for a different kind of selector and that would be a computed selector so um we still throw in the uh the whole state on the left side so that's the base for any selector and um computer selectors are based off of um regular property selectors so um at this point we've got these two parts of the state now you want to combine this to-do list with your user um can't think of a good view for that right now but uh you have you often have requirements where you uh want to combine different parts of this okay and where you start is with these property selectors so you'd have a property selector for the square like that could be the upper one here and you have a property selector for your triangle that could be the lower one then you have this part projector if you're working with njx or um like any any functional um parts you maybe maybe have seen that in extras you can you can pass projectors to a map function so a projector something that takes some inputs and projects them to a different form it should be a pure function where you recombine the inputs in some way to build a view model so here i've stacked the triangle on top of the square in order to build a little house and this could be a computed selector and this way you could build up view models for your components still in a reactive manner and um the big part that's interesting with computed selectors is that they're memorized so i didn't miss an r there it's similar to memorization the computed selector actually caches the result that it has computed and that's possible because the projector function should be pure and like we've learned in the beginning um if your projection if a function is pure you can just guarantee that it's going to result in uh in the same output every time and so uh for the same arguments and so if you encounter the same arguments um the exactly same um inputs then you can guarantee that the output is going to be the same as before and at that point you can not you can stop recomputing and you can just say all right i'll just return the previous result and this way things get performance so you might have this global state part but um computed selectors you don't miss miss out on performance because you only have will have components looking at some specific slice and even if you do computations from view models this will be still performant because the computation is memorized yep that's cool so one thing i think i would say here is if you have worked with behavior subject and subject you will realize the true power of selectors how powerful they are definitely um yeah selectors are the place i love to write uh it's uh so straightforward you have these inputs and you say all right i need outputs and you can combine them especially in typescript so i i'm coming from a java background and in typescript it's just so nice because njx has this perfect type support where it will infer the type so nicely for you um and uh that's just a big plus of njx in general the type support um in every every corner like you mentioned uh i don't know if you mentioned it actually but uh njx has gotten so much nicer than the uh recent versions i think it's especially version seven and eight where they introduce uh introduce creative functions yeah you name it and this makes writing selectors so um straightforward um we could jump into some code in a second because i think we didn't look at code yet or should we just cover effects and then we can actually see the entire code which also covers effects so let's talk about effects next and why they are important where they fits in in our ngrx flow so um we've put all these constraints um on our state management in order to make things easier like we don't have side effects we've we've got immune immutability uh and if you go through this and think all right where do i do my http requests i just can do less now things might be organized but that's because i can't do asynchronous operations and the thing is you can do asynchronous operations ngx has got you covered there um you just do them in a really formalized manner and this formalization is called an effect so one slide for that so the actual store doesn't care for any side effects so the actual store doesn't um so it's even even separate packages in ngx because you can use everything we've set up to now without effects you can say right i want to keep everything pure uh this will get hard at some points like when you when you want to save data you need effects or you can either build them yourself or use the library for that um but effects is actually really nice term for this package because what we're dealing with is our side effects and that's anything that's impure like saving state to a database that's that's a side effect because you can't just do it based on input arguments you can't just do it um without reaching out of your function like changing changing a class property from from a class function that's a side effect because this class function uh doesn't have the the input variable in your in your um in your arguments to the function so anytime you reach out of your pure function uh for network requests or towards your database to your local storage that would be a side effect and side effects uh get messier as we've seen in the beginning uh synchronizing them gets hard but we've seen that managing state with this uh event and reducer combination it's really nice so it'd be nice to map effects just on top of that that's exactly what has been done with ngix effects so these blue circles you see here would be actions and now i've said any any component would be dispatching like a submit action you submit your to-do to uh to the to-do list and the reducer covers the rest you could just put it into the state and you'd be done but now if you want to save your to-do list to the server and the book is actually an issue tracker so that's just just an advanced to-do list i'd say but if you want to now synchronize this to the server which is something you you do in like almost any productive production application you need some http request on any any any network request and the effect is actually this little line connecting the uh actions here so you can make your round trip to the http uh um to the backend server through this http request and um in angular that's um based on the http client and that means you're dealing with some some observable there and observables have these callbacks on next so when your http quest is done you go and dispatch this submit success event or action and you do the same when your submission fails and uh as we've seen now um you can actually have side effects and you can map them really nice with ixjs so you you should be a bit familiar with ixjs when you're going into ngx but the actual statement state management solution stays untouched here because um we're just just dealing with events at that point because the store doesn't know about the effect this the store just knows about the submit event it does know about the submit success and submit failure actions and these can have payloads like you can attach the to do to your actions and anytime this actually reaches the reducer in your store you can update these days so if you save the to-do to your server this you you maybe have some angular form and uh the value from this form you'd attach it to the submit action you dispatch it the reducer doesn't care about it because um you just want to save it to your store when it's also saved on the server that would be pessimistic because we're pessimistic about does this work on the server side so we we work for the success we wait for the success action um and this is based on the observable and when the observable is done it will dispatch the success action to the store and at that point we also have the to do attached to this success action then we can place it in the state and all components can update based on their selectors so your to-do list would have selected the to-dos and then it could update and this way we can have side effects and formalize them into these rxjs observables which we place in services as we're about to see and this makes this leaves everything as as easy and organizable in our actual state in our store but we don't lose anything we can still do side effects we can still have http requests so i think we can we can actually go to an example and see how it is written so sure um so um the book comes with all these little steps for every chapter so we'll just jump right in uh into the middle i'd say so uh this is our to-do application in my case it's it's an issue tracker so we've got some more fields we've got this title field uh where we can like input the tasks for configuring https for our website and we can add a description and maybe maybe some priority so https that is something you you probably want so that has a high priority and submit button uh would be the place where you have the first interaction with ngx this is a regular angular form and when you press submit it actually dispatches your um your actions um so i press this and we see it showing up down here and i'd say uh we now retrace how the form value just got into our list and then we can see actions uh reducer selectors and the effect for that starting off something really powerful that's that you get when you use ngx are the red x dev tools so these are tools um for oh that's actually pretty a bit difficult if you're running um that's the f2 it's on on stack this yeah you gotta select the right uh store instance instance i think this isn't even right yeah this this should be the right one um let me step to show you um the actions just can you just increase the font i think oh yeah i just zoomed in i came in yeah it's a bit hard to zoom in on this one maybe i can uh click this pull it out and zoom in here yeah and now i've got to reselect the right instance so um we get this list of different actions which got dispatched to our state so it starts off with some internal stuff so we don't care about this right now but here you can see the actual actions actual actions which get this by our submit button so uh the submit button dispatch an action which has the type of issue submit and it has some payload attached to it which are actually just the values from the form so here you can see the title i've put in the description and the priority and this is dispatched to the store and we can also see the changes here states are equal this action doesn't do anything to our state because we still want to wait for the http request we still want to dispatch uh send this to do over to the server once we know it's saved in some kind of database we want to uh have this submit success action which you see down here and then we can place it into the um into the state so i'd say we go back to this in a second and just have a look at this um the place where this action has been dispatched trying to increase the font even more oh i think i gotta press yeah all right uh oh this all right uh we've got this um new issue component which is the place where you you're seeing the uh form over here isn't completely mobile responsive please forgive me for this one um oh this is the test um and there's your submit function so that's a function which i'm calling from the template once you press the submit button and there i just passed the value from a regular angular form which i've created prior and uh interact with the store through the dispatch function that's if you think back to the command query separation this is basically the first direction where we want to inform about our state management about anything that's hap that has happened uh but we don't actually tell it what to do so we just had it all right a submission has happened and these are the values um the form value is passed in s as the issue and at that point it shows up in in the redux dev tools and then we gotta go over to the place where the um action is processed and that would be inside my store folder where i have this this feature slice issue um if you think back to the illustration with the little triangles and squares issue would be like this square and the square is managed by the issue reducer and inside the issue reducer this is our pure function where we throw in the current state and the action that has been dispatched and the creative reducer function and the initial the create reducer function is actually one of those creator functions we just mentioned and just does a lot of typing stuff for you but in the end what's placed in the reducer is a function that accepts the current state and an action and will return to you a new um a new state um if we look in here there is no handling for the for the submit action because we don't want to do anything once the issue is submitted we want to do something once uh the submission is successful so once the mission is successful we get the current state and we get the issue we just dispatched and we gotta look at the effect um in a second so um maybe let's look at the effect first and then go back here but um what you see in the end is uh this is good isn't might be not the best place but in the end we um place the issue into our um issue list which i'm calling entities here and um you might want to ignore the produce function around here you can work with the spread syntax and it produces the key point is you don't want to mutate the state variable that you put in here right and produce that's actually a library called imma that's really handy if you want to still have these have the ability to do mutational syntax on your state so here i'm actually assigning the issue to the entities dictionary i've got in my state this is something you wouldn't do without the produce function um usually i have to write this differently you can just write in here right now we want to return a new state where we put in the whole state but um oh i gotta add some braces and um we just keep the state as it is so we spread the whole prior state into here into this that's the missing brace here and um the entities dictionary which i've defined in this in this initial state at the start of just an empty object um but that's where we want to place the the issue that has been successfully um submitted and we index it by its id that's some part of state normalization whole chapter in the book about that it's a good point for keeping things organized so instead of having a regular list we just have this dictionary but we use the id and sdk and the value would be the issue itself and this way we can place it into the store and this is just a pure function because we don't mutate the state or the issue we just create this new object where we spread the um make a shallow copy of the current state by using the spread operator the regular javascript spread operator and we just overwrite the parts that are new um i think we're missing the current entities here so in order to keep the entities which are in in the list before we need to spread these two so sound on that and you can write a lot less if you use this this imel agreement that's a bit much maybe getting into right now so but if you want to re-retrace how we got there we still need to look at and look at the um effect so the effect is mapped in the in the um in the issue effect fire and they've got this submit uh dollar observable which is the finished notation like you can use any variable name here but um it's convention more or less to use these uh dollar signs for observables you probably know it for for a regular access that's the same and there you've also got this creator function for creating an effect and you pass a a factory function which which returns an observable which starts at the submit action we've seen in the illustration does the http request a round um trip and then either either goes to these uh success event action um or when it fails it it could dispatch a failure action which isn't in here but what we do is we subscribe to a stream of all actions so if we think back to the um redux dev tools you see you've seen all the actions in in one list so um there's a service from njx which is called actions where just all actions fly through all actions that go through the whole application will fly through this observable and we can pipe it um in order to get a handle on this and say right our effect is based on any action of type so this is an advanced like filter operator from rxjs which uh watches out for any actions that go through which have the submit type which i can reference like this and anytime this action comes through i'm doing a merge map so i want to look at some other observable and i want to merge all the results together and here i'm using some issues service which under the hood just does an http request that saves the form value to the backend and when this is done um i'm mapping the resulting issue to our success action and this way it can go back to the store there so any actions that com that come out of these effects i actually returned to the store um so if i map to to an action here and return this to the create effect function um by registering this uh with ngix i'm actually um this continuously dispatching new actions based on other actions and we get this um this little um flow diagram from the illustration where we can lead from submit around the http request to submit success back to the store [Music] so uh we have a question here from elise so uh her question is related to email library so the one we you mentioned so she's asking if uh the email library provides help with entities does it differ from ngrx entities adapters uh it does differ um very much um we've just seen it on on something i've called entities um but there are two different things so emma isn't specific to ngx it isn't specific to redux it's just a library that allows you to um copy states or any objects right basically you can throw in a state and you can pass this past this function where you get a draft of the of the current object and mutate it with um with producing no you can mutate it with mutable functions sorry if you said that so i don't have to make this whole spread syntax here i can go ahead and pass the whole state to this produce function from emma and pass another function which will then work on this state uh and it doesn't directly work on the state but it in instead works on this draft has the same type at that point but i can now um basically mutate this state and this state happens to have this property entities and i could just write the issue directly into the draft which is something i usually wouldn't do with a regular njx um i'd be mutating the state but if i mute the draft this produce function will go ahead and um create a new state based on anything i've done to the draft so it will just record all right um he's uh he's mutated the entity's um dictionary so i gotta spread the entities dictionary so this is what emma will do under the hood i i um encourage you to pick up this library it's it's a really nice library from creator of mobx actually which is a statement library for um that's really popular in the react world so even says that it's a it's a good liability and alternative to objects object or freeze so yeah actually just also freeze your state so you can easily see um when you've mutated it at some other point in your in your application it makes entity something uh entirely different or it works on a different level where it helps you working with entities um so it will uh it's it's it's close to each other um because it solves the problem of having like boilerplate like having too much gold or doing simple tasks okay so norali has this question can you add error handler i have a few effects which are erroring out even when ah they have catch error so uh i'm not sure are you referring to syntax syntax error or you are referring to the runtime errors um he's probably uh he's saying catch arrow it's written in camera case so i think he's referring to guantanamos like from the hdtv request i'd say yeah i mean uh so in case uh you get you have any examples you can share it with us probably you can reach out to niels on twitter uh his twitter handle is mentioned is in under his name but probably you can reach out to him with an example and uh we can look into that yeah you can otherwise like the regular way would be um adding a catch error to your observable or to to the inner observable actually so you you have this http request under under the the safe card you can go ahead and pipe on top of that and then you can catch it like the regular catch error from isos in here and you can you can provide uh like the summit failure action we've seen in the illustration before uh at that point you want to move this map call into the inner observable too um so not with the whole effect stream but that's how you'd be dealing with failures from effects but you always got to think uh what am i supposed to do with this um era so you know there's also good articles by um ngx members like brandon robots on on handling uh errors and i'm also touching on that in the book um like um what can you do in this era so you can you can you can work with backups you can you can do a pop-up at that point um through some notification servers so these would be cases um i think this is the example from the book uh well what i'm doing with um okay so just to uh mention it again really uh this is the link for the book you can actually buy it from there so you'll be able to get some good examples but in case uh you you're still struggling with those errors you can just tweet i think there are many uh ngrx experts out there they will be able to help you oh uh that's actually not not the link you gotta remove the latest uh latest part of the link that that's just linked for you this isn't going to work for uh okay okay uh so the uh angular engineer expo right so last right right it's just good now this is this is the one so yeah earlier wrongly this is the correct link yeah uh so this is uh related to ngrx effects and uh can we see an example of this selectors and then we can move on to the next question yeah perfect uh select us yeah that would be the last part so we've now got this um this action going into the effect and it does the http request and we've got this other action which we've seen uh will go back to the reducer which in turn will update our state so a lot of moving parts were just doing um just manning managing a to-do um list or some issue tracker but if you have all of these different events from from an application that uh that like a graphics editor or um general applications that have a lot of state or a lot of moving parts then this will make your uh make up for some headspace and um because we in the component itself we don't have to care about all of this so i've got this issue list in here which is a regular angular component and it uses the other big part from the store which would be the queue and the command query responsibility segregation principle so recurring the store at that point and this you do so the selector um you call the select method on the store and there you can have a selector which you specified earlier so this is um actually a computed selector and it's imported from a selector's file i'd say we just jumped this i think we also missed uh looking at how you create actions um maybe we can jump uh yeah jump into this in a second too but selectors are defined over here and um you can have regular um property selectors which look like um like this at the top so at the top i'm saying all right i just want this this feature like the slice of state it's usually called a feature and if you think it back at this big box where the triangle was selecting a feature would be like getting one shade from the state and you pass in this whole box which uh i've typed as the root state and you get this issue which would be the square or something so this is a property set up and it's just really basic it's just a function where you throw in the whole state and you just pick a property and that's it and you can pass this to store.select um and that will provide you an observable which just updates when this part of the store sword if you want to get uh you can if you want to get more um if you want to do more with your state or you want to memorize some part of the state you can use a computed selector which is done with this create selector helper function where you pass in all your property selectors like from before these green green filled errors arrows not errors i just passed in one property selector which uh just retrieves the whole uh the whole square and from this gram i'm fetching the entities property so i've got this dictionary of items uh the thing is if i want to display these with and with ng4 in angular i still want a list because i kind of i can't easily iterate dictionary so i've also got this select all selector which is based off this previous selector but has this projector function which calls object values for the entities and this way i get all the values from the dictionary that will be a list of issues okay which i can display in the list in the component we've just seen the selector wasn't used and then i'm using the select filter which also incorporates the the search field you can see on the right here um and select filtered um combines the select all and the select filter so we've got this list of issues and we've got a filter which just has a text which i can use to search in my in my issues on the on the client side and now if i want to select only the filter issues so the ones that would be matched by the search input so we've just had the configure https issue if you want to search for that you type https and if it's in the title it should show up and this is done by the select filter selector which is based off the select all computed selector and the select filter computed selector which i just memorized which is just one memoized property selector and one that actually does some computations here and then we can pass a projector function where we have the results from the previous selectors and combine these in some way so we've got the list of issues and the text property from the filter and now if there's a text so i know i only want to filter out the text of the search book exam i want to display all the issues right for usability purposes um i'm lowercasing these texts to make them easily matchable so that's just something i've done in this example and then i'm calling issue filter which is the regular array filter operation and i'm filtering these issues based on their title and description so if https would show up in in the title or description of your issue it would show up in the results and this way i've got a whole view model that just models the idea of uh a list of issues that can be filtered and i've still i still didn't touch the view and this is this didn't touch any other state and it's basically this function that doesn't go anywhere else i can i can test this um pretty much straightforward and use it with one line of code in the issue this component which i'm doing here what i get is this observable of uh issues of issues and i'm in the view i'm displaying these with some sort of edgy fire using the async pipe here too and then i just just display these uh these um different uh issues so we've done the whole round trip um so if i put in configure https secure the page with https put some priority in here it will submit the submit action if you go back to the dev tools so this is again a bit tedious here oh my god it has put up a couple of things and i won't start you know but uh it would submit um dispatch the submit action which will make the http round clip the success action will go back to our reducer the reducer puts it into this entity dictionary using image.js so we're touching on a lot of uh aspects here uh don't get discouraged you don't have to uh couple these things up right from the start um you can you can make your way there that's also how i'm doing it in the book like build it up step by step but i think this would be the whole example and once it is in the reducer it will be picked up by the select all and the select filtered selectors which will compute the list and now if i search for something like um example it won't show up but if i search for it it would still show up in the in the list ah so let's take one question uh from chirag so one problem that i encountered maintaining strict immutability is that the mat table component re-renders when the reference of tables data source changes to you have some suggestions i think that's the default behavior of matt table so i'm not sure what you want to uh i mean i don't know if it's a big problem when [Music] like re-rendering shouldn't um shouldn't be a problem because it doesn't mutate yourself right like re-rendering would be just updating um updating the view but you would have to write um a data source which is attached to the njx state so um you can implement the uh data source uh interface from njx uh sorry from the material library and you can attach it to the store it's not something i've done particularly but i've written a blog post about writing a custom data source for the material table so maybe you want to look into that and then you can figure out how to write a data source which you attach to the ngx store and the data actually works with uh with an observable and um you would subscribe this observer to the store and then the table would fetch it from there maybe you have to rephrase your um question regarding um immutability again because i i didn't i didn't get that part uh much yep sure uh so let's take another question from elise so elise as this question i think effects can lead to complex rx just operators channing especially when it deals with the sync operations do you have any advice to keep it simple and yeah so is really powerful but uh it can come can be complex so i i really like it uh but um i definitely don't think it's um the best thing ever everywhere and there should you need to keep it simple it's powerful but chaining a lot of operators uh can create a mess so one basic rule i i have for effects is um just do the orchestration there don't do anything that isn't related to the effect orchestration so orchestration would be um for a regular effect you'd be uh having one action that goes in you uh tip off some async tasks and like you've seen in our example that was in our issue service so i don't know if it's actually an http request or if this entered some more asynchronous tasks i just want to um refer this to the business logic of side of things and just when it gets back i'm i'm only orchestrating how it uh communicates to the store with these other actions it still can get complicated um at some point you got to think if you might want to split it up into different um actions and you might want to separate into different uh effects so you don't have one effect that uh like goes back to the action stream to wait for another action this this might get messy uh at that point you want to split things up you can even have effects which uh unconnected to both sides of um both both sides aren't connected to actions so you um can have different sources and maybe when you shuffle things around you don't have to you don't require all these operators and maybe you can outsource some of these two services um but yeah i don't have one one size fits all solution here i think this is a general problem um when you chain rxjs operators um too much yeah but uh actually the hardest i'm probably the hardest part uh in terms of ndx so uh let's move on to next question and then we'll take some questions from the chat so the next question i think is it's related uh how to split the state into multiple modules so we generally uh don't put everything into a global state right so we just split it so can you just show us uh show us how you do it in njx yeah so the idea is um we have one store we have these different um shapes in there and these different shapes can have like a different type definition and um you don't want just one reducer like right now we've just seen one reducer for all these issues but now you want a different reducer when you think about authentication you don't want to want to manage this in the same function it gets hard to test you want to have some dedicated for managing dedicated parts of the state and for that you gotta register uh multiple reducers and um like if we go back to this one uh i think it's this one uh you can see that it's not just run one reducer in your in your state but it's uh multiple any any uh number you want what ngx will do is roll these up into one method we meta reducer basically so you can make out the outline here it's still a reducer funnel and we still throw in the whole state and uh any uh um any recent action but under the hood um each dedicated part of the state will go to a dedicated funnel in a dedicated reducer so this one would be could be our authentication state a reducer this one could be our issue tracker to-do list reducing and both just get the part of the state they're interested in and they both get the same action then they can decide to produce a new state or just return the the one they had when they don't really care for the event like uh the issue list wouldn't really care for um any login related events right um but at the same time this pattern allows you to change this without changing the whole architecture without recoupling your multiple state services so um when you now see all right we don't want to just display any to-do's when there's no one locked in you can just change this based on the action um maybe that's not the best example but um and you need to we can go into the code right now in order to see how these are actually registered but the basis is you you provide different keys for these different parts of the state and then you can say all right please use this function for this part of the state and please use that function for another part um i've got i've got a another slide for that because oh yeah this one um because in angular you've got modules right and maybe you've got even that lazy loaded model so if your application's getting really bad a big e1 don't want to have all modules loaded at the same time and with global state you think that you need to have all of the state running when any part of the state is needed but this isn't actually the case you can build up your um store and your state incrementally like you can have your root state you've seen this interfere interface in the in the in the in the um code and then we could have this triangle for the authentication state and the to-do list because our application is like issued issue tracker to lose um i've thrown these words around a lot sorry for that um so we want to have these available others all the time but now at some point uh we want additional feature states and we can reference them by a key so these are reference to this one put into maybe authentication and for this one you've seen this basic property selector where i'm mapping the root state to the issue property and i could do this easily because the issue property was defined in the root state but you can even lazily attach these um to the state and build up your feature root state which would only be available in a dedicated module so um this is supposed to be like um how do you call it a little gear icon for settings uh so our issue tracker would now have module for managing settings where you could say all right notify me when any issue is resolved that has a priority of high you don't want to have that running all the time maybe you only want to have that running for dedicated people dedicated roles so that's something for uh for a lazy load and feature module and um didn't plan for that but maybe we can find it in the code too should be in here too yeah so i've got this module settings it's different from the store so in the actual store uh directory you're not forced to use these directory structures but in the book i'm i'm introducing some structures which are good baseline i think there are different opinions on that like most of the stuff i'm talking about there are different opinions uh don't take take my word here for granted but i'm organizing the the state that's available all the time in this in the store directory there i can put um a folder for any any any slice of my state that's supposed to be available all this time all the time and then in this index ts file i'm building up the root state and this root state has this issue property where i'll have the issue state and then i can map all parts of the of the state our properties to dedicate the reducer the dedicated issue reducer would be the one we've seen in the indie file before where we've handled the submit success action and then we tell uh ngx by mapping um every part of our root state to a reducer um that it should use this reducer for this part of the state and this is where we register any meta reducers and um we pass this information to ngx by registering registering the reduces with the store module so this is actually where nga starts you import the store module in your angular imports means we're talking about the root state this is supposed to be available everywhere in the application and there we pass these uh this these reducers which are supposed to handle one property like the issue property and we could put put more um reducers into this map like we could put a reducer for managing the authentication state but we can also lazily add these um like we've seen in the illustration a second ago this is what i'm doing for the settings module so this is another angular model i'm lazy loading the this one through the angular router and in the um in the settings in the settings uh module i i'll have another directory called store and i'm doing all the same things actually there i'm having multiple um multiple slices of features data at this point uh too and then i can say all right i've got this additional setting state and the setting state has apart from notifications i can set the priority for being notified or i can maybe update my profile with a nice little picture or something like that and then i can have make up this mapping again and tell njx all right under these parts of the state with these dedicated reducers which you'll find in these directories over here um you can actually access all of this code even for free the repositories up on github don't even have to get the book you can go through the commits uh and the demos if you want to and then i'm telling ngx to uh i'm actually just building up a constant here so both of these slices i want to manage under the settings key and then i'm i'm just doing some typing so this is ngx related but uh just for a nice typing approach i found that you can extend the root state and say all right we've got this extended root state so while the settings module is running we know that an additional property will be available that's the settings property and then we build up this this new state where we know all right the settings feature key will lead us to the extended um it will lead to the setting state with these two slices and we can attach these so what happens then when we go into the settings module we again start up the store module but don't call for root we call for feature because we want to add a feature and we pass this feature key from before so this would be just a string that evaluates to settings and we pass this buildup reducer which can now manage the whole setting state part now if we were to take a look into the death tools again i'll try finding them now because this one is interesting then i'll move this one over here and um all right just gotta find the art instance maybe it's that one uh we'll see um but in the dev tools you can actually see what your state looks like so at this point it's just an object which has this issue property and inside issues we've got the the dictionary for um also all parts of the um for entities of the issue list and we've got the filter for managing the text and some property that tells us that the issues have been loaded or not loaded from the back end and we don't see the settings key at that point but if we were now to navigate to um the settings module uh through this link above here you can see that um it will be added to the state if i find the right instances let us find this one yeah here it is you see that um there's actually now a settings property which hasn't been there before i clicked and just find the right instance here and there's now these uh additional property properties for the notification and profile state both under the settings um settings uh feature state so we can actually do uh two separations we can have these dedicated reduces for each slice of state and we can have even lazy loaded feature state which would be the whole settings part and we can even slice this one up into separate states so this would the settings would be this gear from the illustration and notifications would be like a little bell-shaped inside settings and profile would be like a little little icon for the profile state and this is the way how you can build up your state incrementally combine it with lazy loaded routing and still benefit from the ngx principles and global state in general and you can even combine these states through it's selectors so let's take few questions and then i think we are already above the time so uh sebastian has this question one thing that i have had trouble with is creating an effect that react to different action types each having specific payloads and getting proper type interface for each action type uh i i mean this is like more of a typing question but are you able to anyways solve this issue using effects um so you get the type infuriance from the off type operator so i'll just jump around here um i hope this is comprehensible afterwards but uh if we have a look at this one where we submitted the issue to the back end oh we can we could actually pass multiple types here to the of type operator so this is probably what sebastian is referring to but his answer is more on let's say we submit sub uh we have two types yes submit let's say reset and both having different payload signature yeah that would be the um the origin uh our point of departure and um the action down here like just for everyone who isn't too familiar is type based on the based on the type uh you pass to of type so ngx has done like phenomenal work here to infer the type you don't have to tell uh typescript what kind of action you're expecting it's all inferred from the action creator which we haven't taken a look at here but um you could pass multiple so that's what what you're just referring to like maybe we have a different form at a different point in our application where you can also submit um issues and you want to have two actions for this at that point it gets out because uh i've had these situations but i think most of the time they had some overlap in what i was expecting because uh what ngx would have to do is create some kind of um union type where it says it's either this action or it's that action because it it can't guarantee that it's either one uh so what you probably want to do is um correlate these payloads so if in one payload there's your issue um and and you've got another submission action like uh maybe editing action and it uses the same effect which maybe you don't want to do in in hindsight uh when we think back to elise's uh question but uh so this could solve your problem already but if you still want to have one effect um you need to have some overlap in the properties you want to use or do some type assertions in order to figure out what you're dealing with i think these are the only solutions correct me sometimes you are if i'm wrong so i think this is what uh sebastian also agrees with all right perfect cool uh so uh in case i mean i missed some question you can all always get in touch with nils so nils uh has this twitter handle available here and underscore melhan and uh you can send him question on his dm probably uh that will be the best way uh because we are already past the time which we have alerted and uh thanks a lot nils i'm in uh that was really uh great i would say we discussed a lot of things and now let's talk a little bit about your book so uh what your book is for whom and what are the things which we have covered um um the book is actually uh for anyone who wants to get into ngx for anyone who wants to get started but um like you can you can also get started based on the docs so uh the docs are great studying product i don't want to say you you need this book to get started but um things get a bit tricky when you want to do advanced stuff and there isn't too much information out there and i think the book provides a good baseline for building up applications uh based on uh red on the reddit's principles and how to do um like there isn't even like what we see right now um organizing feature state uh that's something uh which i had to do by a trial and error and in the book i'm laying down uh like you can type it like this and you'll be fine i'm also discussing some patterns so you can even if you still uh already using njx i think it's it's a good resource for um for uh like validating your architecture and uh planning new features uh and i think in general because ngx is really based on rxjs there's also um like if you just want to see some ixjs go have a look if you just want to see uh i think there's also some performance tips in there which you can use if you're working with angular and you might which is something i'm i'm uh keen to point out you might not uh need njx there's a great talk by mike ryan co-creator of njx um the book is actually um like rich with references to the whole ngix team and anyone who's doing work around them because uh definitely not at all alone in that space um they're great resources and i'm collecting them throughout the book and talk on you might not need ngx so um but um so you've got to carefully evaluate if you need this approach but um i think it's still good to have this in your tool belt and to know that you might not need it um is a bit better than don't knowing what it is and just dismissing it i think this gives you a good overview in the first chapters cool so uh where we can actually buy your book and can is this the link which i have shared is that correctly meaning yes that's uh the perfect link i think you can find it through google you can also go to my um to my website which is near mirhan.de where you can also find free some free resources on njx i've written an article on how to implement the ngx store in 20 lines of code just demystified this all part and i'm also just i've published a chapter on from the book on the blog um where i'm exploring how to store your state in the local storage so this is available for free i've just put out a new um blog article based on uh uh how you can uh guarantee that your state is serializable so you can easily store it into locked storage and make sure that the dev tools are working so there's a lot of space to cover but uh yeah you can get get the book for the the complete resource and follow my blog for more topics uh thanks a lot nils thanks for sharing this and thanks for writing this book i think this will be really helpful for a lot of developers out there and it takes a lot of energy to write a book i know that so i have i have like done it for two months which i couldn't complete but i know how much effort it takes yeah so anything you want to promote apart from your book on uh here so we already promoted the book but in case you have anything else to share with us you can oh uh even more than that yeah like you can go to my website um ebook is like the centerpiece uh of uh put out recently uh again uh thanks for having me so much and letting me show that uh apart from that um you can check out the graphics editor which uh most of um learnings from the book are based on that will be scene lab or you can check out um like i'm building these uh little software as a service project and right now i'm going to into microsoft teams apps so if this is something for you you might want to have a look at um and follow my um newsletter in order to get information on on how i'm building little products in there and uh the general way i'm getting informed on on text so i'm always trying to share this with the newsletter oh this is cool so i'll share that link as well i'm uh so i'll update all these links in description and so everyone can refer it uh so yeah so anything else nails you want to share with us oh i think i've uh over shared a lot uh i don't think i've got anything on my list thank you so much for doing this uh show it's it's incredible and uh it's uh what's really nice uh of you uh to have me thank you so much thanks for joining me so uh i mean of course this is uh this is the second last episode which we had for this year tomorrow we have another episode and that will be on angular so in case you are interested to know about the new features or a few more things about angular please join us tomorrow same time 10 pm ist and we will have aris who is a google developer expert will be joining us tomorrow and uh yeah that's it for today so see you bye bye everyone and thanks for actually joining us like bye just

Channel: Tech Talks With Santosh

Views: 563

Keywords: ngrx, angular, state management, redux, flux

Id: DhgbolCd2_E

Length: 107min 12sec (6432 seconds)

Published: Mon Dec 21 2020