1 00:00:06,599 --> 00:00:11,599 Hello, everyone, Welcome to Adventures and Angler, the podcast where you keep 2 00:00:11,599 --> 00:00:16,399 you updated on all things Anglar related. This show is produced by two companies, 3 00:00:16,480 --> 00:00:20,039 Top Anddves and Onvoid. Top and Doves is where we create Top and 4 00:00:20,079 --> 00:00:24,800 Doves to get top and pay and recognition while working on interesting problems and making 5 00:00:24,839 --> 00:00:31,120 meaningful community contributions. And Onvoid, which provides remote design and software development services 6 00:00:31,120 --> 00:00:36,640 on a performance basis, so clients only pay when tasks are delivered and approved. 7 00:00:37,119 --> 00:00:42,520 In today's episode, we will talk about NNGRX version seventeen, which, 8 00:00:42,600 --> 00:00:48,640 by the way, introduces a fully signal based store. My name is Lucas 9 00:00:48,679 --> 00:00:52,439 Paganini. I'm the founder of Onvoid and your host in a podcast, and 10 00:00:52,560 --> 00:01:00,359 joining me in today's episode is Arman Vardanian. Hey everyone, Subrette, Hello, 11 00:01:02,560 --> 00:01:08,560 All right, let's get to it. So Aarman, I understand that 12 00:01:08,640 --> 00:01:14,159 you read a lot about this new version of engr X seventeen, so let's 13 00:01:14,200 --> 00:01:18,719 just start with a brief introduction of what's new. So what are the most 14 00:01:18,840 --> 00:01:23,799 relevant changes in this new version of enngurr X. I didn't only read a 15 00:01:23,799 --> 00:01:27,599 lot about this, I also wrote a lot. I wrote a small application. 16 00:01:29,120 --> 00:01:34,319 Actually, I made a Twitter thread on this, I want to just 17 00:01:34,760 --> 00:01:40,680 you know, cope, paste the link here. Okay, let's put it 18 00:01:40,719 --> 00:01:44,120 in the comments, because it has all the source code on which I've tried 19 00:01:44,200 --> 00:01:48,040 out. So what I did was I used the new Signal Store to build 20 00:01:48,079 --> 00:01:53,799 a well, you know, to do least application. I find it, 21 00:01:53,840 --> 00:01:59,959 you know, remarkably easy to you know, get yourself familiar with in ste 22 00:02:00,120 --> 00:02:05,319 up by building such a sort of application because it sort of has everything that 23 00:02:05,519 --> 00:02:07,960 we needed. It has you know, lists of data, it has htpicles, 24 00:02:08,039 --> 00:02:14,759 it has modifications and so on. So yeah, I'm pretty impressed. 25 00:02:15,960 --> 00:02:23,639 This is a really big step. In NNGRXB sixteen, the NJRX team introduced 26 00:02:23,680 --> 00:02:30,560 signals overall, so you could not only just select data from the store as 27 00:02:30,599 --> 00:02:35,319 observable, but you had the select method. It's always returned the observable of 28 00:02:35,599 --> 00:02:40,039 whatever data you are selecting. You could also now select the data as signals. 29 00:02:40,039 --> 00:02:44,639 There's a select signal method, So in the end of the day, 30 00:02:44,680 --> 00:02:47,199 even if you don't like the Signal Store, but you want to have signals, 31 00:02:47,879 --> 00:02:54,280 you can continue using NJRX store the conventional store which select signals. So 32 00:02:54,360 --> 00:03:00,240 that was already there. It is now I guess stable so feel free to 33 00:03:00,319 --> 00:03:07,560 use it in your applications if you want to have JRX and signals. But 34 00:03:07,840 --> 00:03:10,319 of course, the big big thing that we now have is a fully signal 35 00:03:10,360 --> 00:03:23,960 based store. It's functional, it's extensible, and it is relatively easier to 36 00:03:23,039 --> 00:03:30,199 adopt than say n JRX store like the conventional store, because there you had 37 00:03:30,240 --> 00:03:38,680 the reduct pattern, right, you need to learn some consopt selectors and reducers. 38 00:03:38,840 --> 00:03:42,159 Obviously, if you are an Angular developer who knows signals but it's not 39 00:03:42,240 --> 00:03:46,879 familiar with reducts or flux or whatever, adopting njr X signals will be way 40 00:03:46,919 --> 00:03:51,800 easier for you and brings almost all the benefits that you have with NJRX store. 41 00:03:51,960 --> 00:03:57,080 Okay, So how it works is that you can create lots of stores. 42 00:03:57,360 --> 00:04:00,319 They can be decoupled from each other, or you can couple them. 43 00:04:00,319 --> 00:04:02,479 You can provide them on any level of your application that you want. You 44 00:04:02,479 --> 00:04:08,800 can have a I don't know, root level store for global stuff and component 45 00:04:08,879 --> 00:04:15,639 level store for whatever this one particular component is doing. Okay, so how 46 00:04:15,680 --> 00:04:19,240 you do it? There's a function called create store. Now create signal store. 47 00:04:19,800 --> 00:04:26,720 I'm not sure this doesn't really matter, so and it can receive a 48 00:04:26,720 --> 00:04:30,319 bunch of modifications. So if you just create a signal store and pass it 49 00:04:30,360 --> 00:04:33,800 the wid state function so that you can give it an initial state, and 50 00:04:33,959 --> 00:04:38,120 you could be down with that. You now have a signal based you know 51 00:04:39,360 --> 00:04:44,199 store okay that only has this data. It automatically creates selectors to select the 52 00:04:44,279 --> 00:04:48,240 data that you have there, okay, and you provide the data as a 53 00:04:48,240 --> 00:04:51,720 plain object. But now you have signals of all that stuff, right, 54 00:04:53,279 --> 00:04:58,839 which is you know, kind of cool little thing. You don't have to 55 00:04:58,879 --> 00:05:02,120 write signal this, signal that all the time. But now you have a 56 00:05:02,160 --> 00:05:08,279 store that has data that you can select as signals. Essentially, you would 57 00:05:08,319 --> 00:05:12,839 just do I don't know my to do store, do all to do for 58 00:05:12,879 --> 00:05:15,839 example, and you'll get the array of the signals. Then you can add 59 00:05:15,879 --> 00:05:20,759 computed properties derived from you know, your state, and you will just you're 60 00:05:20,839 --> 00:05:26,680 just going to be using the computed function. So it's fairly easy. It 61 00:05:26,759 --> 00:05:30,199 gets a call back in the callback. You have an object that has all 62 00:05:30,240 --> 00:05:34,160 your state. Now whichever signals from the state you use, it will be 63 00:05:34,199 --> 00:05:42,399 a computed signal created from those pieces of state where you can create computed properties 64 00:05:42,399 --> 00:05:47,519 there. For instance, in my in the example that I provided in the 65 00:05:47,560 --> 00:05:54,920 Twitter thread, I use the query to search among the in the to do 66 00:05:55,079 --> 00:05:58,319 list. So I have the list of all to dos. I have a 67 00:05:58,439 --> 00:06:01,560 query which is an empty stream, I default and user tapes something. I 68 00:06:01,639 --> 00:06:05,199 have a computed property that you know, selects all need to do that are 69 00:06:06,279 --> 00:06:12,079 relevant to whatever the user has searched, and I do with computed signals. 70 00:06:12,199 --> 00:06:14,480 And it's the same way in the end of the day, in the in 71 00:06:14,560 --> 00:06:21,079 the component where you're using the store, you just get that value as a 72 00:06:21,120 --> 00:06:25,319 signal. You don't really care how it works, and you cannot. Of 73 00:06:25,319 --> 00:06:29,000 course, you cannot rewrite those signals. You cannot set those signals directly, 74 00:06:29,160 --> 00:06:34,199 which was the bitchtick With, for example, a conventional store, you could 75 00:06:34,240 --> 00:06:40,079 only use actions right reducers to change the state. You couldn't like say, 76 00:06:40,199 --> 00:06:42,959 oh, I want this property to be something. You had to create an 77 00:06:42,959 --> 00:06:46,959 action you have to create reduce it more or less. The same is going 78 00:06:46,000 --> 00:06:50,879 on here. The third extension that you could do to your story is ad 79 00:06:51,000 --> 00:06:56,839 methods. There's a with method function and you can give it an object of 80 00:06:56,959 --> 00:07:01,120 methods that you can then call in order to you know, change your state 81 00:07:01,279 --> 00:07:03,759 and if you want to change the state, you have to use a special 82 00:07:03,800 --> 00:07:10,399 function called patch state, which is essentially a small small reducer to which you 83 00:07:10,439 --> 00:07:13,680 can give the piece of the state you want to change and the new sort 84 00:07:13,720 --> 00:07:16,399 of new value or the callback to use the previous value and so on, 85 00:07:16,839 --> 00:07:21,000 liking reducts, but a bit shorter. You just call it a patch state. 86 00:07:21,240 --> 00:07:27,279 If this method is called patch state, set this new whatever item. 87 00:07:27,319 --> 00:07:31,160 You can provide arguments and so on. And the cool thing is that you 88 00:07:31,199 --> 00:07:35,240 can also provide like RIX methods. That's literally a function called rix method, 89 00:07:36,240 --> 00:07:42,480 and inside that RICS method function you can define some synchronous task like or for 90 00:07:42,560 --> 00:07:46,199 this state modification. What I want to do is, you know, make 91 00:07:46,240 --> 00:07:50,079 decision to be called get the response, change this I don't know property on 92 00:07:50,160 --> 00:07:55,680 the store depending on the response and so on. So yeah, these are 93 00:07:55,879 --> 00:07:59,800 kind of like the basics. Right, So you can create state, you 94 00:07:59,839 --> 00:08:03,480 can create computed states, and you can create methods and also our methods. 95 00:08:03,040 --> 00:08:07,519 Ok So that's the whole idea, and all of all of that stuff lives 96 00:08:07,519 --> 00:08:11,839 in one place. Okay, just create one store here. It works. 97 00:08:13,319 --> 00:08:16,399 Okay, I think pretty pretty nice. So one thing coming to my question 98 00:08:16,480 --> 00:08:22,279 to my mind, like I think. Suppose someone is already doing a gr 99 00:08:22,439 --> 00:08:28,920 X a lot and now they have on effects, wratting effects, writing actions 100 00:08:28,920 --> 00:08:33,200 and all. I think, although this is also going to work with older 101 00:08:33,480 --> 00:08:39,799 facts and accents. So suppose I think ad in the in the thread thread 102 00:08:39,840 --> 00:08:46,159 asually you have Soon the WI method will will execute whenever there will way any 103 00:08:46,200 --> 00:08:48,679 state change, right. Uh? No, The methods are the stuff that 104 00:08:48,720 --> 00:08:56,039 you call when you want to change the state the computed properties will you know, 105 00:08:56,159 --> 00:09:01,399 re executive there dependent track signals changed. Methods are for you know, 106 00:09:01,240 --> 00:09:07,279 like actions were in the store. Okay, okay, so no, no 107 00:09:07,759 --> 00:09:11,799 my question. I suppose, for example, I I want to make a 108 00:09:13,080 --> 00:09:18,360 stra typical to the server, and for that I create actions. Action calls 109 00:09:18,720 --> 00:09:24,159 the effectually called the bra uh the setuotypical get the data, then we call 110 00:09:24,200 --> 00:09:28,440 the reducer, then pat the states. So can you just explain a bit 111 00:09:28,559 --> 00:09:33,840 like how this thing will work on these scenarios. Sure, that's what the 112 00:09:35,000 --> 00:09:39,240 rigs method is for here. As you notice, I didn't say anything about 113 00:09:39,279 --> 00:09:43,879 actions because you do not have actions in the signal store. Uh. And 114 00:09:43,960 --> 00:09:48,320 this is actually great for me. I like and reg store. I actually 115 00:09:48,360 --> 00:09:52,720 didn't like component store. If anyone has worked with component store. I mean 116 00:09:52,759 --> 00:09:54,919 it's nice, but I didn't like it didn't have actions, it was not 117 00:09:56,120 --> 00:10:01,120 events driven. So for example, with one action I could make a decision, 118 00:10:01,159 --> 00:10:05,000 three I could make something. I could say, all this action triggers 119 00:10:05,039 --> 00:10:09,240 these lots of stuff and so on, which, to an extent, I 120 00:10:09,279 --> 00:10:11,759 still can get with methods. But methods are to me like a bit more 121 00:10:11,799 --> 00:10:18,000 imperative. Like instead of saying what would I do with the JRX stories, 122 00:10:18,039 --> 00:10:24,480 I would say, you know, for example, this component has loaded dispatch 123 00:10:24,799 --> 00:10:28,879 events action that this component is loaded and I don't care who handles it. 124 00:10:28,000 --> 00:10:31,960 However, and in the store, I would say, oh, if this 125 00:10:31,080 --> 00:10:35,200 component is loaded, this is an effect I need to fetche these days, 126 00:10:35,200 --> 00:10:39,159 and that in this case, I have to be a bit more imperative. 127 00:10:39,240 --> 00:10:41,120 I need to write a function that says I don't know a load data for 128 00:10:41,200 --> 00:10:46,200 this component. For example, it's a function that I'm gonna call okay, 129 00:10:46,279 --> 00:10:52,240 and it will It is going to belong only in one store. So if 130 00:10:52,279 --> 00:10:56,080 I want to search data in two different stores, I need to call two 131 00:10:56,080 --> 00:11:03,879 different two different methods. Again, of course, what I can do is 132 00:11:03,279 --> 00:11:09,279 create just one signal or a big signal store and have different methods imported and 133 00:11:09,639 --> 00:11:11,519 just converge in one place into one store. I could do that. That's 134 00:11:11,519 --> 00:11:15,519 also an approach. Not not bad, not a big fan myself, but 135 00:11:15,720 --> 00:11:18,240 you could do that, or you would have to call several methods, which 136 00:11:18,279 --> 00:11:22,960 I don't like. So your question about effects, why I'm saying all of 137 00:11:22,960 --> 00:11:26,639 this stuff, is that effects now don't exist as effects that were in NJRX 138 00:11:26,639 --> 00:11:33,120 store. An NJRX store effect was just separate entity, just separate thing that 139 00:11:33,200 --> 00:11:39,679 could like a reducer react to actions and work with observables. Right, It 140 00:11:39,720 --> 00:11:43,919 was like a reducer for observable sort of thing. Here, we don't really 141 00:11:43,960 --> 00:11:48,960 have it, but what we have is rix method. So instead, so 142 00:11:48,080 --> 00:11:52,600 for usual methods, for example, if we look a look at my example. 143 00:11:52,360 --> 00:12:00,879 For instance, here I have a mark as completed method. This is 144 00:12:00,879 --> 00:12:05,919 a conventional method that just takes an idea of a to do item, finds 145 00:12:05,960 --> 00:12:11,360 it, changed it to completely true right, and patches it back on the 146 00:12:11,399 --> 00:12:16,600 state. So it is a simple synchronous method. But I also have a 147 00:12:16,679 --> 00:12:20,279 load to do this method. Load to do this now here is doing urge 148 00:12:20,399 --> 00:12:24,440 stuff. It's doing a synchronous stuff. It loads data and what it does 149 00:12:24,480 --> 00:12:28,919 it used this function called RICS method. And this is a really cool function 150 00:12:28,039 --> 00:12:33,320 because the RICS method essentially creates a function itself, is a higher order function 151 00:12:35,519 --> 00:12:45,200 that works asynchronously, and its argument is the whatever observable you want it to 152 00:12:45,360 --> 00:12:50,159 execute. Okay. So the cool thing here is that you no longer need 153 00:12:50,200 --> 00:12:52,519 to do like switch mad like what you do would do with the endoric effects. 154 00:12:52,559 --> 00:12:58,320 It would say actions type I don't know off type. Let's say load 155 00:12:58,440 --> 00:13:03,000 to do items which map or marriage map, and then I would say go 156 00:13:03,080 --> 00:13:05,679 to do service blah blah blah, load and so on and in the end 157 00:13:05,799 --> 00:13:09,879 map to another action, which LOKs fine for me. It's not bad. 158 00:13:09,120 --> 00:13:13,480 Where ARIS method is actually simpler. You could just use the pipe function, 159 00:13:13,639 --> 00:13:20,600 not the pipe operator. There is a pipe function in the RGS package, 160 00:13:20,799 --> 00:13:26,360 not RGS slush operators, just RHS and the pipe function. What it does 161 00:13:26,440 --> 00:13:31,600 it creates a higher order observable if you pass operators to it. So essentially 162 00:13:31,600 --> 00:13:35,519 what you say is just execute this operator, and inside I would say, 163 00:13:35,720 --> 00:13:43,200 okay, switch map to this HTP call or whatever. And they also actually 164 00:13:43,240 --> 00:13:52,320 added, well, this one existed previously. It is a custom RGS operators 165 00:13:52,360 --> 00:13:56,279 from jr X called type response so you don't need to subscribe or map to 166 00:13:56,320 --> 00:14:00,960 an action. You could do type response and inside you can provide callbacks for 167 00:14:01,240 --> 00:14:11,200 error completion right, and a finalized callback which would work when regardless when it 168 00:14:11,320 --> 00:14:15,679 is done, regardless of whether there's been an error or not. Okay, 169 00:14:15,879 --> 00:14:18,759 So in my example, what it does is that the next call back it 170 00:14:18,840 --> 00:14:22,759 catches the state with the to doos from the back end. The to do 171 00:14:22,879 --> 00:14:28,840 least error does a console error or whatever. However we want to handle the 172 00:14:28,960 --> 00:14:37,080 error and finalize turns the loading bully into false because we either completed the call 173 00:14:37,159 --> 00:14:41,679 successfully or there was an error, so we no longer need to display a 174 00:14:41,000 --> 00:14:46,159 spinner or whatever. So Rix's method is essentially what replaces effects. We no 175 00:14:46,240 --> 00:14:52,919 longer really have effects here. We have methods that do acing stuff with observables, 176 00:14:52,960 --> 00:14:54,279 but in the end of the day they still you know, have to 177 00:14:54,320 --> 00:14:58,799 push it to the signal store via patch state. So yeah, that's about 178 00:14:58,840 --> 00:15:03,320 it. Our arg method is the replacement for effects here. That's the bottom 179 00:15:03,320 --> 00:15:09,240 line. Yeah, So here I want more questions like so this with with 180 00:15:09,559 --> 00:15:18,159 methods will be figgered on instances of the store, or how will you tiger 181 00:15:18,320 --> 00:15:22,919 to supple the in your example load to do How will you tigre that? 182 00:15:22,559 --> 00:15:28,080 Yeah, that's a good question. Either I call it on the instance of 183 00:15:28,200 --> 00:15:31,360 the store, So what would I do. Let's say I made the to 184 00:15:31,480 --> 00:15:35,080 do store and now I have a to do this component. Okay, I 185 00:15:35,080 --> 00:15:37,480 can provide the store on the to do component or wherever I could provide it 186 00:15:37,519 --> 00:15:43,279 in the root. I can provide it in some pots or whatever. Now 187 00:15:43,320 --> 00:15:46,159 I inject the store, I have the resonance of the store. The store 188 00:15:46,240 --> 00:15:50,320 now has all the properties that I define as signals, so I can say 189 00:15:50,480 --> 00:15:56,200 to do store dot let's say loading and show spinner or not in the tumplate. 190 00:15:58,000 --> 00:16:03,320 And it also can pains the methods that I define there. So for 191 00:16:03,360 --> 00:16:07,559 example, I can write an engine on a nat method and there I can 192 00:16:07,600 --> 00:16:12,279 call a load to doce and just select the signals and use the signals in 193 00:16:12,360 --> 00:16:18,799 the template. But there are also cool things. There's also a function called 194 00:16:18,879 --> 00:16:23,000 with hooks, so I can define two life cycle hooks for the store, 195 00:16:25,120 --> 00:16:29,600 an on inat method and an on destroy method. And that's really cool because 196 00:16:29,639 --> 00:16:34,480 now I don't even need to define a life cycle method in the component because 197 00:16:34,519 --> 00:16:38,840 the store itself as well. If the to do story is initialized and the 198 00:16:38,879 --> 00:16:45,000 todos are actually coming from the backhand. Why wait for the component? I 199 00:16:45,039 --> 00:16:48,039 mean, there can be scenarios where I would want to wait for some properties. 200 00:16:48,279 --> 00:16:52,360 But let's say the core element of this story is the to do. 201 00:16:52,759 --> 00:16:56,240 The to doos will arrive from the back end anyway, so I can just 202 00:16:56,279 --> 00:17:02,320 put that logic in the store itself and say with who function only need please 203 00:17:02,639 --> 00:17:07,880 you know, load the to this list and touch state and whatever essentially. 204 00:17:07,559 --> 00:17:11,119 Again, in my example, I also use that I define the only method 205 00:17:11,200 --> 00:17:18,359 and just call the load to do reactive method that I defined in the with 206 00:17:18,559 --> 00:17:23,480 methods function. And that's really cool because you have like different functions with callbacks, 207 00:17:23,720 --> 00:17:27,519 but each function in its callback can use something that was defined in the 208 00:17:27,559 --> 00:17:33,119 other callback because you always get the state as an argument to your callbacks there, 209 00:17:33,160 --> 00:17:37,240 and you can just call the store sorry, you can just call are 210 00:17:37,279 --> 00:17:41,400 the items on the store state properties, or you can call some methods to 211 00:17:41,440 --> 00:17:44,640 execute stuff. So you have two scenaris. You are to call the method 212 00:17:44,680 --> 00:17:48,519 there, which is useful when you are updating something. For example, in 213 00:17:48,559 --> 00:17:56,359 the component, I have a button or checkbox rather next to each to the 214 00:17:56,480 --> 00:18:00,279 item, and when I click on it. It just to do store dot 215 00:18:00,599 --> 00:18:07,279 mark as completeed to do that idea as an argument. So yeah, that's 216 00:18:07,279 --> 00:18:11,559 about it. You have to call it or you can use hooks to call 217 00:18:11,599 --> 00:18:15,359 it prematurely or after the destruction of the state. Yeah, pretty cool. 218 00:18:15,519 --> 00:18:22,279 Like this will reduce a lot of boilerplate. Absolutely, just right now, 219 00:18:22,319 --> 00:18:29,720 from the top of my head, imagine having some data coming from web sockets. 220 00:18:30,319 --> 00:18:36,359 So what you could essentially do on the initialization of your store you can 221 00:18:37,160 --> 00:18:41,759 say, okay, establish a socket connection, and please every time that this 222 00:18:41,920 --> 00:18:49,240 socket is emitting something, punch the state with whatever message it's sent. And 223 00:18:49,279 --> 00:18:53,799 then in the undestroyed hook you could just say, okay, if you destroy 224 00:18:53,799 --> 00:18:57,440 it, then let's disconnect the okay, okay. And now in the component 225 00:18:59,079 --> 00:19:04,799 you have zero idea that this is a web focus or whatever in the company, 226 00:19:04,799 --> 00:19:07,440 you'll just say, okay, I have some messages notifications. I'll just 227 00:19:07,519 --> 00:19:12,759 slay them. That's it. Some other things that I saw that are posted 228 00:19:14,400 --> 00:19:22,680 news in this version seventeen are that they are deprecating or actually they're not officially 229 00:19:22,680 --> 00:19:30,559 deprecating, but they're putting it into maintenance mode, which is AnGR X data. 230 00:19:30,400 --> 00:19:36,359 And I thought that was interesting because there's something that I've used extensively in 231 00:19:36,400 --> 00:19:41,400 the past. So that was like, A I must say that I was 232 00:19:41,440 --> 00:19:44,279 a bit afraid when I saw that. I was like, oh shit, 233 00:19:44,400 --> 00:19:48,640 I'm gonna have to migrate a lot of what I have. And I wonder 234 00:19:48,720 --> 00:19:56,279 if you because I haven't seen them suggesting a direct alternative to it, Like, 235 00:19:56,400 --> 00:20:00,079 sure, they're migrating to a more signal based approach, but this wouldn't 236 00:20:00,119 --> 00:20:06,359 really work for what jr x data was supposed to do, which is to 237 00:20:06,680 --> 00:20:15,200 already provide you a default store created based on like basic crude operations to a 238 00:20:15,279 --> 00:20:21,039 particular API. So that's that's gotta be our xgs because we're doing asynchronous work. 239 00:20:21,599 --> 00:20:27,200 So I wonder what would be the recommended approach for that, like for 240 00:20:27,279 --> 00:20:36,319 anyone wanting to create a facade between their their data stores and API resources for 241 00:20:36,359 --> 00:20:41,200 example. That's a that's a good question, but I want to highlight something 242 00:20:41,279 --> 00:20:47,279 before before I answer it. Uh, I alway isn't migrating anywhere. I 243 00:20:47,440 --> 00:20:53,400 like both danger store and component store, and the signal store will continue to 244 00:20:53,680 --> 00:21:00,200 be maintained, will continue to be updated. So if essentially the only thing 245 00:21:00,279 --> 00:21:07,599 that we got here, like I wouldn't really connect putting JRX data into maintenance 246 00:21:07,599 --> 00:21:11,119 with signals. I think this was a big thing that was coming all along, 247 00:21:12,240 --> 00:21:15,799 and it stands from one thing that I'm not going to say something opinionated 248 00:21:15,920 --> 00:21:21,720 and I want to make with This is just my opinion. I don't claim 249 00:21:21,759 --> 00:21:27,240 to be completely right on this, but I don't think we really need facades 250 00:21:29,200 --> 00:21:33,519 for NJRX. Of course, there's been lots of articles from lots of people 251 00:21:33,519 --> 00:21:40,079 that I respect, and I think their opinion is very valid, But I, 252 00:21:40,119 --> 00:21:45,039 you know, respectfully disagree for me, like you have facades, they 253 00:21:45,039 --> 00:21:48,720 would create facades, they would write the selectors there, and in the component 254 00:21:48,759 --> 00:21:52,880 they will inject the facade and so on. I don't agree that is necessary 255 00:21:53,839 --> 00:21:57,799 because for me and JRX. For for example, if you takes most the 256 00:21:57,880 --> 00:22:02,400 most basic things like danger x store, for me, it is already a 257 00:22:02,440 --> 00:22:07,400 facade, uh for instance, it acts as a facot with the fact that 258 00:22:07,440 --> 00:22:14,559 it has effects that are essentially the couples from your components flow like you don't 259 00:22:14,599 --> 00:22:18,720 call effects directly in your in your components. Essentially, you have a facade 260 00:22:18,960 --> 00:22:25,319 called the store and actually just gives you two methods. You select the data 261 00:22:26,400 --> 00:22:32,839 and you dispatch actions, and when you dispatch an action, you really have 262 00:22:33,079 --> 00:22:40,480 no idea from the component perspective which selected properties would change. Okay, you 263 00:22:40,559 --> 00:22:45,079 dispatch an action, which is essentially just an event if you're doing it correctly. 264 00:22:45,480 --> 00:22:48,839 Lots of people would do like imperative actions, like we would say load 265 00:22:48,920 --> 00:22:52,680 data, load these blah blah blah. In reality, what you need to 266 00:22:52,680 --> 00:22:56,440 do is you need to to create events like your component loaded. Okay, 267 00:22:56,480 --> 00:23:00,720 you dispatch an action that says, I don't know, use a our component 268 00:23:00,759 --> 00:23:03,079 loading. That's it. That's what you tell all the world. You say, 269 00:23:03,119 --> 00:23:06,759 I'm a component, I'm here, I was loaded, please whatever. 270 00:23:06,839 --> 00:23:10,519 I also need these data. I select this data, and I just patched 271 00:23:10,559 --> 00:23:15,599 this action, so it is already a facade. Angel X data for me 272 00:23:15,240 --> 00:23:19,599 is sort of a facade of a facade. It's useful, I mean I 273 00:23:19,599 --> 00:23:26,599 don't I completely agree that it's useful in the context of like I don't have 274 00:23:26,680 --> 00:23:33,599 to single handedly write out every single crude operation method. That's an understandable thing, 275 00:23:33,799 --> 00:23:40,960 no disagreement there. But in most enterprise applications this is like twenty twenty 276 00:23:41,039 --> 00:23:45,759 five percent of the work. You would still need to define lots of lots 277 00:23:45,799 --> 00:23:49,359 of methods, and in the end of the day, you have to keep 278 00:23:49,400 --> 00:23:55,400 track of your services that work with the you know, the data, right. 279 00:23:55,720 --> 00:24:00,799 Make sure your API is a bit you know works in the world it 280 00:24:00,880 --> 00:24:08,359 is intended. Like imagine having an API that uses a post request to get 281 00:24:08,519 --> 00:24:17,640 some data. I mean that's not unheard of, right. You could have 282 00:24:18,519 --> 00:24:23,440 a very big query and it just doesn't fit as a querry parameter, so 283 00:24:23,480 --> 00:24:29,680 you have to send the body and you need a post request. So those 284 00:24:30,200 --> 00:24:33,480 sorts of problems can come up right with Enjeric's data, and then Garry's data 285 00:24:33,519 --> 00:24:38,160 only solves like twenty percent of the problems, and it was like not really 286 00:24:38,160 --> 00:24:41,319 a problem, but more like boilerplate code. That code still exists, right, 287 00:24:41,319 --> 00:24:47,599 you still wipe out your services. You just sort of make them connected 288 00:24:47,759 --> 00:24:51,279 to the store, and you don't directly access a store. Would rather use 289 00:24:51,359 --> 00:24:53,839 the you know, the facade of the facade, right that you have with 290 00:24:55,000 --> 00:24:59,319 njered data. So it's not usefully it's obviously it's a bad thing, but 291 00:24:59,400 --> 00:25:07,079 it just doesn't I guess warrant like it's too big of a contract, Okay, 292 00:25:07,559 --> 00:25:12,079 And that is what now you're experiencing the right looks like you think, 293 00:25:12,119 --> 00:25:18,759 oh, I have to, you know, refactor this because I have sort 294 00:25:18,759 --> 00:25:22,319 of married my state into these services via Jerry Data, right, and now, 295 00:25:22,920 --> 00:25:27,240 well they're deprecating it at least I think in the forcible future. I 296 00:25:27,240 --> 00:25:34,319 don't think it will be deprecated in version eighty. Okay. They could, 297 00:25:34,839 --> 00:25:41,240 however, deprecate it in twenty for instance. I couldn't say much about it, 298 00:25:41,319 --> 00:25:45,400 but still it would be well ahead of time, so there is time 299 00:25:45,440 --> 00:25:49,960 to refectory. I think it would be relatively is it to refectory to a 300 00:25:51,000 --> 00:25:56,559 conventional store, right? Or you could rewrite it into facades, like write 301 00:25:56,599 --> 00:26:02,240 out the facades yourself so they don't you know you have a facade with the 302 00:26:02,279 --> 00:26:04,880 same method, and then you can start removing the facades one one by one 303 00:26:06,400 --> 00:26:08,799 and you just remove enjoyic data and then you will deal with your facade later. 304 00:26:10,000 --> 00:26:15,319 For there is a strategy, I guess. I don't think it is 305 00:26:15,880 --> 00:26:22,599 that simple because, for example, there's one particular thing that njr x data 306 00:26:22,079 --> 00:26:27,359 handles which is really hard to do manually, like really hard, which is 307 00:26:30,319 --> 00:26:37,599 the error handling. For example, you can have a method in your in 308 00:26:37,640 --> 00:26:42,400 your facade exposed using jr x data. That would be like create one for 309 00:26:42,480 --> 00:26:51,000 example, and this is going to return a promise, And what you can 310 00:26:51,079 --> 00:26:56,519 do is make it so that if the request to the back end fails, 311 00:26:56,000 --> 00:27:02,279 that promise rejects and if you works, the promise resolves with the data. 312 00:27:02,359 --> 00:27:06,920 But it not just results with the data, but it also updates the cash 313 00:27:07,079 --> 00:27:10,839 that you have, so everything that is listening to that cash also updates. 314 00:27:11,839 --> 00:27:18,720 Doing this error trow is much harder without j X data because if you have 315 00:27:18,920 --> 00:27:26,359 like a normal store and you just want to like you want to emit the 316 00:27:26,519 --> 00:27:33,440 error to as an event so that whoever's listening to the error event can answer 317 00:27:33,519 --> 00:27:38,400 to it, but you also want to just strow the error in the method. 318 00:27:40,599 --> 00:27:45,880 That is way harder than it looks. And j REX also does a 319 00:27:45,920 --> 00:27:53,599 lot of internal ID creation to connect the error to the event that trigger it, 320 00:27:55,480 --> 00:28:00,319 and that's kind of hard to do on your own. Yeah, idea 321 00:28:00,400 --> 00:28:07,599 that of course, it's a concern. I think the main contributor to data 322 00:28:07,960 --> 00:28:14,920 being put into maintenance models well like a popularity. Obviously, not a lot 323 00:28:14,960 --> 00:28:17,839 of people are using I don't never used that. I tried it out once 324 00:28:17,880 --> 00:28:23,039 in a pet project and that was about it. Another significant blow to enjeric 325 00:28:23,200 --> 00:28:33,279 data was the introduction of feature stores. Right, so you could combine. 326 00:28:33,480 --> 00:28:41,680 You could bring reducer and you could bring it will automatically generate the selectors, 327 00:28:42,000 --> 00:28:48,759 and now you also create action group. So essentially what it does it says, 328 00:28:49,119 --> 00:28:53,920 you know this, this package provides more freedom, So just enjerk store. 329 00:28:55,119 --> 00:29:00,960 Let's just enhance it. So the real boiler plate stuff like selectors that 330 00:29:00,079 --> 00:29:04,039 just select some property, like you don't need to be a genius, you 331 00:29:04,079 --> 00:29:08,720 know, do that. That store can handle it automatically. Or if you 332 00:29:08,720 --> 00:29:11,440 want to create those of actions that are connected with each other, okay, 333 00:29:11,440 --> 00:29:15,319 here create action groups. You can create lots of actions. And what is 334 00:29:15,359 --> 00:29:23,480 happening now it says, okay, that package was useful, but we're not 335 00:29:23,640 --> 00:29:30,920 going to maintain it because one problem it has it has nowhere else to grow, 336 00:29:32,799 --> 00:29:37,200 Like it cannot you know, predict what other custom methods you want to 337 00:29:37,200 --> 00:29:45,440 have. Right, So now what you can do is if you are let's 338 00:29:45,480 --> 00:29:48,079 say error handling, like you have this approach, right, what you could 339 00:29:48,160 --> 00:29:52,519 do with functional approaches right that we have in the jars. What you could 340 00:29:52,519 --> 00:29:57,799 do is you could have a higher order function that just does that for instance, 341 00:29:57,920 --> 00:30:03,480 you have top response now, right, you can just rap it inside 342 00:30:03,480 --> 00:30:07,799 another function. Your custom top response as will always do the same error handling. 343 00:30:08,519 --> 00:30:12,759 But you could also, let's say, provide an optional argument of another 344 00:30:12,880 --> 00:30:19,000 collback that you want in one specific case with our handling. Okay, so 345 00:30:21,200 --> 00:30:26,799 you can write like five lines of call to fully customize that function. And 346 00:30:26,880 --> 00:30:33,039 the same goes for actions. You have action group. Now you can also 347 00:30:33,119 --> 00:30:37,640 like actions themselves are just functions. When we call create action does to create 348 00:30:37,680 --> 00:30:41,920 an action. What it does creates an action creator which we then need to 349 00:30:41,920 --> 00:30:45,920 call to get the actual action object. Right, what you can do you 350 00:30:45,960 --> 00:30:51,440 can rap that function. We did this approach for example with NJRX store, 351 00:30:51,480 --> 00:30:53,319 but you could do the same with Signal store with phone store. What we 352 00:30:53,359 --> 00:30:57,400 did we create a higher order function. It was called for example specifically for 353 00:30:57,519 --> 00:31:03,680 HTP. It would create free HTP actions. It was called create actions. 354 00:31:03,839 --> 00:31:08,400 It would take a response request model, response model, what we are sending 355 00:31:08,400 --> 00:31:11,039 to the server, what we're expecting from the server, and it would give 356 00:31:11,119 --> 00:31:18,359 us free actions in a topple. Now, the error and success functions actions 357 00:31:18,400 --> 00:31:22,000 had their specific metadata on this object, but I didn't need to define that 358 00:31:22,039 --> 00:31:27,119 metadata. So for example, errors always had something like successfuls on it, 359 00:31:29,000 --> 00:31:33,119 and in the effects, what I would do. I would first get all 360 00:31:33,200 --> 00:31:37,200 actions, I would filter out the ones that are related to HTP with the 361 00:31:37,240 --> 00:31:41,319 metadata I put in the action okay. Then I would perform I would see 362 00:31:41,359 --> 00:31:45,440 if okay, this is an error. In case of error, I would 363 00:31:45,440 --> 00:31:52,200 call some error handler service to handle that error okay, And if it was 364 00:31:52,319 --> 00:31:56,279 success, I would display a message or whatever and so on. So those 365 00:31:56,319 --> 00:32:02,160 are just two effects global effects that worked always. So I never actually wrote 366 00:32:02,599 --> 00:32:08,960 a single line of duplicate error handling code. Instead, I would just would 367 00:32:08,960 --> 00:32:16,119 say catch error return observable of this error action that was automatically created for me. 368 00:32:16,480 --> 00:32:22,359 I didn't need to define anything. Obviously, this is several lines of 369 00:32:22,440 --> 00:32:30,000 code more than not writing any code, but I guess it's less obscure, 370 00:32:30,240 --> 00:32:35,799 like what codes on there. Like the function that creates three error actions is 371 00:32:35,839 --> 00:32:38,279 fairly simple to explain. You could comment it, you could document it, 372 00:32:38,559 --> 00:32:43,200 and then you can document two effects that are handling success in error cases, 373 00:32:43,960 --> 00:32:54,640 and essentially that's it. That's what like about event driven component sorry state management, 374 00:32:54,720 --> 00:32:59,039 which we have with NGR extore, which I like. I like that 375 00:32:59,119 --> 00:33:05,319 I can say Okay, I want to do something on all HTP calls. 376 00:33:05,640 --> 00:33:07,519 Okay, sort of like an interceptor. Now I would have to do an 377 00:33:07,519 --> 00:33:12,160 interceptor. But what if I want to do something on all errors, Like 378 00:33:12,559 --> 00:33:17,279 I don't care every error. I want a red notification message somewhere on the 379 00:33:17,279 --> 00:33:23,039 screen. Okay. I probably I would do some other or handling for some 380 00:33:23,160 --> 00:33:28,519 specific cases, but I always want the red thing that's something done wrong. 381 00:33:28,720 --> 00:33:32,480 Sorry. I can do that easily with effects food, action driven, event 382 00:33:32,599 --> 00:33:36,720 driven state. Managine, I can't do that with ajerics data. I can't 383 00:33:36,720 --> 00:33:40,160 do that with with a signal store. I can't do that because it doesn't 384 00:33:40,160 --> 00:33:45,039 have actions. But the cool thing. Sorry, I'm talking too long on 385 00:33:45,119 --> 00:33:52,240 this question, but we just arrived to logically arrive to the other big thing. 386 00:33:52,519 --> 00:33:55,759 When I say the signal store is extensible, means that you can write 387 00:33:55,799 --> 00:34:01,680 your own functions and use the state and provide it to the signal store creator 388 00:34:01,799 --> 00:34:07,799 function, meaning that actually, if you really want to, you can have 389 00:34:07,239 --> 00:34:13,360 an event driven stuff. You could do a reducer driven stuff in a signal 390 00:34:13,400 --> 00:34:19,119 store. You can do that by writing your own custom function. I have 391 00:34:19,199 --> 00:34:22,280 seen people doing that. I haven't tried it out yet, but it is 392 00:34:22,320 --> 00:34:25,320 possible, okay, because it is extensible and you can wrap pieces of state 393 00:34:25,360 --> 00:34:31,119 into functions and using other stores. Okay, so with signal Store you can 394 00:34:31,159 --> 00:34:37,000 do that. With Jerry's Data, I guess you still have to resort to 395 00:34:37,199 --> 00:34:44,320 the manual stuff when it came to custom things. So the benefit was Again 396 00:34:44,360 --> 00:34:46,320 I'm not trying to say it was a bad package. I didn't like it, 397 00:34:47,159 --> 00:34:52,440 but it was more of the case like, Okay, it will work 398 00:34:52,480 --> 00:34:57,519 if I have a table that is purely crude stuff. But in general, 399 00:34:58,320 --> 00:35:02,920 this is really how world works. It's like fifteen twenty percent of cases, 400 00:35:02,960 --> 00:35:08,679 but more complex cases, interconnected models and so on. That does make sense. 401 00:35:10,199 --> 00:35:15,360 Still, I wish that, for example, all those utilities that you 402 00:35:15,400 --> 00:35:22,000 said everyone's going to have to build, if the people that are built NJRX 403 00:35:22,119 --> 00:35:27,960 data could do that, that would be way better. Of course, but 404 00:35:28,000 --> 00:35:31,519 again I understand that open source community, we can't really just put that pressure 405 00:35:31,559 --> 00:35:39,079 into the maintainers. But it really would be amazing because this migration can be 406 00:35:39,159 --> 00:35:45,280 really frustrating, and not every company is going to have professionals that will be 407 00:35:45,320 --> 00:35:50,000 able to build all those utilities that INJRX data used to provide. Yeah, 408 00:35:50,159 --> 00:35:58,239 I understand like NGRX itself never said they would continue the development of NJRX data. 409 00:35:58,360 --> 00:36:04,599 It was always a project created by other members of the community, not 410 00:36:04,719 --> 00:36:09,800 the official creator and supporter of NJRX. So yeah, that's a good point, 411 00:36:09,960 --> 00:36:17,880 although it was never something that was advertised, so enterprise companies making the 412 00:36:17,960 --> 00:36:24,559 decision to use jr xdata didn't know that the support and continuation of that package 413 00:36:24,719 --> 00:36:30,519 would be different from the rest of the NJRX or packages. You know. 414 00:36:30,599 --> 00:36:32,840 It's kind of like when you put something in the at angler scope, you 415 00:36:32,960 --> 00:36:38,639 expect it to be supported just like every other package in the Angler scope. 416 00:36:38,920 --> 00:36:45,280 So that's the expectation. If you were like an at NJRX dash community, 417 00:36:45,800 --> 00:36:50,920 then okay, you kind of already understand that we're talking about different maintainers. 418 00:36:51,000 --> 00:36:55,079 But it was in the NJRX scope, you know. So that was like 419 00:36:55,480 --> 00:37:00,440 a huge blow to me, and I'm pretty sure that it would be hard 420 00:37:00,599 --> 00:37:07,400 to explain to two clients like that. It was a good decision in hindsight, 421 00:37:07,760 --> 00:37:14,360 I see some developers maybe having some tough conversations with their managers when the 422 00:37:14,360 --> 00:37:20,320 managers realized that the package is going to be discontinued. But yeah, another 423 00:37:20,440 --> 00:37:23,599 thing that I think would be interesting for us to talk about is component store. 424 00:37:24,679 --> 00:37:30,639 Like there is no direct replacement for component store, but at the same 425 00:37:30,719 --> 00:37:37,920 time, like the signal based store can very easily be used to serve the 426 00:37:37,920 --> 00:37:44,760 purposes that the component store was serving. But it is interesting that, like 427 00:37:44,880 --> 00:37:50,239 it's a general purpose store, but also it can be used for the specific 428 00:37:50,320 --> 00:37:54,599 case of just being a component store, whereas in the past we had a 429 00:37:54,719 --> 00:38:02,199 specific solution for local component data, which the component store. So I think 430 00:38:02,239 --> 00:38:07,760 that that was an interesting movement too. It simplifies things because you don't have 431 00:38:07,840 --> 00:38:14,519 to learn the component store and the general store, just learn a regular JRX 432 00:38:14,559 --> 00:38:19,800 stores and then you can apply that in any case you want. But yeah, 433 00:38:19,920 --> 00:38:24,280 it would be cool to see it being applied to just local component data, 434 00:38:24,440 --> 00:38:30,400 just so that people understand how they could use that for newer components that 435 00:38:30,440 --> 00:38:35,840 they're building, and also if they're just going to migrate components that we're using 436 00:38:35,880 --> 00:38:42,719 component store to it, how that would be done. So you guys have 437 00:38:42,840 --> 00:38:49,719 anything to say about this component store thing, well, component store is not 438 00:38:49,920 --> 00:38:55,000 new at all. It's not going to be replaced definitely. I think what 439 00:38:55,039 --> 00:39:01,400 the ngoids does now are right now is they sort of cover the entire market 440 00:39:01,920 --> 00:39:08,159 of ideas. You want the centralized, centralized, event driven state, okay, 441 00:39:08,239 --> 00:39:15,079 use an erroric store. You want class based store with the you know 442 00:39:16,320 --> 00:39:22,119 you want class based store with observables, Okay, you can use a component 443 00:39:22,199 --> 00:39:29,039 store and will be decentralized. Essentially. The store thing can also be decentralized 444 00:39:29,039 --> 00:39:36,159 because you can feature state, laser load feature stores. Right, it's just 445 00:39:36,400 --> 00:39:39,480 one unified store under the hood. In these other cases you have different store 446 00:39:39,519 --> 00:39:44,719 that can work with each other with dependency injection. Right. If you want 447 00:39:44,800 --> 00:39:47,920 fully functional stuff, you can go with signals. You can go with signal 448 00:39:49,400 --> 00:39:55,119 store. The cool fact actually, uh and I saw it in another suite, 449 00:39:55,119 --> 00:40:00,440 I think by Marco from the Jurics team. I saw so that you 450 00:40:00,519 --> 00:40:06,239 actually when you call signal store, it creates a class under the hood because 451 00:40:06,239 --> 00:40:15,360 it's an injectable and you can actually write your signal stores as classes. You 452 00:40:15,400 --> 00:40:22,320 can extend a class from You could say with store with this state, your 453 00:40:22,360 --> 00:40:27,480 class extends this and now you just write conventional methods in your class and hooks 454 00:40:27,519 --> 00:40:30,760 and so on. And it's pretty cool. Actually, if you don't like 455 00:40:30,800 --> 00:40:37,119 this fully functional, nested colvectional but stuff you can just extend the basis of 456 00:40:37,159 --> 00:40:40,840 your store into a class, and then in a class you can write whatever 457 00:40:40,920 --> 00:40:45,800 methods, rix methods and so on and so on and actually really cool, 458 00:40:45,000 --> 00:40:52,760 So you have essentially four approaches. You can do red ducts based event driven, 459 00:40:52,920 --> 00:40:59,239 you can do component based or driven. You can do functional signal driven, 460 00:40:59,320 --> 00:41:02,400 and you can do class based signal driven. And if you are really 461 00:41:02,440 --> 00:41:06,079 keen about it, if you have the time for that, you can actually 462 00:41:06,119 --> 00:41:12,400 do events driven with signals, either by using a select signal on the conventional 463 00:41:12,440 --> 00:41:17,480 store or fully you know, extending the signal store with reduced the res actions 464 00:41:17,519 --> 00:41:21,840 and all. You can do that. It is extensible. So what I 465 00:41:21,880 --> 00:41:28,679 think the movement here is more towards like diversity. You have every need you 466 00:41:28,760 --> 00:41:31,840 have, like you are developing a small application. Okay, you don't really 467 00:41:31,880 --> 00:41:37,920 need a full blown store, selectors features, blah blah blah. You know 468 00:41:37,119 --> 00:41:40,320 signals. You are not very good at direct jests, you don't care about 469 00:41:40,360 --> 00:41:45,800 our jests, and you don't really have many methods talking to pay hand. 470 00:41:46,079 --> 00:41:51,119 Sure, just drop a signal store, a couple or two. They can 471 00:41:51,199 --> 00:41:54,480 work together. You can inject one signal store into another. So essentially still 472 00:41:54,519 --> 00:41:59,719 have one big store if you want to. Okay, if you need something 473 00:41:59,719 --> 00:42:05,679 wrong, those story just injected it and you are up to your work. 474 00:42:06,320 --> 00:42:08,840 You don't need to know a bunch of stuff, care about a bunch of 475 00:42:09,440 --> 00:42:15,360 think about scalability and the fact that you are using these stores. You can 476 00:42:15,360 --> 00:42:22,400 always scale up to JRX store. You can create one centralized store afterwards when 477 00:42:22,519 --> 00:42:25,119 your application grows. And then you could say, ah, okay, I 478 00:42:25,119 --> 00:42:34,719 would just switch these injected stores in my components to the conventional store use like 479 00:42:34,800 --> 00:42:37,480 signal. That's it. You're still getting the same data under the hood from 480 00:42:37,480 --> 00:42:42,679 the component perspective. Nothing has changed. That's the cool thing. You can 481 00:42:42,760 --> 00:42:46,719 have this diverse approaches, pick one which you want, and I guess entiic 482 00:42:46,800 --> 00:42:52,559 data just didn't fit into any one of them. Yeah, I think the 483 00:42:52,960 --> 00:42:55,119 one thing came to your mind that this will also go going to help in 484 00:42:57,239 --> 00:43:00,679 a lot of micafent and development, like past put it to put the put 485 00:43:00,800 --> 00:43:07,159 your signal stores. And then once you finalize and or you have now multiple 486 00:43:07,199 --> 00:43:10,320 macro content and you want to maintain one store for your application, and then 487 00:43:10,920 --> 00:43:16,079 like Karvan you said, you can go with the biggest stored approach and then 488 00:43:17,159 --> 00:43:23,760 microstore approach. I think this also be possible have multiple store with signal store, 489 00:43:23,840 --> 00:43:29,199 like the store will not be related to each other, and you can 490 00:43:29,280 --> 00:43:32,679 you can just share the store in between in between your components. It entirely 491 00:43:32,840 --> 00:43:37,519 like depends on how you provide your story. If you create a story and 492 00:43:37,559 --> 00:43:43,920 provided the route your entre application has, of course you can reduplicate. I 493 00:43:43,920 --> 00:43:46,960 don't think that's a good approach. But again, you could reduplicate the global 494 00:43:46,960 --> 00:43:52,079 store by providing the store in the component. No one really does that, 495 00:43:52,159 --> 00:43:57,119 but theoretically you could. I think it's cool that you can just you know, 496 00:43:57,280 --> 00:44:06,239 say, like what I see myself possibly doing is having an event driven 497 00:44:06,239 --> 00:44:10,559 and JRX store for all the stuff, and then each component has its own 498 00:44:12,039 --> 00:44:15,480 store, its own facade if you will. But it's a signal store that 499 00:44:15,599 --> 00:44:21,079 just injects the big store, takes all it needs from it takes all the 500 00:44:21,119 --> 00:44:24,800 component data change stuff, injects it back into the component. Another component just 501 00:44:25,239 --> 00:44:29,480 has to you know, work with all these things. It's way easier on 502 00:44:29,519 --> 00:44:32,119 the unit testing stuff and the thread that I post also this some unit testing. 503 00:44:32,199 --> 00:44:38,039 It's very very easy to unit test a and JERIC signal store. So 504 00:44:38,800 --> 00:44:44,840 having this sort of interconnection with the big store and small store could work well 505 00:44:44,880 --> 00:44:47,679 in terms of union testing. Right yeah, So yeah, you can have 506 00:44:47,760 --> 00:44:52,840 multiple story or you can just have a big root signal store and a small 507 00:44:53,039 --> 00:44:57,440 local component store, and you can then choose how you work with it. 508 00:44:57,559 --> 00:45:01,679 I would prefer to combine them into one at the component level and then just 509 00:45:01,760 --> 00:45:05,880 use one store and say, I don't know, use a profile component under 510 00:45:05,880 --> 00:45:08,079 the hood that actually uses all these other stores. But I don't know it, 511 00:45:08,119 --> 00:45:10,960 I don't care about it. I just use whatever data I need for 512 00:45:12,039 --> 00:45:15,920 this component, right, and I unit test whatever need I need for this 513 00:45:15,039 --> 00:45:21,719 component. And it's easier to mock. Also, right, you don't need 514 00:45:21,719 --> 00:45:23,840 to mock this entire store. You can mock this small one that only uses 515 00:45:23,840 --> 00:45:30,039 two things from this store, and so on. You can both combined, 516 00:45:30,119 --> 00:45:36,840 recombine and so on. Yeah. Yeah. The segregation of responsor the good 517 00:45:36,920 --> 00:45:40,719 here and the components become super simple in this case. Again, in the 518 00:45:40,760 --> 00:45:45,000 thread and the example component, typescript has literally one line of code. It 519 00:45:45,079 --> 00:45:51,920 just injected store uses it all in the template. It's just a no brainer 520 00:45:52,039 --> 00:45:55,760 to see how it is both good for the readability of the component for the 521 00:45:57,360 --> 00:46:04,239 like all your component logic is its expressed in Every component is expressed uh in 522 00:46:04,320 --> 00:46:12,360 the same pattern by using the signal store approach, so your components kind of 523 00:46:12,440 --> 00:46:15,679 become more uniform. You can adopt this like an approach. Oh, my 524 00:46:15,719 --> 00:46:20,679 components just need to use a signal store for its state every time. It's 525 00:46:20,719 --> 00:46:22,920 a bit more code, but we now know all the components you know, 526 00:46:23,000 --> 00:46:27,960 conform to this. We can easily see that and something again, you can 527 00:46:28,039 --> 00:46:34,199 just use you know, component class based story class based signal store, which 528 00:46:34,239 --> 00:46:40,199 is also I like that. Like overall, I think it was a really 529 00:46:40,280 --> 00:46:45,960 positive addition to and your X. I really like the movement of going signal 530 00:46:46,000 --> 00:46:52,559 based. I think that's definitely going to It's already gonna simplify things for us 531 00:46:52,599 --> 00:46:59,719 that are like ah old Angular developers, but it's going to be even easier 532 00:46:59,800 --> 00:47:04,840 for newcomers into the framework. So I really like, I really like this 533 00:47:05,000 --> 00:47:09,679 movement. And yeah, I actually don't think I have anything else to aggregate 534 00:47:09,679 --> 00:47:14,039 to this discussion. I think we can start wrapping up. The last thing 535 00:47:14,079 --> 00:47:17,920 that I'd like to say is how much I like the functional approach that those 536 00:47:17,960 --> 00:47:23,199 libraries are going for. It's not just syntax. It makes it so much 537 00:47:23,199 --> 00:47:30,079 easier to really reuse parts of the library because you don't have to like create 538 00:47:30,119 --> 00:47:35,800 a base store and then extend it. You know, if you have parts 539 00:47:35,840 --> 00:47:40,280 of it that that you want to reuse in other stores, even if like 540 00:47:40,599 --> 00:47:44,719 you have methods that you want to reuse in other stores, you can just 541 00:47:44,760 --> 00:47:50,920 create a function that returns those those methods and then you call that function during 542 00:47:50,960 --> 00:47:57,159 the store creation, you know, kind of like with custom methods x whatever, 543 00:47:57,679 --> 00:48:00,960 and it's going to give you those methods. So I like how this 544 00:48:01,039 --> 00:48:09,239 is going. I think it's much much much easier to create reusable code. 545 00:48:09,679 --> 00:48:17,840 And yeah, I think developers just need to be cautious not to introduce dependencies 546 00:48:17,880 --> 00:48:23,000 that should not be present. You know. It's that saying copy and paste 547 00:48:23,119 --> 00:48:30,079 is better than the wronger abstraction, So you don't want to create wrong dependencies 548 00:48:30,239 --> 00:48:36,960 among your code base. But other than that, if you have a particular 549 00:48:37,119 --> 00:48:43,079 piece of code that you're repeating among all your stores, then you can just 550 00:48:43,199 --> 00:48:49,480 isolate that into functions and reuse that during the creation of all these stores instead 551 00:48:49,480 --> 00:48:52,840 of isolating in a base class and having to extend it. So I really 552 00:48:52,920 --> 00:48:58,320 like how this is going. Yeah, I think that's mostly for me. 553 00:48:58,719 --> 00:49:00,599 So if you guys don't have it anything else to add that, I think 554 00:49:00,599 --> 00:49:06,559 we can go to one very very very small thing. Just if you're working 555 00:49:06,599 --> 00:49:09,639 with rix method, make sure that all the operators and all the stuff you 556 00:49:09,679 --> 00:49:15,840 import you import from RHGS not RHGS slash operators. It won't work and you 557 00:49:15,960 --> 00:49:22,000 won't know why because there you are not inside and observable. You are actually 558 00:49:22,079 --> 00:49:28,280 creating an observable using the pipe function not the pipe method. Was a very 559 00:49:28,320 --> 00:49:32,760 big pain point for me just doing these small applications like why is this not 560 00:49:32,800 --> 00:49:37,760 working? Literally? What I what is in the you know, official blog 561 00:49:37,800 --> 00:49:42,760 post example? Why is it not working? Oh wait, maybe I need 562 00:49:42,800 --> 00:49:49,840 to use the map function rather than a map operator that goes into the pipe 563 00:49:49,880 --> 00:49:53,440 method of some observable. So yeah, be careful with that, because I 564 00:49:53,480 --> 00:49:58,360 think it's customary for us to import that stop from RGS slash operators. But 565 00:49:58,400 --> 00:50:05,920 those are different. Those are functions intended as higher order functions for existing observables 566 00:50:06,039 --> 00:50:12,679 rather than just functions that we turn observables themselves. Yeah. I think if 567 00:50:12,679 --> 00:50:19,599 someone left before this and that doing the court and hit my day is doing 568 00:50:20,440 --> 00:50:24,559 again. Come to the episode and see after fifty fifteen minutes to give you 569 00:50:24,639 --> 00:50:32,000 the solution. Okay, let's let's get to your promos then, So mine's 570 00:50:32,159 --> 00:50:37,960 going to be quick, just the default. I'm going to promote onvoids, 571 00:50:37,039 --> 00:50:44,440 so it's you and vo i d dot com uh, and we provide remote 572 00:50:44,599 --> 00:50:51,360 software and design services on a performance basis, so clients only pay after the 573 00:50:51,440 --> 00:50:58,320 tests are delivered and approved, which removes every risk that you may have by 574 00:50:58,400 --> 00:51:05,920 hiring an outsourcing agency. Also, Unvoid engineers and designers working US time zones, 575 00:51:06,000 --> 00:51:09,559 so you also don't have communication issues of like trying to talk to your 576 00:51:09,599 --> 00:51:15,840 development team and having to do that at midnight because to then that would be 577 00:51:15,920 --> 00:51:19,639 like ten am or something like that. So these are the kind of things 578 00:51:19,639 --> 00:51:25,800 that Onvoid has solved for you while still having an interesting price point. So 579 00:51:25,880 --> 00:51:31,880 if you're interested in either outsourcing your project or augmenting your staff, be sure 580 00:51:31,920 --> 00:51:37,639 to check out unavoid dot com and contact us if you're interested in that. 581 00:51:38,400 --> 00:51:43,360 So, yeah, this is gonna be my promo for today, Arman. 582 00:51:43,519 --> 00:51:50,519 How about you I show if finally enough the publication just dropped something for me 583 00:51:50,559 --> 00:51:55,639 to promote today, So the last one, I you know, notify our 584 00:51:57,239 --> 00:52:01,920 listeners that I have a book in early access about modern Angular. Certainly not 585 00:52:01,960 --> 00:52:10,480 ANGI X, but modern Angular. My new book is all about the recent 586 00:52:10,840 --> 00:52:15,239 latest school features that we have in Angular. So it is an early access. 587 00:52:15,559 --> 00:52:22,840 The last week three chapters were published and today two more arrived. And 588 00:52:22,960 --> 00:52:27,599 actually one of the chapters is kind of touching on the points that we're discussing 589 00:52:27,639 --> 00:52:35,000 today. So one chapter is about the different you know, small cool things 590 00:52:35,039 --> 00:52:43,079 that we have like host directives and the optimized the image you know, input 591 00:52:43,119 --> 00:52:46,760 transformations, required inputs, that sort of stuff. And the fifth chapter that 592 00:52:47,000 --> 00:52:53,760 brow today is about our xges urges into road package custom operators that we can 593 00:52:53,800 --> 00:53:00,320 do, how we combine it with the inject functions and so on. Oh 594 00:53:00,599 --> 00:53:04,960 yeah, let me also put the link to the book. It's an early 595 00:53:05,039 --> 00:53:12,039 access meaning meaning you can buy it with a discount, you can try it 596 00:53:12,119 --> 00:53:15,880 out. Oh well, the website is down, but whatever I will put 597 00:53:16,000 --> 00:53:22,159 I will put the link here, hopefully to results soon enough. So yeah, 598 00:53:22,679 --> 00:53:27,679 if you if you choose to read the book, hopefully you enjoy it 599 00:53:27,760 --> 00:53:31,119 and it is useful to it. Feel free to comment on the live forum 600 00:53:31,239 --> 00:53:36,760 about the book. It's still a bit of a work in progress or polishing 601 00:53:36,800 --> 00:53:40,360 it out, so and yeah, more content to drop soon, all right. 602 00:53:40,760 --> 00:53:45,239 Yeah, feel free to send that any lengths that you you'd like people 603 00:53:45,280 --> 00:53:51,079 to see in the comments section, because that's going to be sent to everyone 604 00:53:51,119 --> 00:53:58,280 that is in that's watching the live stream. All right. I'm just mentioning 605 00:53:58,280 --> 00:54:01,719 that because you said in the chat that is private to just this. All 606 00:54:01,800 --> 00:54:07,800 right, how about you service? Yeah, I think it's simple for me 607 00:54:07,840 --> 00:54:10,800 as well. I would like to promote my YouTube channel. It's fun of 608 00:54:10,920 --> 00:54:17,280 Heuristic, So please guys go ahead and past that, uh and let me 609 00:54:17,320 --> 00:54:22,599 know what you want to see more like some people are seeing me do some 610 00:54:22,760 --> 00:54:30,199 and react videos. Yeah, it depends on how many more goes there, 611 00:54:30,159 --> 00:54:37,320 so please go and check fun of puristics. All right. Okay, I 612 00:54:37,360 --> 00:54:42,760 think that's awful today for today, Thanks everyone, and I'll see you in 613 00:54:42,800 --> 00:54:43,360 the next one.