WEBVTT 1 00:00:06.360 --> 00:00:12.480 Hello everyone, Welcome to React Roundup and I hope you have a very nice 2 00:00:12.599 --> 00:00:16.800 new year. This is the podcast where we keep you updated on all things 3 00:00:16.879 --> 00:00:22.920 React related. This show is sponsored by Raygun and produced by two companies, 4 00:00:23.079 --> 00:00:26.800 Top and Doves and Onvoid. Top and Doves is very great Top and Doves 5 00:00:26.800 --> 00:00:31.239 to get top and pay and recognition while working on interesting problems and making meaningful 6 00:00:31.280 --> 00:00:36.920 community contributions. An Onvoid which offers remote design and software development services on a 7 00:00:37.000 --> 00:00:42.799 task basis, so clients only pay when tests are delivered and approved. In 8 00:00:42.840 --> 00:00:50.399 today's episode, we will talk about reactivity on JavaScript frameworks. So how are 9 00:00:50.560 --> 00:00:58.079 the other frameworks and also React, how are all the other popular frameworks dealing 10 00:00:58.159 --> 00:01:04.920 with reactivity on the front end. My name is Lucas Paganini. I'm your 11 00:01:04.920 --> 00:01:11.200 host in the podcast, and joining me in today's episode are the hosts Chris 12 00:01:11.439 --> 00:01:21.000 Ruin, Hi guys, and Peter Osa. Hello everyone. All right, 13 00:01:21.560 --> 00:01:26.840 so I can bring to the table a bit about how Angler is writing that 14 00:01:26.040 --> 00:01:32.400 wave of reactivity, especially now with signals. And I think this has been 15 00:01:33.359 --> 00:01:40.079 a conversion that like it seems that all frameworks are conversion into some sort of 16 00:01:40.280 --> 00:01:47.840 signal based approach. We saw that I believe first in solid but then we 17 00:01:47.920 --> 00:01:51.519 started seeing it popping up in every other place. It was kind of like 18 00:01:51.560 --> 00:01:59.120 when every social media started copying snapshat. So that's basically that's basically it. 19 00:02:00.400 --> 00:02:07.079 But yeah, let's of course start with react. How do we currently deal 20 00:02:07.319 --> 00:02:15.039 with reactivity? What is like the signal based approach and react? Peter, 21 00:02:15.439 --> 00:02:22.719 Okay, yeah, for react to what I think React uses the virtual dome 22 00:02:22.840 --> 00:02:25.680 and then hoisting, right, So, I don't know if a lot of 23 00:02:25.800 --> 00:02:32.479 us not about hoisting, right why javascate thinks the jazzkip concept where you can 24 00:02:32.520 --> 00:02:38.520 actually have access to a setting vailable outside the functional scope, like right, 25 00:02:38.680 --> 00:02:43.479 so we'll I think, so we act kind of works with that in its 26 00:02:43.719 --> 00:02:47.080 like maybe when you talk about your states, why U states is actually maybe 27 00:02:49.159 --> 00:02:54.039 a specific to a component we recall it this is hoisting and they a set 28 00:02:54.280 --> 00:02:59.360 to once evalues change and to get to us the virtual dome and that's what 29 00:02:59.520 --> 00:03:02.599 you So I think that's kind of like a of a view. I think 30 00:03:04.919 --> 00:03:09.400 that's just the point of I think that's what the direction I see reactivity in 31 00:03:09.439 --> 00:03:19.000 reactas technically, So yeah, that that's definitely the the status quo, right, 32 00:03:19.000 --> 00:03:28.360 now, have have you seen people doing reactivity and React in different forms? 33 00:03:28.360 --> 00:03:34.919 For example, our xgs is very popular in other frameworks to do with 34 00:03:35.080 --> 00:03:40.479 reactivity because it exposes an observable class in which you can subscribe to and listen 35 00:03:40.520 --> 00:03:46.639 to events that are emitted and et cetera. And it also does deals really 36 00:03:46.719 --> 00:03:55.800 well with asynchronous events. So our xgs is like a very powerful library for 37 00:03:57.560 --> 00:04:00.719 a lot of frameworks to do with reactivity. I know, Angler, for 38 00:04:00.759 --> 00:04:05.759 example, for a very long time, relied solely on our experience for its 39 00:04:05.840 --> 00:04:13.039 reactivity. Now it also has some native ways to do it, which is 40 00:04:13.280 --> 00:04:19.839 signals, But up until then, reactivity was just our extra ass So have 41 00:04:19.920 --> 00:04:28.959 you guys noticed people dealing with reactivity in other ways within React applications besides just 42 00:04:29.000 --> 00:04:34.399 the regular hooks? Yeah, so yeah, I've seen that as well. 43 00:04:34.519 --> 00:04:41.399 So I've seen I've seen people arectually using ours itself for reactivity and React as 44 00:04:41.399 --> 00:04:45.399 well. I think I've worked on cold business like that too, where we 45 00:04:45.560 --> 00:04:49.519 take advantage of the observa paton and then you're listening to events, and you're 46 00:04:49.560 --> 00:04:56.319 listening to events and then won't say an event is figured then you can do 47 00:04:56.439 --> 00:05:01.639 something. But I think that's the only one I can think of that I 48 00:05:01.680 --> 00:05:06.439 have seen of Chase, What have you seen any like anyone you've kind of 49 00:05:06.480 --> 00:05:12.199 come across. Yeah, I'm trying to think you guys will probably know it's 50 00:05:12.199 --> 00:05:15.720 not coming to my head right now. There's also for reducks, there's a 51 00:05:15.759 --> 00:05:20.319 library that helps you do ACYNC stuff. What is do you guys know what 52 00:05:20.360 --> 00:05:30.399 that that library is called? But they that's that's sunk saga. Yeah, 53 00:05:30.879 --> 00:05:33.680 yeah, yeah, yeah yeah. So I guess that might be a way 54 00:05:34.439 --> 00:05:41.560 of of kind of handling and kind of like pipelining acinc operations. I never 55 00:05:41.600 --> 00:05:45.000 got into it because I I know people say, like, once you get 56 00:05:45.000 --> 00:05:47.000 it, it's really awesome, but I could never. I just couldn't get 57 00:05:47.000 --> 00:05:51.279 into like the yield and the you need like these special functions and all this 58 00:05:51.319 --> 00:05:59.199 stuff. So I'm I'm still uh happily living in hook like use effect land 59 00:05:59.560 --> 00:06:03.079 for my side effects. I have seen our xjs as well, like like 60 00:06:03.160 --> 00:06:08.279 Peter said, Otherwise, I don't, I don't know, I don't. 61 00:06:08.639 --> 00:06:14.800 I can't think of anything else I've seen. Yeah, I think even Jes 62 00:06:15.120 --> 00:06:18.720 with Dogs, I think they kind of use that subscriber paton idea. What 63 00:06:18.879 --> 00:06:23.480 you're dispatching on the event and then you're listening to the event as well. 64 00:06:23.639 --> 00:06:30.240 I think that's dominantly the patterns of seen and react being used mostly like it's 65 00:06:30.360 --> 00:06:32.720 mostly dogs. If not our ages, then there has to be like you 66 00:06:32.800 --> 00:06:36.480 state or something. Yeah, so what do you think look as like if 67 00:06:36.480 --> 00:06:42.519 you come across anyone too as well, maybe anyone different from these these types. 68 00:06:44.079 --> 00:06:48.040 I was actually hoping that you guys would know because I've never seen, 69 00:06:48.480 --> 00:06:54.759 but I really wanted to figure out if there are people doing it differently. 70 00:06:55.519 --> 00:06:58.600 But I guess that's kind of a good thing, right, Like the way 71 00:06:58.680 --> 00:07:02.800 that people are dealing with reactctivity and react as very standardized, So that's actually 72 00:07:02.839 --> 00:07:08.079 good, like boring is good. If everyone was doing it differently, then 73 00:07:08.639 --> 00:07:12.600 it would be way harder for us to navigate between one project and the other. 74 00:07:13.199 --> 00:07:18.240 So yeah, let's go through some of the other frameworks then and talk 75 00:07:18.240 --> 00:07:23.399 about how they are dealing with reactivity. And by the way, we at 76 00:07:23.439 --> 00:07:31.199 no point we defined clearly what is reactivity, right, we just assume that 77 00:07:31.439 --> 00:07:38.639 the audience would know it, but just so that we are complete into what 78 00:07:38.680 --> 00:07:46.839 we are discussing. So reactivity is you being able to rerender or I would 79 00:07:47.000 --> 00:07:53.720 say, just rerender is really it's anything. It's basically like instead of you 80 00:07:53.959 --> 00:08:03.560 having to imperatively tell a variable that is like, oh man, I can't 81 00:08:03.560 --> 00:08:07.920 think of a good example. Jesus that my explanation is terrible. Let's go 82 00:08:07.040 --> 00:08:11.319 through one very simple example. Let's say you have a variable called full name 83 00:08:13.279 --> 00:08:18.800 and that is computed based on the first name and the last name. So 84 00:08:18.879 --> 00:08:22.000 every time you change the first name or the last name, you have to 85 00:08:22.040 --> 00:08:26.759 recompute the full name variable, and that can lead to issues if you suddenly 86 00:08:28.240 --> 00:08:31.680 change the first name or the last name, but then you forget to update 87 00:08:31.399 --> 00:08:39.080 the full name variable. With reactivity, you wouldn't have those problems. You 88 00:08:39.480 --> 00:08:43.360 also wouldn't have some other problems with regards to rendering that information for the user. 89 00:08:43.399 --> 00:08:52.759 But at the core, you can tell that a particular particular variable can 90 00:08:52.799 --> 00:08:56.960 be listened to, and that means that you can trigger something. You can 91 00:08:58.080 --> 00:09:01.240 have a callback, for example, to run every time that value changes, 92 00:09:01.960 --> 00:09:09.399 and that way you can solve this problem by listening to changes in the first 93 00:09:09.480 --> 00:09:15.600 name and the last name variables and then recomputing the full name when those changes, 94 00:09:15.960 --> 00:09:18.799 So that way you don't have to every time you change first name, 95 00:09:20.000 --> 00:09:24.159 remember to change the last name. Just by changing the first name, it 96 00:09:24.200 --> 00:09:31.519 will automatically trigger a change and trigger the callbacks that you registered and recompute the 97 00:09:31.960 --> 00:09:37.159 full name variable accordingly. So that's just one simple example. But this problem 98 00:09:37.279 --> 00:09:46.159 is just really nasty, Like we are probably not familiar with how painful it 99 00:09:46.320 --> 00:09:52.919 was because it's been so long that I've been doing everything reactively, but like 100 00:09:52.480 --> 00:09:58.840 six years ago, I remember doing a lot of imperative code and it was 101 00:09:58.879 --> 00:10:01.960 just so annoying. For example, a lot of bugs that were like, 102 00:10:03.399 --> 00:10:05.960 oh, you updated a variable before, got to update in this other place, 103 00:10:07.000 --> 00:10:11.519 and I was like, jah, this is so stupid, like stupid 104 00:10:13.200 --> 00:10:16.399 issues, small issues across the code base, and all of that can be 105 00:10:16.440 --> 00:10:24.279 fixed with reactivity. But the thing is, there's no universal standard to reactivity 106 00:10:24.320 --> 00:10:30.679 in JavaScript, and I mean JavaScript itself, because some other languages do have 107 00:10:31.440 --> 00:10:37.679 natives for reactivity, but JavaScript doesn't. There's a proposal to add observables to 108 00:10:37.519 --> 00:10:46.159 JavaScript, but other than that, which wasn't implemented yet, there's no native 109 00:10:46.320 --> 00:10:52.799 way in JavaScript to define how everyone should do with reactivity. It's kind of 110 00:10:52.840 --> 00:10:58.759 like how the world was before promises were standardized, so you had libraries and 111 00:11:00.080 --> 00:11:03.559 mental promises, and then you had other libraries implementing other solutions to deal with 112 00:11:03.919 --> 00:11:09.879 a synchronous responses. And this is what we're talking about. Like every framework 113 00:11:09.519 --> 00:11:15.320 brought up its own solution, and we don't know yet which one's going to 114 00:11:15.399 --> 00:11:18.720 be the winner. So probably in three years or so, we're gonna have 115 00:11:18.879 --> 00:11:22.080 some native implementation and then every framework is gonna say, okay, now we're 116 00:11:22.120 --> 00:11:26.320 just going to use the native implementation. But until then everyone's doing it differently. 117 00:11:26.799 --> 00:11:35.360 So yep, now we have proper introduction. Yeah, exactly. So 118 00:11:35.399 --> 00:11:39.159 I think maybe maybe maybe I could add in something to reactivity, right, 119 00:11:39.200 --> 00:11:43.360 so I think those three reactivity I was trying to sink up the so we're 120 00:11:43.399 --> 00:11:48.960 key for example, and made it change. Maybe I have available where I 121 00:11:48.120 --> 00:11:54.120 needed something maybe like PETA, and then i'd said to just move it up 122 00:11:54.240 --> 00:11:58.759 to lucas I want the reference of that vailable to kind of have to sync 123 00:11:58.799 --> 00:12:03.039 with the with the update, with the recent update I need. But so 124 00:12:03.080 --> 00:12:07.919 all the activity does does is to ensure that happens. Quite so it does 125 00:12:07.960 --> 00:12:09.960 it your the other Okay, maybe for example, I make a change to 126 00:12:11.039 --> 00:12:15.879 this vailable and then it could probably use the call back or listening to that 127 00:12:16.120 --> 00:12:18.399 change, and then on listening to the change, its kind of reflects to 128 00:12:18.440 --> 00:12:26.000 all lot of instances of that vailable all it could what million many many frame 129 00:12:26.039 --> 00:12:31.720 of do we render the whole right course, and render to the dumb and 130 00:12:31.000 --> 00:12:35.399 just make it to those just like more likely a very gigantic reload, so 131 00:12:35.440 --> 00:12:39.519 that everything that's updated rights. That's so I think that just how you can 132 00:12:39.639 --> 00:12:46.000 see it. Just to sink updates with those sinking data updates, we ensured 133 00:12:46.000 --> 00:12:50.399 that Okay, whatever change you make in a new whatever new change changes you 134 00:12:50.480 --> 00:12:56.480 make to always going to be reflected in wherever it's devailable or self reference, 135 00:12:56.559 --> 00:12:58.080 right, So I think that's just it occurse. Do you have anything to 136 00:12:58.120 --> 00:13:05.039 add to Yeah, I think it also comes down to I mean Lucas mentioned 137 00:13:05.080 --> 00:13:09.320 how a lot of frameworks are kind of going to this pattern, and it 138 00:13:09.480 --> 00:13:15.320 comes down to this concept of what's declarative and what's imperative. Right, So 139 00:13:16.720 --> 00:13:20.759 there's there's a nice link a link at the end of the show. But 140 00:13:20.399 --> 00:13:26.080 like Facebook was talking about why they kind of went to this reactive pattern. 141 00:13:26.080 --> 00:13:30.200 Anyway, like Lucas mentioned, like imagine, okay, maybe for just a 142 00:13:30.240 --> 00:13:33.679 full name and you have to add the last name. Okay, that works 143 00:13:33.720 --> 00:13:35.399 fine. If you have to put an if statement and like hard code it 144 00:13:35.559 --> 00:13:39.960 like is this different than I change it? But as soon as you have 145 00:13:39.360 --> 00:13:45.679 like five ten, you know, any modern application with hundreds of things that 146 00:13:45.720 --> 00:13:50.519 can potentially change, and each of those things maybe change only one or two 147 00:13:50.559 --> 00:13:54.919 of the other state variables, it becomes I mean, imperative programming is kind 148 00:13:54.960 --> 00:13:58.519 of out of the question, at least on the front end. So I 149 00:13:58.559 --> 00:14:03.240 think all that all these frameworks you know, over time of recognized this and 150 00:14:03.240 --> 00:14:07.000 and that's kind of the pattern. It's it's that they're all moving to. 151 00:14:09.440 --> 00:14:15.639 So yeah, I guess that's that's all I have. Yeah, okay, 152 00:14:15.879 --> 00:14:20.759 so beyond the introduction, all right, so let's go through how those other 153 00:14:20.840 --> 00:14:26.799 frameworks are dealing with that. So I can bring a bit about how Angler 154 00:14:26.919 --> 00:14:33.559 is dealing with that. I mentioned it a couple of times, but I'm 155 00:14:33.600 --> 00:14:39.039 really curious to know what you guys know about how other frameworks are are dealing 156 00:14:39.080 --> 00:14:45.919 with that. Like I kind of know from theory how Solid deals with that, 157 00:14:46.080 --> 00:14:48.320 But I gotta say, like I never really built anything with Solid, 158 00:14:48.639 --> 00:14:54.120 like for real, so you can't really speak much about it. But which 159 00:14:54.279 --> 00:15:01.120 frameworks did you guys experience and you can talk about how they're dealing with reactivities 160 00:15:01.519 --> 00:15:05.799 Peter, Okay, Yeah, So I think for reactivity, one that I 161 00:15:07.120 --> 00:15:11.559 kind of know about this React, and I think I've worked with that of 162 00:15:11.799 --> 00:15:16.720 View. I think the difference is that for view view users and what call 163 00:15:16.159 --> 00:15:22.279 foxy objects, and I think object is kind of like a new concept, 164 00:15:22.360 --> 00:15:28.279 right, where with a foxy object you can kind of set or get some 165 00:15:28.519 --> 00:15:33.600 variable. So I think View kind of combined media reactivity with frozy objects. 166 00:15:33.639 --> 00:15:37.840 So most of the time when you're doing reactive states with View, you're kind 167 00:15:37.840 --> 00:15:41.679 of using like ay object reference, right, So once it changes, then 168 00:15:41.720 --> 00:15:48.600 it's not rigas it changed to the original object you wanted to change. Yeah, 169 00:15:48.639 --> 00:15:52.240 I think that's how it works for for View. Then React, I 170 00:15:52.279 --> 00:15:56.919 think reacts on this kind of you're used hoisting with the virtud and constant revend. 171 00:15:56.919 --> 00:16:00.159 That's still kind of events based, right, doing with events I made 172 00:16:00.159 --> 00:16:04.840 this change, and then it's with twigger, so it's listed, there's some 173 00:16:06.360 --> 00:16:10.000 I'm listening to the changes made to the state and then courses everywhere in the 174 00:16:10.600 --> 00:16:14.120 Yeah, I think apart from that, then with signals yeah, I don't 175 00:16:14.120 --> 00:16:18.480 really have like a very good grasp SIG and like you said, I'm just 176 00:16:18.600 --> 00:16:22.960 on the same boat as we have. It's still right, it's just it's 177 00:16:22.840 --> 00:16:27.480 knowledge. But then I think Angla spe is kind of quite you have before 178 00:16:27.559 --> 00:16:33.519 we active signals, but I'm still I'm still not I've still not gotten them 179 00:16:33.600 --> 00:16:37.279 of it yet. But then I think for ALEXJX, because I've kind of 180 00:16:37.320 --> 00:16:41.399 worked with more with Angler, good business use that uses the lexs button. 181 00:16:41.519 --> 00:16:45.159 Yeah, I think that is still events based. While you're listening to an 182 00:16:45.159 --> 00:16:49.799 event and then you're listening to changes on the veable and once that happens, 183 00:16:49.840 --> 00:16:55.360 she just broadcasting to other instances our name updates, right, So I think 184 00:16:55.360 --> 00:16:59.200 that's technically the ones I've worked with all CRIZ. Do you have an idea 185 00:16:59.200 --> 00:17:03.599 of any one like any how do you work with your activity kind of? 186 00:17:04.880 --> 00:17:08.759 Yeah, I can talk about what I mentioned briefly as we were talking before 187 00:17:08.799 --> 00:17:12.559 the show. I was looking into these this concept of ruins in spelt, 188 00:17:15.480 --> 00:17:19.519 so they also have kind of moved or or added rather thinking spelt three or 189 00:17:19.559 --> 00:17:25.200 whatever version they're on now. They have just here this like their their way 190 00:17:25.240 --> 00:17:29.680 of lettings. Felt know that it's a reactive variable is this dollar signed state? 191 00:17:30.160 --> 00:17:33.519 So to me, it's basically like a stealing used state. Uh, 192 00:17:33.559 --> 00:17:37.000 and it's ironic. It's exactly what I was just talking about that. I 193 00:17:37.079 --> 00:17:41.680 promise I didn't read this before the before what I was saying before about like 194 00:17:41.920 --> 00:17:45.440 complex apps, because they say, like, okay, at first glance, 195 00:17:45.720 --> 00:17:48.200 I'm reading directly from their documentations, is this this move looks like a step 196 00:17:48.359 --> 00:17:52.519 back. Shouldn't we just use let count and automatically make it reactive? And 197 00:17:52.559 --> 00:17:56.799 they say, well, no, the reality is that applications grow in complexity, 198 00:17:56.839 --> 00:18:00.880 figuring out which values are reactive and which aren't can get tricky. So 199 00:18:00.920 --> 00:18:06.680 they now have moved where they want you to specifically state this case is count. 200 00:18:06.720 --> 00:18:10.359 Yeah, that count is with this dollar sign state, and we want 201 00:18:10.400 --> 00:18:15.640 that to be reactive in our in our component. So yeah, that's that's 202 00:18:15.680 --> 00:18:19.920 all I have. I too, like you guys, I'm guilty of only 203 00:18:21.000 --> 00:18:26.960 knowing React here on the React podcast, so I don't have much experience with 204 00:18:26.960 --> 00:18:33.960 with with many other front end frameworks. I think one thing that you touched 205 00:18:33.480 --> 00:18:38.599 that is kind of important is this convention about using a dollar sign as a 206 00:18:38.640 --> 00:18:47.720 post fix on reactive values. It's not enforced everywhere, but I've seen a 207 00:18:47.799 --> 00:18:52.640 lot of different frameworks having developers adopting this convention, and I think it really 208 00:18:52.759 --> 00:19:00.000 helps to make it clear that the variable is indeed reactive. So yeah, 209 00:19:00.000 --> 00:19:06.759 an angular this hasn't catched yet, just because it already catched for observables, 210 00:19:06.799 --> 00:19:10.519 like we always in Angler, we got used to using dollar sign at the 211 00:19:10.599 --> 00:19:14.519 end for observables, but now that we also have signals, we don't want 212 00:19:14.559 --> 00:19:18.640 to use it for signals because people are gonna think that it's unobservable. Like 213 00:19:18.680 --> 00:19:22.720 they're both reactive, but they need to be consumed in different ways. So 214 00:19:23.839 --> 00:19:29.240 with Angler, people are not adding a dollar sign at the end, but 215 00:19:29.400 --> 00:19:33.000 they it's still not a problem because we have to call the value like a 216 00:19:33.039 --> 00:19:37.400 signal in Angler is a function, you literally call it, so you have, 217 00:19:37.519 --> 00:19:44.599 for example, first name, you would have first name open and closed 218 00:19:44.599 --> 00:19:51.039 parentheses. You're actually calling the variable and that returns its value. And it 219 00:19:51.119 --> 00:19:57.799 also creates a connection between the thing that is rendering it and the signal itself. 220 00:19:57.839 --> 00:20:02.119 So every time that the signal changes, Angler already knows that it needs 221 00:20:02.160 --> 00:20:10.160 to re render that particular part of the UI or even the within the typescript 222 00:20:10.160 --> 00:20:15.640 code itself. If you have if you call it the computed, Angler has 223 00:20:15.680 --> 00:20:22.559 a computed function, and then this computed function takes a callback. So imagine 224 00:20:22.599 --> 00:20:26.480 that you write computed and then you call it, and you pass a callback. 225 00:20:26.759 --> 00:20:32.200 Within this callback, you can just use signals as normal, and Angler 226 00:20:32.240 --> 00:20:40.440 will automatically understand that this function depends on those signals, so when they change, 227 00:20:41.039 --> 00:20:48.640 that function will automatically be triggered. So it's it's very smart, which 228 00:20:48.839 --> 00:20:55.640 is a bit different from the explicitliness of React effects, where you need to 229 00:20:55.880 --> 00:21:02.559 explicitly say like hey, rerendous effect when and those values change, you know, 230 00:21:02.720 --> 00:21:04.599 kind of like they are keys and if the key change, then you 231 00:21:06.039 --> 00:21:11.920 rerun this. Angular does that automatically, So I think that solves a lot 232 00:21:11.920 --> 00:21:15.799 of issues because with React we can just forget to add I've seen like nasty 233 00:21:15.839 --> 00:21:21.160 bugs that took me out why to figure out what it was, and it 234 00:21:21.200 --> 00:21:29.160 was just a person forgot to add a variable into the effects array of dependencies. 235 00:21:29.240 --> 00:21:33.400 So it's really nice that we don't have this problem with Angler. Some 236 00:21:33.440 --> 00:21:38.480 people complain it at the beginning because they were accustomed to how React does it, 237 00:21:38.519 --> 00:21:41.720 and they were like, oh yeah, but you're not being explicit like 238 00:21:42.400 --> 00:21:49.480 this is a bit too magical, but it should be. A framework should 239 00:21:49.519 --> 00:21:56.240 provide some level of magic. Otherwise, why are you using it if you're 240 00:21:56.319 --> 00:22:00.720 going to type a lot of boilerplate all the time. So yeah, that's 241 00:22:00.720 --> 00:22:07.160 basically how this is being handled on Angular. On the Angular side, I 242 00:22:07.319 --> 00:22:15.920 do really like another convention which is used as a prefix, so React standardize 243 00:22:15.920 --> 00:22:19.759 that with hooks, so every time a declatter hook is like use something. 244 00:22:21.519 --> 00:22:26.160 And I'm trying to push this convention for Angular too, because Angular also has 245 00:22:26.200 --> 00:22:33.759 this concept of functions that can be injected, because you can just use the 246 00:22:33.880 --> 00:22:40.960 inject function internally within the function. And then that creates a problem because just 247 00:22:41.000 --> 00:22:45.079 to give you a bit of context without it is becoming super complex. The 248 00:22:45.319 --> 00:22:53.319 inject function in Angular can only be called if you are at a component constructor 249 00:22:53.440 --> 00:22:57.759 or, like it can only be called within an injection context. But to 250 00:22:57.880 --> 00:23:03.000 explain what it's an action context would be too complex. So let's just imagine 251 00:23:03.039 --> 00:23:07.839 that you can only call it in the component constructor. Okay, so you 252 00:23:07.880 --> 00:23:11.920 can only call it when the component's being constructed, all right, So what 253 00:23:12.240 --> 00:23:19.279 the problem is if you call a function that internally call this cause this inject 254 00:23:19.359 --> 00:23:25.960 function, and you don't know that this function calls the inject function internally, 255 00:23:26.440 --> 00:23:30.200 then you don't know that you can only call it in the constructor and you 256 00:23:30.279 --> 00:23:36.799 might call it at a later point at which it will not have the injection 257 00:23:36.960 --> 00:23:41.440 context, and then it's going to fail. So what I'm trying to push 258 00:23:41.000 --> 00:23:47.880 forward as a convention is to always perfect those functions with use, and then 259 00:23:48.000 --> 00:23:51.920 if the function starts with use, you already know that you can only use 260 00:23:51.960 --> 00:23:56.160 it if you are within an injection context. Otherwise it's just going to fail. 261 00:23:56.640 --> 00:24:00.680 So those two conventions are really helpful. Dollar sign at the end and 262 00:24:00.720 --> 00:24:04.799 the use prefix. Yeah, I think I think you bring up a good 263 00:24:04.799 --> 00:24:11.319 point there with I think even with these kind of these whatever you want to 264 00:24:11.359 --> 00:24:17.359 call it magic or syntactic sugar, even with reactivity, you're always i mean, 265 00:24:17.400 --> 00:24:19.960 we're always doing this as software engineers, but you're always fighting against complexity. 266 00:24:21.079 --> 00:24:26.640 You mentioned you've you've seen some nasty bugs, and I've also seen some 267 00:24:26.799 --> 00:24:30.599 as well. And also just the hooks themselves can get really nasty and messy, 268 00:24:30.680 --> 00:24:34.599 right because uh, you know, you have maybe have dozens of dependencies 269 00:24:34.680 --> 00:24:41.279 and and maybe one is not even used, So I think, I think 270 00:24:41.599 --> 00:24:45.160 what is still important probably regardless of framework, but I know it's something React 271 00:24:45.200 --> 00:24:52.680 pushes is like your own how you compose the hooks themselves. So and I've 272 00:24:52.759 --> 00:24:55.559 I've been guilty of that. I've looked at some of my hooks and oh, 273 00:24:55.680 --> 00:24:59.599 okay, actually, you know these, I'm kind of mixing, you 274 00:24:59.599 --> 00:25:03.799 know, I'm mixing reactivity again. It's this kind of disadvantage that React is 275 00:25:04.480 --> 00:25:08.119 disadvantage and advantage that reacts so easy to write. Sometimes you end up just 276 00:25:08.200 --> 00:25:12.559 quickly putting together hook and you get way too many dependencies or whatever. But 277 00:25:12.960 --> 00:25:15.759 if you take a step back and you look at, you know, the 278 00:25:15.799 --> 00:25:22.359 composition of your hooks, because this is probably more React advice, but there's 279 00:25:22.359 --> 00:25:26.079 probably simplifications that you can make. But but you talking about these these things 280 00:25:26.160 --> 00:25:30.799 in Angular, it makes me wonder if now there will be like almost like 281 00:25:30.799 --> 00:25:34.559 a third generation in React. So like going from you know, we had 282 00:25:34.559 --> 00:25:38.000 the class components that may have hooks, I wonder if or maybe you know, 283 00:25:38.079 --> 00:25:41.160 maybe it is by design they should be explicit. But I wouldn't be 284 00:25:41.200 --> 00:25:48.079 surprised that there's some sort of other abstraction layer where somehow you know it would 285 00:25:48.119 --> 00:25:51.920 save so many beginners from you know, we all have seen that infinite rendering 286 00:25:51.960 --> 00:25:55.440 thing right where it's just as simple as leaving out that array and then you're 287 00:25:55.480 --> 00:25:59.319 just you're just infinitely rending your components. Wow, what's going on? So 288 00:25:59.359 --> 00:26:03.920 I wonder if if there's something on the horizon would be quite interesting. Yeah, 289 00:26:03.920 --> 00:26:07.240 I just just wanted to add that in. I don't know, I 290 00:26:07.279 --> 00:26:10.920 don't know else where we want to go from there. I don't know if 291 00:26:10.279 --> 00:26:15.839 if you had some comments too, yeah, like yeah, I agree with 292 00:26:15.759 --> 00:26:19.480 so they just they need to be a way for you to actuably know what's 293 00:26:19.519 --> 00:26:23.359 like since yeah, since the activity looks like magic a lot, like we 294 00:26:23.480 --> 00:26:29.519 need to know how to kind of differentiate this reactively well this job. So 295 00:26:29.559 --> 00:26:33.519 I've worked a lot of clothes and so many kind of boiler plates and confusing 296 00:26:33.599 --> 00:26:37.599 coulde yeah most of the time get that A lot of many could business where 297 00:26:38.119 --> 00:26:42.160 it kind of confused, how like especially in Angola, Like I think look 298 00:26:42.200 --> 00:26:47.279 as get the example way I've actually seen they coulde biz were by observable, 299 00:26:47.559 --> 00:26:52.400 not even with dollar. So I'm just litally and confusion like whoa, I 300 00:26:52.559 --> 00:26:56.359 know this? Like whoa? And yeah, so I think the conversion is 301 00:26:56.440 --> 00:27:00.400 very important. Just to know how like what it is, right, is 302 00:27:00.480 --> 00:27:03.839 kind of very important for identification, right, And yeah, I think over 303 00:27:03.880 --> 00:27:07.920 all, yeah, I think that's actually very important. And I think one 304 00:27:07.960 --> 00:27:11.200 thing we need to know about the activity is that for for us, so 305 00:27:11.200 --> 00:27:15.359 I kind of actually work to work with reactivity better. I feel we need 306 00:27:15.359 --> 00:27:19.519 to know the underlying principle behind reactivity in any framework were using, right, 307 00:27:19.640 --> 00:27:23.759 So that why most of the time I usually try to just look at their 308 00:27:23.880 --> 00:27:29.519 underline principle. Okay, yeah, I know for react or is it working 309 00:27:29.599 --> 00:27:34.200 with one javasket, I concept that maybe something new, Okay, Like I 310 00:27:34.599 --> 00:27:41.000 gave an illustration in the beginning for view whereby we use it use kind of 311 00:27:41.400 --> 00:27:48.480 the objects and kind of using for your objects and then kind of brigging like 312 00:27:48.559 --> 00:27:52.359 an observer pattern with it. Kind of I think signals work with that with 313 00:27:52.480 --> 00:27:56.720 that similarly as well, I think it's kind of signals to us in signal. 314 00:27:56.839 --> 00:28:00.880 But I've not really kind of like extensively read about it. Kind I 315 00:28:00.880 --> 00:28:03.160 don't really have more, but I think it's very much important, even for 316 00:28:03.160 --> 00:28:07.200 for React. For React there's on every form of jask developer, so those 317 00:28:07.319 --> 00:28:11.839 know the principle of reactivity in those frameworks. For example, you give an 318 00:28:11.880 --> 00:28:18.079 example of use effect and then I think I think the mother moth the reacting 319 00:28:18.240 --> 00:28:23.240 gave is setting. I think they adopted a post on the right like why 320 00:28:23.279 --> 00:28:27.119 we shouldn't be kind of used environing might not need a use effect. I 321 00:28:27.119 --> 00:28:32.799 think I would the link on the I think I adopted on the chat right, 322 00:28:33.200 --> 00:28:36.599 so you might not need a use effect for certain things we are trying 323 00:28:36.640 --> 00:28:41.359 to kind of use the effects and then adding some dependency are just some values 324 00:28:41.359 --> 00:28:45.240 in the dependency. So I think one thing we need to do this the 325 00:28:45.519 --> 00:28:51.000 underline principle of reactivity of those frameworks and how to use the kind of I 326 00:28:51.039 --> 00:28:55.359 think that's kind of very important. So Chris, what do you think that 327 00:28:55.599 --> 00:28:57.920 like maybe piece for or issues that a lot of people face, we're using 328 00:28:57.920 --> 00:29:03.480 the activity maybe a sespecially in React you work with as well. Yeah, 329 00:29:03.759 --> 00:29:10.559 I think it comes with with those kind of special magic. I mean usually 330 00:29:10.599 --> 00:29:15.319 with magic you pay for for special rules. So I know React, I'm 331 00:29:15.319 --> 00:29:18.799 sure it's still somewhere in their docks. They have like that rules of Hooks 332 00:29:18.880 --> 00:29:23.079 page, right, So I mean you you get huge advantages, but there's 333 00:29:23.079 --> 00:29:27.039 stuff you just can't do like you can't put a hook within a hook. 334 00:29:27.519 --> 00:29:33.519 That's like one rule. And also that what what you were mentioning, Peter 335 00:29:33.680 --> 00:29:37.400 is what came to mind is also how you update even just a simple state 336 00:29:37.480 --> 00:29:41.720 variable with in React. Right, so you're I'm sure it's similar in most 337 00:29:41.720 --> 00:29:45.799 frameworks, but in React you you typically want a fresh object, right, 338 00:29:45.799 --> 00:29:49.319 You're not supposed to mutate, you're not supposed to append directly do an array 339 00:29:49.359 --> 00:29:53.160 for example. The fix is easy, right you You you create a new 340 00:29:53.240 --> 00:29:57.359 ray and a new array as you said the state. So yeah, small 341 00:29:57.359 --> 00:30:02.160 things like that, but it's a really good point that you need to whatever 342 00:30:02.240 --> 00:30:06.079 framework it is, and unfortunately they're usually framework specific, but you should know 343 00:30:06.119 --> 00:30:11.839 those those details to avoid confusing, confusing bugs. And that's probably like what 344 00:30:11.960 --> 00:30:15.880 Lucas mentioned in in Angular apparently this inject Unfortunately I can't speak much more to 345 00:30:15.920 --> 00:30:19.079 it, but it seems like that's rue, like you can only use certain 346 00:30:19.519 --> 00:30:26.160 things in certain context. So yeah, that's what that's as well. So 347 00:30:26.319 --> 00:30:30.759 look as speaking of like, I think I like a general like also as 348 00:30:30.799 --> 00:30:33.759 a confusional, I think it's more like a debits because I've had I kind 349 00:30:33.759 --> 00:30:37.759 of have digital love they look like this before, like the aspect of do 350 00:30:37.839 --> 00:30:41.599 you think I think it's based on the activity as well? Do you think 351 00:30:41.920 --> 00:30:47.240 set state or you STI it is synchrons or synchronos. Yeah, Like the 352 00:30:47.319 --> 00:30:51.920 answer for that, like because I kind of get that a lot on reactivity, 353 00:30:52.079 --> 00:30:56.640 I think so many people argue that because of the way you stick to 354 00:30:56.640 --> 00:31:02.000 work. So it's React, it's kind of synchrons some seats. So what 355 00:31:02.039 --> 00:31:08.559 do you think, like from working with React at least? Yeah, Yeah, 356 00:31:10.440 --> 00:31:18.200 first, like that's that's a really good question, and this is not 357 00:31:18.319 --> 00:31:26.000 even just specific to React, like other frameworks also also get into this debate. 358 00:31:26.599 --> 00:31:32.799 And basically the thing here is, at one point, you when you 359 00:31:32.880 --> 00:31:38.119 think of code being synchronous, you think that like you call it, you 360 00:31:38.240 --> 00:31:44.519 call the function, and everything that you're doing right now just stops, and 361 00:31:44.599 --> 00:31:48.079 then it goes round that function and Danny comes back and runs the rest of 362 00:31:48.119 --> 00:31:51.240 your cup. That's what we generally think about when we say the code is 363 00:31:51.279 --> 00:31:59.160 synchronous. But the thing is when we're talking about reactivity, then people started 364 00:31:59.200 --> 00:32:09.039 giving different meanings to sink and a sync because you can technically have a synchronous 365 00:32:09.200 --> 00:32:15.720 refresh or an asynchronous refresh, and if you think too much about it, 366 00:32:15.799 --> 00:32:20.839 you're just gonna go mad because it doesn't really make that much sense, Like 367 00:32:21.480 --> 00:32:24.079 if you stop to think about it, like everything that you're executing is going 368 00:32:24.160 --> 00:32:30.279 to be executed and this other thing that you called is only going to be 369 00:32:30.319 --> 00:32:35.640 executed afterwards. So that's kind of like the definition of asynchronous, right, 370 00:32:36.079 --> 00:32:42.279 So why are we debating if it is synchronous or not? But the question 371 00:32:42.359 --> 00:32:46.240 I think is less about it being synchronous or not, but more about at 372 00:32:46.319 --> 00:32:58.359 which point does the JavaScript run time decides to execute that callback, because there 373 00:32:58.440 --> 00:33:07.400 are many things that happen within those idle moments in which your code is quote 374 00:33:07.480 --> 00:33:12.839 unquote not running. Like there's always something running, right, the browser is 375 00:33:12.920 --> 00:33:15.279 running, even if your code itself is not running. There are a lot 376 00:33:15.279 --> 00:33:22.400 of listeners, there are a lot of other stuff going on. The user 377 00:33:22.000 --> 00:33:27.680 is scrolling through the application, so something is clearly running, but your code 378 00:33:27.799 --> 00:33:34.160 is not running anymore. So what's going on is that the browser has stages 379 00:33:34.720 --> 00:33:38.799 and basically like it's going to execute your code, and while it is synchronously 380 00:33:38.880 --> 00:33:47.039 executing your code, it can't repaint the page. But once your code stops, 381 00:33:47.559 --> 00:33:52.119 then it will repaint the page, it will refresh, and then it 382 00:33:52.200 --> 00:33:58.960 will it might like trigger another code that you have, like maybe it's going 383 00:33:59.000 --> 00:34:04.079 to trigger an event you have, or you are listening to request animation frames 384 00:34:04.119 --> 00:34:08.239 something like that. Now, when we talk about hooks being synchronous or not, 385 00:34:08.800 --> 00:34:13.639 this is what we're referring to. It's like, okay, of course, 386 00:34:14.079 --> 00:34:20.320 when you call set value, when you call set state, the rest 387 00:34:20.360 --> 00:34:30.960 of your component render code is going to finish running before React rerenders or retriggers 388 00:34:30.960 --> 00:34:38.920 your component with new with the new value. But when is React going to 389 00:34:39.079 --> 00:34:45.000 trigger this rerender? That's the question. And what a lot of people are 390 00:34:45.039 --> 00:34:53.559 calling synchronous is when the code is re rendered before the browser actually has a 391 00:34:53.639 --> 00:35:00.800 chance to render. So it's kind of like the framework triggers this recalculate of 392 00:35:00.920 --> 00:35:07.960 the UI before the browser has time to really render the UI, and that's 393 00:35:07.079 --> 00:35:15.519 kind of like being called as synchronous. And when it waits for the next 394 00:35:15.000 --> 00:35:22.079 tech or the next I don't know if sick is the right technical way to 395 00:35:22.199 --> 00:35:25.920 call it, but there is like the right name to call. The next 396 00:35:27.280 --> 00:35:31.360 time that the brother is going to do something, then we're calling it asynchronous, 397 00:35:31.400 --> 00:35:36.840 which is what our XGS by default does, but you can also configure 398 00:35:36.920 --> 00:35:45.320 our XGS to run in an immediate way. So yeah, all the context 399 00:35:45.440 --> 00:35:49.079 to say, I think there are both a synchronous ways, and we just 400 00:35:49.159 --> 00:35:53.119 need to stop calling it sync because it's just super confusing to everyone. So 401 00:35:53.199 --> 00:36:00.960 we should just make it clear that it is asynchronous. But uh, it 402 00:36:02.440 --> 00:36:07.840 hyder happens at this point of the browser event or it happens at this other 403 00:36:07.920 --> 00:36:12.280 point, so we've got to figure out another way to refer to that. 404 00:36:12.559 --> 00:36:15.599 Yeah, my only comment there, I think I would have to look into 405 00:36:15.639 --> 00:36:20.320 the at least from React, like the use state it's super I mean you 406 00:36:20.360 --> 00:36:23.679 have to like at this end of the day, it's JavaScript is single threaded, 407 00:36:23.800 --> 00:36:28.000 right, so I think even yeah, looking into the source code of 408 00:36:28.039 --> 00:36:32.639 youse state, you would assume there's like some sort of queue, but yeah, 409 00:36:32.679 --> 00:36:37.199 like you said, like you know, there could be other things going 410 00:36:37.239 --> 00:36:40.960 on. And then it really comes down to probably not even React or any 411 00:36:40.960 --> 00:36:45.880 framework, but like what what the the JavaScript engine wants to do, right, 412 00:36:45.960 --> 00:36:52.000 and what thinks is most efficient? Right? I mean yeah, so 413 00:36:52.559 --> 00:36:57.800 yeah, you're probably right. You know, you can there's probably tricks where 414 00:36:58.239 --> 00:37:01.159 or there's there's ways you can force things or try to get them to be 415 00:37:01.679 --> 00:37:06.400 as sync or as ACYNC as possible. But at the end of the day, 416 00:37:06.440 --> 00:37:08.119 I think if you if you really get into complexity, you're kind of 417 00:37:08.599 --> 00:37:15.800 victim to Yeah, just the the JavaScript engine OPTI trying to optimize as best 418 00:37:15.800 --> 00:37:22.840 it can. Not to speak about web workers or things like that, but 419 00:37:22.920 --> 00:37:28.599 that's what we can do for another episode. Okay, I think that was 420 00:37:29.119 --> 00:37:35.320 enough talk about reactivity, So let's start wrapping up, unless Chris, if 421 00:37:35.320 --> 00:37:38.679 you have anything you'd like to mention before we start wrapping up. No, 422 00:37:40.199 --> 00:37:50.039 okay, all right, so before we we officially stop, let's do quick 423 00:37:50.119 --> 00:37:55.079 promos. So I'm just gonna plug on Void. So, as I as 424 00:37:55.119 --> 00:38:01.199 mentioned in the beginning, on Void is a design and software company. You 425 00:38:01.280 --> 00:38:07.559 can hire andvoid professionals to work for a company remotely. And the interesting thing 426 00:38:07.760 --> 00:38:12.679 about on avoid in comparison to other companies that provide the same services, is 427 00:38:12.719 --> 00:38:16.920 that you have the option to hire on a task based manner. So what 428 00:38:16.960 --> 00:38:22.800 the means is you only pay when tasks are delivered. Sure, that's you've 429 00:38:22.840 --> 00:38:29.159 seen that thus far, but only when they are delivered and approved. So 430 00:38:29.239 --> 00:38:32.119 if they are delivered but they're not up to the standards of your company. 431 00:38:32.239 --> 00:38:37.679 Then you can just keep requesting changes until it is up to your standards, 432 00:38:37.880 --> 00:38:40.440 and you're only going to pay once you really approve it. So that's a 433 00:38:40.639 --> 00:38:50.800 major differentiator, and it makes companies much safer to outsource their parts of their 434 00:38:50.880 --> 00:38:54.360 design and development teams, knowing that they're not going to lose any equality by 435 00:38:54.400 --> 00:38:59.880 doing so. So yeah, if you're interested on that is you and vo 436 00:39:00.039 --> 00:39:04.840 Id dot Comcovoid dot com. So yeah, how about you, Chris. 437 00:39:05.159 --> 00:39:09.079 I think I'm just gonna promo the link I mentioned to this the really nice 438 00:39:09.119 --> 00:39:14.960 presentation by Facebook. It goes into quite a few topics, a little bit 439 00:39:14.960 --> 00:39:20.599 what we talked about today on reactivity of course, and also imperative versus declarative, 440 00:39:20.639 --> 00:39:24.440 and also into the kind of I think what eventually became reducs, this 441 00:39:24.599 --> 00:39:30.039 concept of the flux pattern basically all the problems they ran into with growing complexity 442 00:39:30.039 --> 00:39:35.280 in their apps and how they kind of found all these patterns and why they 443 00:39:35.280 --> 00:39:37.800 still use them today on the front end. So really really cool video. 444 00:39:38.159 --> 00:39:43.199 They have like three or four different devs talk about, you know, certain 445 00:39:43.239 --> 00:39:49.480 parts of what they ran into throughout their projects. Nice. Nice How about 446 00:39:49.480 --> 00:39:53.159 you, Peter. Okay, Yeah, so I have like an mdan link 447 00:39:53.199 --> 00:40:00.400 of chats right about like hoisting through I think most of them time, I 448 00:40:00.440 --> 00:40:06.880 feel on one of the main concept about from how did the reactive how reactive 449 00:40:06.880 --> 00:40:10.239 state walks with you have don't kind of works with hoisting right, So I 450 00:40:10.280 --> 00:40:15.400 think it's the concept that's kind of failing. Most people don't have on the 451 00:40:15.440 --> 00:40:19.760 build a bit kind of music kind of you don't know like that we use 452 00:40:19.840 --> 00:40:22.519 it on this is how it works, and this is how we act kind 453 00:40:22.559 --> 00:40:25.800 of work with stags with right kind of So I think I just I will 454 00:40:25.880 --> 00:40:30.320 just drope a link on hoisting and then also they see the link of yeah, 455 00:40:30.360 --> 00:40:35.400 I dropped earlier, but you might not need music effects, So most 456 00:40:35.400 --> 00:40:38.960 of the time we just kind of use the effects for everything we really not 457 00:40:39.000 --> 00:40:45.199 need. Issue I think are the two links I have kind of yeah, 458 00:40:45.519 --> 00:40:50.880 okay, and we put them into the comments section, so if you're watching 459 00:40:51.239 --> 00:40:55.960 this on YouTube or Facebook linked and then you will be able to see those 460 00:40:57.039 --> 00:41:00.039 links in the comment section. If not, they're probably in the show notes. 461 00:41:00.679 --> 00:41:06.920 So yeah, okay, I don't think I have anything else to contribute 462 00:41:06.920 --> 00:41:12.639 to this discussion. So guys, thank you so much. It was good 463 00:41:12.800 --> 00:41:17.320 for us to have a podcast again because for the last few weeks it was 464 00:41:17.360 --> 00:41:21.039 really hard for us to find time, like the end of the year, 465 00:41:21.159 --> 00:41:23.559 things like that. So it's good to be back, good to have you 466 00:41:23.599 --> 00:41:30.000 guys back. So yeah, happy New Year for everyone, and I'll see 467 00:41:30.039 --> 00:41:31.239 you in the next one.