AngularAir - NgRx Book with Nils Mehlhorn

hey what's going on welcome to another episode of angular air i'm your host justin and on today's episode we are going to be talking about a new book a new book on ngrx called the ngrx book looking forward to it so let's say hi to our panelists then we'll meet our guest and then we'll get into the content joining us today we have mike mike what's going on not too much just uh hanging out on another friday all right nice i'm glad you're hanging out with us so that that's always good alyssa what's going on i'm so excited first of all to meet neil's and have them on the show today and i totally just spoiled that one again we're like not even going to worry about that anymore we're just we're good we're good thank you beautiful man but we do have a new rule like if if you do name the guests before we get to the guest you're the one that gets to introduce them so i would like to welcome to the stage the very kind and most wonderful niels who is above me oh i'm above you yeah thanks thanks for spoiling me thanks for the nice introduction there listen yeah thanks so much for having me uh such a such a nice uh uh show such a lovely people here yeah we're excited to have you on hey so do you want to uh maybe tell our viewers a bit about yourself uh those that might not know you yeah sure um freelance software engineer um like i'm doing a couple of different stuff um like in in on the software engineering part i'm working with types to it a lot of angular njx too um then i'm also developing some back-end stuff with java or nowadays or awesome with typescript node.js and um like i use these technologies in like when i'm doing consulting but i'm also starting some uh like i'm doing uh indie hacking like developing little products here and then that's also been a great inspiration for for the uh book you already mentioned and um yeah i'm doing blogging like uh since two years uh mostly on angular i think i never really got away from angular on the blogging part and i'm also doing uh speaking um like different talks i think they're all also on javascript answer now i gotta gotta broaden the area over there but uh angular's been a favorite uh topic of mine and that's why i've uh done a whole book about like state management in angular that'll be about yeah very nice do you find yourself um gravitating towards front end stuff or do you have like this desire to do kind of at all uh kind of gravitating towards front and stuff like what you see of me on the on the web i guess but um like i like to do um like the full stick development it's kind of kind of bad work nowadays but i like i just like the idea of doing everything like you can develop a whole product by yourself and nowadays it's so nice when you can do a full stack of development with one language i just really enjoyed that so um recently i've developed a product in like two months with a full stack type script and i i just like the idea of that but yeah different projects different uh technology and um uh recently it's been been a lot of fun and stuff with which i really enjoy nice very nice yeah i i kind of in the same boat i like doing all the things right but i really enjoy the front end part because of the visual aspect of taking logical programming and and then being able to translate that and do something visual along with it and tie those two together it's always been a draw the front end part um very cool hey i've got a question for you because you uh just i'm just out of curiosity so you got this white board behind you right and you have it in a vertical layout versus a horizontal so i want to kind of get a pull from all everybody who's on here like is that like a developer mindset that you think in terms of your code going vertical so you want your whiteboard vertical because i think that's how i do too i put my whiteboards vertical because maybe i'm into code and programming what do you think my husband's white board is is vertical is exactly like nils so that's i've never thought of aren't they meant to be vertical i don't know like pages are vertical so you're right from the top to the bottom it's just outside of this conversation i've only ever seen them like long ways like teacher teacher style right like you're in a classroom yeah i have probably i have to give two answers um i actually prefer mine horizontal because i'm not typically not writing out code i'm more so writing out flows and diagrams uh to see how different pieces will fit together so that's how i would i typically have oriented mine and but at the same time my real answer is neither only because the whiteboard that i have which is technically a piece of glass is square so there is no uh correct or incorrect orientation i've gotta admit i i fully expected you to say i want mine diagonal yeah yeah or like rainbow diamond with my square one but i only write in arches you know like something weird so i've been using this one mostly uh like you can see for to-do lists so it's like a cheap uh way of keeping to do this instead of having like a numerous pieces of paper and so like the second one would be for boxes have you heard a rocket book rocket book i my birthday was this week and my uh got me i used to think that all the valentine's decorations was for me as a little kid because i have a birthday right right after valentine's but rocketbook is so cool and it actually works with whiteboards too i think they sell little like qr codes and you essentially you scan it and it's set up with an app so that it can go to like any destination like your email dropbox where it's got a ton of destinations but um you you scan it and then it either it turns into like a pdf or like a gif even of like like a progressive thing like if you have a list of notes and it's like growing but it's really cool because they do whiteboards too and so it's like categorizing and sending it out to the cloud so i don't know i'm excited i'm trying it out and uh i i wanted to like shout out to that since we're talking about whiteboards and like you're saying like reusable environmental friendly notes so yeah and maybe that could help me set up some reminders because i think i think most of these are actually ideas for blog posts or like talks and then it could remind me to like do this and uh not just keep it on the whiteboard i wipe it away anymore those kind of ideas always come to me in bed never when i'm near a white board and i'm like oh that's a perfect one i'm like writing it on my face yours happened during the what'd you say mike you could put a white board next to your bed or potentially here's a here's an idea that just came to me get a larger one and it could be your headboard for the bed and that's why all you have to do is just it's just yeah and then any guests that i have think i've absolutely lost it you know they're just that wouldn't really work for me because i toss in my sleep so i think my head would just erase all the ideas that were on the headboard i don't know oh good okay sorry we totally derailed and i really read about this book so niels should i take it away oh yeah like i've prepared uh some slides on whiteboards now so uh i think uh no just uh let's get into this is your book offered in the whiteboard platform can we get it on whiteboard yes you can only actually get it on whiteboard so i've handwritten it on a couple of whiteboards and if you if you order it you'll just get like a 100 whiteboards delivered to your front step yeah excellent it's a very expensive yes but it's uh i'd say it's worth it but no you are literally my new favorite person oh thank you for coming on okay i'm excited you tell us you tell us about the book all right uh can i share my screen somehow i don't know yeah i am already yeah perfect so i can bring this up so um just some facts about the book so um i've started with this indie hacking um project which maybe i can i can show some slides for that later but it's basically good graphics editor in the browser and i've started with this one with a good friend of mine and um state management was really hard for this so if you're developing your classic enterprise application uh you don't have to think about it that much at first i'd say but when you when you're trying to implement a um graphics tool in your browser you gotta think about state because of this a lot of state in the browser and uh so we naturally turned to njx like we've tried it without it but uh we needed something that had like an architecture fall of that and that's why we turned to ngx and so we developed this product and all of the learnings which i've got during this development went writing right into this book because during development like um i've uh like stumbled upon stumbled so many times and i uh looked up so much stuff and uh watched so many videos and uh like trial and error figured so much stuff out there i thought yeah i gotta i gotta write this down somehow and uh that's what the uh that's why the book came out and because this is an open source project and um i really like the idea of open source i thought uh i'd give a good bunch of this uh um away for free like back to the community so during pre-sale you could uh pay what you want for the book and that's like well i think over 500 people ordered it in the pre-sale and they could pay what they want so anyone could get it and still now if if you're a student or something you can reach out to me and i will figure something out and uh like it's it's 150 pages long and i've self-published it so i really wanted to have full control of it and get it ready when i'm ready and so decided to self-publish it and um i reached out to njx team members they reviewed it so i've got really really nice feedback on that one and um it has a bunch of links back to these background resources which i've initially mentioned so i think it's over 300 links like 360 or something to talks to different blog posts to um like other technologies you might want to look instead at instead so i really wanted to show what njx is good for but also provide you like all the background information and all uh the little considerations you might want to look into before getting into the technology or when you're already using it uh how to think about it and that's all in the book um so we could start off with the story about uh njx like you already you you're developing with angular and you're thinking um of using ngx so should i go ahead with that one yeah yeah beforehand um that it's not just a technical book um because i know documentation exists and what have you but the reasonings why and um the overall thought process is always good to include so thank you for uh not just focusing on the technical aspects yeah uh during writing this i really thought of writing this for myself or a bunch of people and i knew and i've also put in these little boxes here and there with little smiley faces telling you all right this stuff might be a bit difficult but you can go through this like all the argsjs part like you've talked with uh lamison last episode that's really powerful but it can get a bit heavy and um if you're already going through a learning phase there it might be a bit much so uh like i thought like i write this for myself so i need some motivation here and there since this is a digital book all those links that you mentioned they're all clickable from the book yeah that's awesome so while you're reading you can go to the subliminal material yeah one more point on that one it's also including um a whole example application like including every little section there so every little aspect of the framework is implemented and explored in one chapter and there's a little link with live demo which builds up um continuously throughout the book and um that's like over 40 steps i think and you can like have them in stack blitz like this perfect playground for angular apps and you can clear around and um explore it on your own so it's really interactive all right so the basic idea for nga so the basic story for coming towards njx it's a bit different like in in other frameworks and and here's actually why so if you've got your regular uh angular application it might look like this from from something i draw on a whiteboard right so uh it's this hierarchical uh component three where you've got this um this one component at the top which could be your app component and it has some local state right here like some title you want to change for um the top bar of your of your browser right and then you've got this chart component these chart components below so for different views inside your application you've got different components in order to keep everything maintainable right and these all might have local state they don't have to have it but most components do and um sometimes you even want to share state between components so on the left side you see this this like parent component which has some shared state and it can actually share state to different child components through these little io bindings here right so we've got uh angular already comes with uh with different tools for sharing state between different components like inside components you can manage states through class variables right properties and you can even get them towards other components by binding them through inputs and outputs so that's a really good measure to have and it's really helpful in a lot of situations um so the usual story would would start right here and if you think about a redux or the react world you'd usually just start right here and say all right if you've only got these input output bindings you have to turn towards redux because it's hard to share some state like from all over here towards all over here so with input output bindings you'd have to go all the way you'd have to go through this parent and you'd have to go through this one and then down to this one and you're finally ending up here right um but with angular the story goes a bit different so i really export this in the beginning of when writing this book what's the actual use case for njx like it's still different to put this into words but in angular you've you have this different aspect you've got already got services so that's something you might not have in different uh front-end frameworks you already got these injectable classes which you can use outside of the component hierarchy and this way you can have shared state which is independent of the view setup and this way we could share some state from here with a component over here without binding anything through these intermediate components so they don't have to like be concerned with any shared state that doesn't um concern them directly so this isn't really an argument for introducing ngrx to your application you can work with this right um if you go on and you find yourself in a situation where uh it's hard to um synchronize the component state with the shared state you've also got a tool that's coming with angular and that's arcs yes so um your service could not only have this shared state in some kind of property fields but because if it's only a property fields like you can bind it properly to components but if you want to introduce some intermediate steps it's a bit hard because you don't really know when does the shared state get changed and what you usually do is uh you use like stress um you introduce some kind of subject behavior subject or any kind of absorber because then then you get this um like this long-standing uh term here in software development it's called command query responsibility segregation really hard to pronounce i guess at least for me for short it's secure rs or just cqs and the idea is that you segregate commands and queries so the query would be the subscription to your observable you'd query some specific kind of shared state and your command would be invoking a method on your on your service and this way you can uh you have the separation and you get an explicit way uh to hook into when data changes so uh the observable you can pipe this through all these operators again last episode really dove deep into this one and um on the other hand you can issue commands to your servers like if you've got this user service which has to update some uh users you can you can create these users through some observable like that would be the top error here and if you want to change update some user you can command to the servers and this one can in turn uh set up some http call and on the view side you can easily uh translate these two to some render call in the view and you can like have some triggers for that and it also gives you already performance benefits like the on push change detection all right um so we're still not kind of there right we still don't really see the need for ngix and the problem is this thing so i can maybe win a bit of of rails here but uh just to show the idea uh i think there are probably projects that look like this in theory so um i don't know if this fits on my vertical whiteboard still but um if you introduce all these kinds of services uh with share state and if you got this uh command query segreg uh responsibility segregation principle then uh you can work with it like it's something many people use in angular projects to scale up the architecture to share state and it works quite fine um so we'd have all these kinds of services like the top one could be still our user service and then we've got this authentication service which is keeping the current user and then we've got some domain data in here and some domain data in here and usually all all data we manage in an application is a codependent um if you change one piece you get a you probably got a notify some some other piece and um then you gotta issue another http request and uh it gets messy especially with async tasks so i've introduced these little little circles here i know i i noticed the loop for async yeah that was that was nice there's no real sign for that yeah so you make this round trip again and then you gotta see all right when when this round tube is done i gotta tell this service it works fine so uh but uh as you see it kind of gets messy you kind of lose these this brought a perspective on on on your state your state gets like fragmented it's all over the place which isn't like totally a bad thing if you like this the first piece i've linked in the book it's um the actor model so there's also some some work on keeping this organized but uh njx is kinda um solution currently to um untangling this mess um in angular applications it's not the only solution that's that's where my point is so how do we untangle this uh we just say we don't have all these different services we just have one we don't have a couple services that share states so we just have one that contains all the global states so there's a difference there we just say all this shared state is global state now so um it doesn't get entangled and um like it looks a lot cleaner right now and we still have this segregation right something changed here we don't have commands anymore we now have events but we can still push data from the service to components through rxjs like queries subscriptions right and this way we can clean a lot of things up and uh like one part of the idea of the last step of this idea like the first step would be having services the next step would be the segregation of command and query and the last step is now all right we don't have these different actors we just have one global state which is kind of a workaround but works really real really well for many people and we've also replaced the commands with events so instead of telling some service to do something explicitly we rather say all right this happened maybe this needs to um result in a state change but the component doesn't really know it doesn't force the uh state change service has full control of it and it's really nice for traceability purposes so we've got this global state and this global event bus um like that's also backend topic um that if anyone is coming from that part and makes things a lot easier so is this model not possible without ngrx it's definitely possible without ngx but probably what you would be end up doing was would be um re-implementing ngx right so this idea is what um it isn't like an unique idea for njx um still many unique great ideas went into that library but um the basic underlying principle would be redux right so that's what the uh like the pattern is initially called flux and sometimes it's called red x but the big library in that space is redux but the underlying pattern actually emerged in many different ways people work in different languages also arrived at this pattern because it made things so much more easier because you have these two indirections you you split uh the command of changing state from a current state and the next one would be that you generally do this little cop out where you place shared state with one global state and have this um have components on your report what's happening and that's really um something many people ended up and i think the engineers at firebase like correct me on this one but i i think this is how how it went down um like the engine is working on on at google on firebase they saw themselves ending up at the uh that's this pattern and then they implemented ngx basically um all right it also allows for uh um centralization and organization of all your logic in one place as well uh separate uh definitely separate from how it's being presented yeah so that's something people always drive towards i think in angular so you have these different um services uh where you um just factor out all the state part and then you have have components separated from this um and it's like the next the next uh i wouldn't say the next level so it isn't like a natural progression you don't need this this either way but like if you think back if you're implementing a graphics editor on on your um in your browser and it has to run all uh everything has to run on the client side you've got a lot of state and it can change from a lot of different places so all these components you see here that can dispatch events and um you just want to have one place where you really say all right this would be the next state then yeah exactly and then to eliza's point of can you do this without ngrx and that's more of it can we brought up to like a higher level that of course you can but the reason why you bring in libraries is that so you don't have to implement common logic around different things so i always bring up the point of always think critically of the different dependencies that you're bringing in and figure out what need that library may be solving for you and your application um definitely so uh in the in the book once i'm done with this introduction i'll mention uh these different labels which which i can mention now um in the angler space i think uh what got really big recently is called akita um i haven't tried this um myself but it looks really nice and there you don't have this uh second interaction like you have um predefined ways of managing state like mike just said it's something you always use and you want to have it implemented once nicely and just pull it in but you don't have this in direction where you use events so you don't you don't have this global event bus it makes makes things um different i i i was tempted to say easier there but um you you're more coupled to the state management like you would be if you just have this event connection to the state um but if you don't really need this decoupling here um you might be better off with that one yeah i think that's one element that gets kind of the the part that's still up in the air of a solution for where you you have something like you mentioned which you have this decoupling of these events right that happen with ngrx but to have a mental model or a confirmation of this flow happens in a certain way right it's because they're all independent you get that power with it but then you also have this challenge of like how do i orchestrate a known structure and then how do i mentally understand that how can i conceptually grasp like what's going on throughout the application in terms of business logic and and so yeah but different tools different things right tools might be a really good um point here because i think a lot of uh arguments in the in this discussion are based on what tools are available so i think some patents aren't just just not that popular because the tooling around them isn't as good and the tooling around njx or redux is really nice because um it's like the standardized pattern you can say you can always say everything is in the global state and you know how the state changes and uh this makes it easy to plug in stuff on top like the red x dev tools you can use them with ngix and you have this little browser plugin where you can do what you just mentioned you can follow this stream of what happened to my state and it would be really nice if you could integrate this with other approaches um so this is currently a plus for ngx but um yeah i think there's still room going forward in this kind of solution space yeah um so we can could talk about um how this is really implemented so the idea is clear i think we've got this global service where we store the state and you can push events to this service and then the state with some more update but how does it really update this is like shown here now we've got these um words with which might be a bit intimidating at first but um i'll try to explain in really simple terms here um so the um this global service which has all this global state in it that's what's called the ngx store or it's it's also called stone many other frameworks so if you're coming from different background um it's the same thing it's this box where you have the current state it contains the current global state um and this state doesn't change so it's immutable um just means you can't and can't just uh change it right away because that would break some some of these um principles we've seen before you don't want to just mutate the state because components should know when the state updates so you just if you think about rxjs you wouldn't mutate the current state you just push a new one through the observable so the store at the same point is also unobservable containing the current state and every time a new state gets computed it will push this new state to your component so that's the the update update part over here so that would be the decree part of our command and query um segregation and the component can then dispatch events over here and events are called actions and ndx i think that's just traditionally because it's really good to have in mind that these are events so they shouldn't shouldn't be like commands they shouldn't tell the storm what to do instead the store knows what to do because it has this funnel this reducer which is just a function it's just a function accepting two parameters the current state and this event slash action right um and it doesn't mutate the state but um from this information it gets like what's currently in the state and what has been um dispatched from the conv component like there could be some information in there what what happened in the application like did someone click a button or did some http request turn up with the result that could be then incorporated into the next state which we see down here and the reduce is doing this not by mutating this state but by computing a completely new state object and the store will do this anytime an action comes into the store and then it will push out the state through an underlying arc just observable to any component that is subscribed to the storm so the last time i really tried to get behind in grx and really wrap my head around it and use it everything that you just said i was like i got it i'm cool but then you've got the stuff i'll say that i'll say the e word the effect on the outside of your box there and that is where i i was like i give up on life so i'm really excited to see how you explain this next bit because it's like the scariest part ah thanks for the um like uh introduction to that part i i'll do my best now uh so let's get to the stuff um so uh if you imagine this part on the right side gone at this point um it's already like the redux principle um it's self-contained the effects are just it doesn't really um it doesn't really belong to the store idea it's actually also two separate packages in ngx for that reason because you can use this principle already in your application you don't have to introduce this one um the basic idea is just um from somewhere actions come in can come into our store and at that point the store will will invoke the reducer which we which we code ourselves it's like this this switch case statement where you say all right action types uh xyz then compute the next set like this so this is the whole ngx principle and anything on top can just interface with what we have here so if you want to say that some kind of asynchronous thing happened you can tell it to the store by dispatching an action you can't communicate any other way with the store it's just by um dispatching an action to the store and then it will update the state nothing more there and um the thing is inside the reducer you can perform anything else than what i just mentioned you can't run observables you can't do anything asynchronously because it has to be synchronously and it can't reach outside of this box like it kind of actually reach outside of this funnel so it just has access to the state and the action now um this is hard because um there's no way of doing an http request now like we gotta fetch some data from the back end most applications have to do this right and in order to do this there's this um other library which would be called nginx effects and it's this formalization of um performing asynchronous stuff in conjunction with ngx like the store part and what it does is uh it grabs any action um after it went through the reducer funnels it through some effect and this effect can be asynchronous it's not inside the reducer it's not even in the store it can um go uh fetch something uh from the back end maybe through some service and this one again does the actual http call or whatever you want to do asynchronously and once that's done you just dispatch an action and that's the whole effect part um and the way you write this would be with plain plain xgs um so you have the observable where you um start with a stream of different actors that come into your store actually these this observable will only um put out the actions once they went through the store so you can be sure that the state is already updated and then you can do whatever you want based on an action like if the action says load something from the backend like load our users uh it can go off load these users and once once it's done it can communicate back to the store in form of a dispatched action and you describe this with this observable you base it off of the stream of all actions you like switch map merge map it over to some http call and once that gets back you map back to another action and ngx will subscribe to this observable for you and funnel all actions that come out of it back to the store and that's how we get this round here right an action triggers some effect you say all right uh actions of this type like log users will trigger this effect it will go off to the service the service will go off to some some place to fetch the users it'll go back and then it'll be dispatched a new action like lurk user success usually back to the store and we're done nothing changed actually over in the store parts it's just a formalization for um subscribing to existing actions doing some asynchronous stuff and funneling that bad back without touching any of this did that make the cut no it was beautiful i was beautiful yeah i'm so happy that you're describing it this way and presenting it this way because i think that this is something i see a lot as people are going through and trying to figure this stuff out in the state management things like that is like i think there's a lot of impression that people think that the effect is the effects are part of this bundle and we have to have it and it's part of the thing if we're doing um global state then effects are part of the equation but they're a utility right and like you called out the stuff in the left and the middle that's about the the state and the global state and the redux in that pattern right and like hans in our comments in our chat comments mentioned uh effects are really when you leave the flux flow and run a server request and come back into the flux flow right so you think about all these things like just like you described the left in the middle is all about our state management and the right is just a utility to help us broker something whether you do effects whether you have some other solution that does that maybe it's a combination of both ultimately it's another way to kind of get stuff in and broker things to your state yeah so that's what uh we found so nice about um this approach because everything on the left or in the middle like whatever you want to call it stays so untouched the ideas stay untouched and we can still reap all the benefits uh but we can also do http requests somewhere else so for our graphics tool it was really nice to have um this one source of truth this one place where we know all right this is the um this is the state for our current like uh canvas like our current tooling every different component can subscribe to that and it will always show the right state and we can trace every change to the state um this is something that allows you to uh like use these nice dev tools you can install in your browser or what we did was um uh we developed an under radio feature like you wanna press ctrl z and uh undo something that's something you need in any kind of sophisticated tool nowadays because people expect it and if you have this uh always these different parts of state available you can go back and forth through each of them and this is all thanks to this like formalization the the idea of having reduces that don't mutate the state but always produce a new one yeah i'm like loving this explanation and the chat is only adding to it and uh mike even has alternate names for effect and reducer and i think i think that's that's an idea you know maybe an additional library on top to just change those names right out like it's just more commonly used english names that's all rather than specific names that fit directly into the pattern i think that helps people understand the concept more if you think of like the relationship between dispatch and an action dispatch is a messenger and the action is a message um the reducer is just something that does changes so changer and effect is kind of functions like uh if this then that so hey something happened oh yeah i can go do something for you i'll let you know you can do something with that and then the state is just a way to store data so it's a database i don't know yes explain things in different words rather than say come on it's just an action what does that mean well it's just a message that hey i want you to do something and this is the thing i want you to do and here's the things that you need to be able to do that yeah really good um counterpart names i i'd say um that brings me to the point that um these pieces are mostly really basic javascript like what you just said what is an action and um it's just a plain old javascript object it's just something you'd um um it has a property um that tells it what kind of action it is and then you can attach some some plain javascript properties to that and a reducer function is just a plain function and the state is also just a plain javascript object so no magic there are no classes there um it's actually really crucial in order to gain some benefits like i've written a couple blog posts on that if um if you want to know why it's um crucial to keep this one uh and this one always plain and how to do this if you're coming from this like angular you're usually using classes for a lot of the building building blocks like components or classes services are classed but when you're dealing with ngx you get in this like functional programming part and you don't want to have classes for a couple of reasons like classes are fine for for probably a couple use cases but um at that point it's uh really beneficial to um have these all plain objects and plain functions just thinking more about like an action what an action actually is if you think about it it's a function just in a different format because functions have names and that's essentially the action name that you're trying to do and then the props that you're supplying are just parameters to that function yeah plus you don't really know what the function does so yeah it could it could do anything all right yeah it's almost like an abstract function and that it has no implementation it's just hey this is the thing that i want you to do and these are things that you need to be able to do it um so i'm not really seeing what what the next slide is right now so i gotta i gotta uh i gotta do this on the fly so this one showed up next uh what showed up i think it fits it fits nicely because you can see that you drop all these fun actions from all these different places like you click somewhere or your network returned this this response in form of an action and everything goes into the store and every time it comes in the store would spit out this new state in a little factory database factory all right again this is like just the focus part on on the reducer and um yeah let me check what's next up yeah you can combine a bunch of these like this might be a bit um a bit uh it's something you need in any application so i might as well get into it um like if your application goes bigger you've got this part for the for the users now and um you might want to have different you have different parts of your state like your application grows and you've got this part for users you've got this part for managing settings and you don't want to combine all of this into one global state because that's some a question i i uh encountered a couple of times uh like how do you get another nga store i want to manage some different data um how can i uh like do this the point is you always have just one store but you can have a bunch of reducers and you can have a bunch of actions and you can have just this one piece just this one state object but you can like have different slices of it and that's what this illustration is showing here so what you do is you have this this big box of state and in there like this triangle could represent your your user your user state and this might be your authentication state these might be some some builds that belong to some user over here and you want to manage them all differently like when the state updates there's a reducer for every every part of this and when any action comes in here you'll actually have this really big reducer but it consists of different smaller reduces and each one of them will get its specific uh slice of state it'll get the whole action and whether it wants to do something with that or not um that's the part where it's a bit different from from a function maybe like this would do someone do anything with this action if it's about um doing something to any any builds or something or the authentication state um because it's just about the the users the triangle users right and this one will produce a new new triangle state and the other ones might just keep the original one you can't see this here but they might um create a new one or just update uh just uh leave it as it is and then the store will combine them back into this whole new next state part and this way you can grow your application and really have it um separated and you can also work with a couple of people on on the same angular application because it's all following the same pattern if you keep the analogy of a database this is almost like tables in your database right and you you know the different features are different tables and then you use aggregate of all that data together it makes up your entire database or your state yeah really good analogy let me let me just have a quick look what's up next so i don't just wing them all the way okay we've got this um we've got the setup we we know the the pattern and uh now we want to access something from the store so we know that there's some point where we put actions towards the so we dispatch them we've maybe defined this uh how the state looks and types we can do this really well with interface or type definitions we do this at some point we define some actions and we'll maybe implement some reducer functions that will produce these new states just maybe a quick point on that one you can do it um like that's something maybe people in the angular 1 aren't too used to if you're using these kind of behavior subject services you might have already done it but um like when i first got into functional programming and i came from this class back on how i thought how uh i was thought uh how do i create new objects like if it gets really big i don't want to like do a deep copy that's bad and uh i don't want to um iterate through all the properties and create a new object that sounds really um like a big task just for managing my state so what you do is to use this uh the spread operator that you we've got for a couple years now and you just do a shallow copy of everything that's already in the state and then in this new object you've now created that has all the properties from before you overwrite the ones you want to change so if you've loaded the users from the backend you just copy the whole state using the spread operator like these three dots put them inside a new object decoration and then you put your new state on top and then you can spit out the new state just as easily there are even easier ways also covered in the book like this library image is just if that's also a bit uh like intimidating when you get into ngx um these functional programming concepts are pretty um nicely done nowadays in javascript all right and i think one of the nice things about this whole pattern and everything is like in to this point that you're bringing up is that there's this concept you have to kind of think about mutability and and not mutating your state and things like that but because it's isolated in the spot you can kind of work that over time or figure that out and know like that doesn't carry over to your components per se in terms of you solving that problem so whether you're like i want to implement emmer now or i want to solve that i i'd go dive into the reducer part and solve that there and everything else just remains the same because you know we don't have that code spread out in places we're really isolating where we do logic and pieces which makes it great for you know building over time yeah and also for testability which just occurred to me so if you've got this function where you can throw in a piece of state um and uh a new state comes out you can um throw something in that represents an action that could be coming from anywhere and uh you can assert this output of the reducer and you'll be fine that part will be tested and you can be sure that it always will work just the same way just because of these different um concepts in place all right uh i think we've got actions now we've got uh the state definition how you can bring these together with some some different reducers in order to scale things up and always put out a new state and we've slightly covered the effects i've got a slide for that two later but what we didn't do yet uh would be like showing that state to some component how do we get anything out of the store i've already mentioned you you'd create this and it's just um again just sorry for the just i know that alex observables rxjs observer was a bit hard to wrap your head around at the beginning so excuse excuse that part um but what you will do is you subscribe to this whole store but in most places you don't want to look at the whole store so you don't want to look at all users you just want to look at the currently locked in one it in order to display like in the top right corner like you're the logged in user and your name is like this right so you want to just have one property of the whole state and in order to keep this uh performant and reusable um ike's just really on your side and njx is also um has really nice tooling for this in form of selectors another term might maybe you've got a another nice counterpart to this one it's again it's really a function that accepts the whole state and spits out this smaller part of it on the right side and you can write it whatever way you want so i i'll i'll chime in with one uh because when i look at this whole idea of ngrx and taking a step back at what they are at a conceptual level again stepping away from the terms the state as i said is very much so like a database and if that paradigm actually carries out more so with other things um but a property selector would be in database terms and equivalent to either a view or just a select query but a view i think encapsulates that the similarities a little bit better i was gonna say that if you weren't gonna say that i was about to unmute and say the same thing yeah for that analogy i think it works you know for people coming from a database standpoint and and that knowledge like how do you wrap your head around this i think that's a good analogy for thinking about that is that is a view that you're saying like i want to use this reusable selector or view to have the data and under the hood with rxjs it'll ensure that like the right active current value is always coming through there but we can just say that give me this view yeah view would be really perfect because um what we can use it for is actually building up view models so um uh to have some more benefits of ngx it really helps to keep the store or your database normalized something you'd probably also do if you if you're developing an sql database or something like that and um but you don't want to display your state um mostly just how it's in the store so it could be a bit optimized in there so you don't have any like redundancies or something like that and um people um scratch that um you can you can use these selectors to um build up view models from this normalized state and this way you can uh even more decouple your actual state this can be optimized and non-redundant but you can build a view models to the selectors and they give you a view which continuously updates because it's it's an uh ix js observable and you always get the newest view model for your component you can bind that through the async pipe you can subscribe in your component that's up to you and then you can even put on the on push um change detection method from angular so that's something you get right on top there and this is the the simpler case but you can do even more stuff like um if you want to build up these view models you can use something that's called computed selectors so you have these property selectors that will like fetch some uh some part some part of the state like let's say this one is again the the um the users and um like this this block over here would be um the authentication state and now you want to display the currently locked end user on on the top right uh framerate and you have these different selectors you have one for fetching the triangle you have one for fetching the tilde square over here and then you want to then you want to combine combine them in order to have this view model which would be just uh one selector maybe uh one user maybe which you fetch based on who's currently logged in and you can do so with computed selectors like you could do this in a component you can subscribe to both of them or and combine them again there's probably an rxjs operator perfect for that but if you use these computed selectors you can provide another function it's got like a projector something you'd have in uh like any map call or um you you can put on arrows rx is streams and it will give you both um of the current uh the current state of the of both selectors like the property ones and you can combine them in ever which way you want um just make sure you don't use anything out of outside of that and then it will give you um like what you build out of it the view model and what ngx will do for these computed selectors is it will always look at whether these properties changed so when they didn't change it won't run this one again and this way you can have really optimized views because your view models would only uh really update and this way your views will only re-render when really something to the state changed so this might be a concern if you you've got everything in the global state so you'd have to update your views every time something changes even if it's if it is unrelated to uh what you're actually displaying but if you use these compute selectors you've got you get this this memoized view model it's like this is just the concept of all right um did anything change that i put in if it didn't i don't have to run this again and i got just get the output so you're basically trading um like uh storage for computation power right i say just save this somewhere the result and if it's the same input from the last time it'll be the same output another great thing about that is again kind of everything is that it isolates the the behavior and the logic in a certain spot right so like when we talk about this computed selector you could think in terms of like the component just cares about what came out of it right it's not your components like okay i'm ready to render this house on the right right but let's say over time it's like to build that computed thing now we need a third slice in order to evaluate something to figure it out well we update our selector we never have to go into our component to make any changes at that point because we pulled that logic out of the component right and put it into the selector and now we have this ability to adapt and change and meet you know logic need changes without disrupting or big changes to our components because when you talk about the store in the very beginning and you you allude to the fact that like then this thing can be used in multiple components across the component tree so now you're like i don't want each component to have to be the one that wires these two together if they all use the same selector now they all benefit from the logic change right definitely and if you think back to the beginning and again to this uh i've named the picture i think the fire named itself is soup so this like messy part where every every service collided with each other if you want to introduce the uh like third part of the state it you it would usually be like in another service and so you'd have again like just one more arrow you'd have to drop a key on your whiteboard between two different uh services and everything would get even more messy and here you'd um basically adjust your selector to include one more property and you're done your viewmodel stays the same component doesn't care all right we've got selectors uh maybe we can go back to effects for the last part here if i if i find the slide again it's the next one perfect oh you mean database triggers oh sorry our database triggers yeah we can introduce more names here uh so there's this uh little circle again for the async http request we've got these actions which are um messages which uh use yeah or functions whatever you want to call them like little events i think the event method was really nice there's a nice talk by mike ryan co-creator of ngx really emphasizing the idea of referring to actions as events so because this helps you in maintaining everything because um if you really name it like um like what should be happening based on that it's really hard to add additional stuff later on but if you just say what happened it's really nice to layer effects on that and maybe catch the action in one more reducer which is something um you might as well really it happens later on that you say right and now i need this uh in in a different part and um you don't have to change anything else just catch this action as well and you're done and if we start off without with one action we've got this the stream which you get from the ngix effect effects package which will like i've said uh emit any action that runs through the store so once it's done um uh changing the state the new state is emitted it'll go uh through your observable and you've might define you might have to find your effect and this is what it looked like looks like like on a conceptual level um and based off of this submit action you might go out and switch map merge map conquer map whatever makes it make sense at that point usually it's merge map so if we say we'll update a user we want every action to have an effect on the backend no matter at what point it's uh starting or at what point it's uh done doing this http request so just this little circle something that goes on in the background doesn't concern the actual store once once it's done uh updating our actual database in the back end which we're just mimicking on on the client side here um we've got this these uh callback functions from any any observable like on next like the first one you pass to subscribe or on error the first the the second one you pass to subscribe um you don't really have to subscribe when you're defining the effect that will be done by um ngx for you but you can you can tell ngax what's in the stream once this one is done through like rxjs map or catch error and you can return these different actions at that point you'll create new actions in order to have new events in order to communicate what happened uh with this http request and this submit success might contain a reference to the user that was updated and at that point you can update it in the store if you're doing like pessimistically if you're approaching it pessimistically you say all right i don't only want to um display changes which are um already persisted to your database then you can use this to update your state at that point or if you already updated this data at that point you might want to emit a submit failure if it didn't happen and then you can roll it back like you can undo the changes um from before and say right just set this user like it was before because i couldn't pass this to the database um yeah that's the basic concept of effects right there um yeah and what you can do based of these is a bunch of more stuff like i've exported these different patterns in um in in the book like i i won't really go too deep into these but um you can start out by uh having different container and presentational components that's something you always always have in angular and you can really connect this good to njx but it's a bit separated from this but i explored it in combination where you only select from the store and container components and then you have these reusable presentation components and this way you don't really couple all your application to njx and then you can like swap it out or you don't have to use ngx in all of the places these kind of considerations and the next one like excuse me for going through this so quick but i think we can just have a glance and you can also introduce facets which is something that's been around um i'll argue a bit against it in the book but it's something i'd like to mention where you don't really have components connected to the store but you introduce these these facets in the middle which i'm i'm personally not a big fan of um like i think it's a bit uh too much to go into this in in detail here but um basically i think this this one is enough if you really want to have these two indirections it undoes a bit of what you what you get from the actual store so forgive me if this is a bit uh out of out of reach and out of scope no worries totally another episode content for sure and we've had some discussion on we've had an episode on facades too so yeah yeah so that's something uh that really helped us uh develop this this graphics editor maybe i can i can just give you a quick idea of how that can look in the in the end uh like something like this it's it's a mock-up tool where you um can drag your mock-ups of your applications uh websites whatever into devices and it will update uh like these mock-up uh elements with your um imagery and everything you've seen there you see everything that's in the middle is represented by the whole state in ngx there's a whole state slide it's just representing this um this whole canvas hierarchy this view hierarchy and inside of these mock-up elements you've got the whole thing again which you have all of these stuff has to be kept in sync you've got all these different events where you can drag stuff around you can drag stuff over other other elements and then you've got these different components on the right so there's a lot of going on you've got a lot of places where events can come from and it really helps to have this architecture that we explored in the beginning so that's something i want to emphasize again if you're building something like this you might want to take a look at njx you can recolor them in the application so this one is originally wide i think it was an incredible walk through for me personally for ngrx so i just wanted to thank you so much niels for doing this it was awesome and i i just think it was such a cool preview of your book so i'm excited to go and get a copy and i i just feel very humbled to be a part of this walkthrough so thank you niels yeah my pleasure thank you so much for having me yeah it's been great great all right well let's wrap things up um i guess we're at top the hour so uh but before we do picks any last thing meals in terms of the book and everything uh well i've uh put up this slide again you can find the book at uh at the url listed there gum dot co slash angular dash ngx dash book um you can you can read my blog i've i've got um a blog post which might really be interesting for people um uh getting into the concepts where i re-implement the whole nga store plus effects uh in a couple of lines like i think it's 20 lines and if you know angular and bit rx js you can really uh see that there's no magic and i think this one's really helpful awesome awesome all right well i'm going to leave this slide up here real quick like check if our panelists our panels have any picks no picks today all right all right that works all right so we're all going to pick the book justin you never get asked do you have any pics there buddy no no okay i'm siding with our panelists today thanks though yeah picking the pick in the book so for sure all right and thank you chat was fun today yeah chat was awesome chad had some great comments and good inspiration for sure but niels thanks a ton alyssa put it very well uh we really appreciate you coming on uh taking your time to share this content with us and present it to us and also for writing this book and all this great stuff thank you very much anytime my pleasure thanks for having me having me again for sure for sure all right that's wrap everyone have a good one catch you next time bye

Channel: AngularAir

Views: 761

Keywords:

Id: yh-77lwREP4

Length: 64min 50sec (3890 seconds)

Published: Fri Feb 19 2021