Hello everyone, Welcome to React Roundup and I hope you have a very nice
new year. This is the podcast where we keep you updated on all things
React related. This show is sponsored by Raygun and produced by two companies,
Top and Doves and Onvoid. Top and Doves is very great Top and Doves
to get top and pay and recognition while working on interesting problems and making meaningful
community contributions. An Onvoid which offers remote design and software development services on a
task basis, so clients only pay when tests are delivered and approved. In
today's episode, we will talk about reactivity on JavaScript frameworks. So how are
the other frameworks and also React, how are all the other popular frameworks dealing
with reactivity on the front end. My name is Lucas Paganini. I'm your
host in the podcast, and joining me in today's episode are the hosts Chris
Ruin, Hi guys, and Peter Osa. Hello everyone. All right,
so I can bring to the table a bit about how Angler is writing that
wave of reactivity, especially now with signals. And I think this has been
a conversion that like it seems that all frameworks are conversion into some sort of
signal based approach. We saw that I believe first in solid but then we
started seeing it popping up in every other place. It was kind of like
when every social media started copying snapshat. So that's basically that's basically it.
But yeah, let's of course start with react. How do we currently deal
with reactivity? What is like the signal based approach and react? Peter,
Okay, yeah, for react to what I think React uses the virtual dome
and then hoisting, right, So, I don't know if a lot of
us not about hoisting, right why javascate thinks the jazzkip concept where you can
actually have access to a setting vailable outside the functional scope, like right,
so we'll I think, so we act kind of works with that in its
like maybe when you talk about your states, why U states is actually maybe
a specific to a component we recall it this is hoisting and they a set
to once evalues change and to get to us the virtual dome and that's what
you So I think that's kind of like a of a view. I think
that's just the point of I think that's what the direction I see reactivity in
reactas technically, So yeah, that that's definitely the the status quo, right,
now, have have you seen people doing reactivity and React in different forms?
For example, our xgs is very popular in other frameworks to do with
reactivity because it exposes an observable class in which you can subscribe to and listen
to events that are emitted and et cetera. And it also does deals really
well with asynchronous events. So our xgs is like a very powerful library for
a lot of frameworks to do with reactivity. I know, Angler, for
example, for a very long time, relied solely on our experience for its
reactivity. Now it also has some native ways to do it, which is
signals, But up until then, reactivity was just our extra ass So have
you guys noticed people dealing with reactivity in other ways within React applications besides just
the regular hooks? Yeah, so yeah, I've seen that as well.
So I've seen I've seen people arectually using ours itself for reactivity and React as
well. I think I've worked on cold business like that too, where we
take advantage of the observa paton and then you're listening to events, and you're
listening to events and then won't say an event is figured then you can do
something. But I think that's the only one I can think of that I
have seen of Chase, What have you seen any like anyone you've kind of
come across. Yeah, I'm trying to think you guys will probably know it's
not coming to my head right now. There's also for reducks, there's a
library that helps you do ACYNC stuff. What is do you guys know what
that that library is called? But they that's that's sunk saga. Yeah,
yeah, yeah, yeah yeah. So I guess that might be a way
of of kind of handling and kind of like pipelining acinc operations. I never
got into it because I I know people say, like, once you get
it, it's really awesome, but I could never. I just couldn't get
into like the yield and the you need like these special functions and all this
stuff. So I'm I'm still uh happily living in hook like use effect land
for my side effects. I have seen our xjs as well, like like
Peter said, Otherwise, I don't, I don't know, I don't.
I can't think of anything else I've seen. Yeah, I think even Jes
with Dogs, I think they kind of use that subscriber paton idea. What
you're dispatching on the event and then you're listening to the event as well.
I think that's dominantly the patterns of seen and react being used mostly like it's
mostly dogs. If not our ages, then there has to be like you
state or something. Yeah, so what do you think look as like if
you come across anyone too as well, maybe anyone different from these these types.
I was actually hoping that you guys would know because I've never seen,
but I really wanted to figure out if there are people doing it differently.
But I guess that's kind of a good thing, right, Like the way
that people are dealing with reactctivity and react as very standardized, So that's actually
good, like boring is good. If everyone was doing it differently, then
it would be way harder for us to navigate between one project and the other.
So yeah, let's go through some of the other frameworks then and talk
about how they are dealing with reactivity. And by the way, we at
no point we defined clearly what is reactivity, right, we just assume that
the audience would know it, but just so that we are complete into what
we are discussing. So reactivity is you being able to rerender or I would
say, just rerender is really it's anything. It's basically like instead of you
having to imperatively tell a variable that is like, oh man, I can't
think of a good example. Jesus that my explanation is terrible. Let's go
through one very simple example. Let's say you have a variable called full name
and that is computed based on the first name and the last name. So
every time you change the first name or the last name, you have to
recompute the full name variable, and that can lead to issues if you suddenly
change the first name or the last name, but then you forget to update
the full name variable. With reactivity, you wouldn't have those problems. You
also wouldn't have some other problems with regards to rendering that information for the user.
But at the core, you can tell that a particular particular variable can
be listened to, and that means that you can trigger something. You can
have a callback, for example, to run every time that value changes,
and that way you can solve this problem by listening to changes in the first
name and the last name variables and then recomputing the full name when those changes,
So that way you don't have to every time you change first name,
remember to change the last name. Just by changing the first name, it
will automatically trigger a change and trigger the callbacks that you registered and recompute the
full name variable accordingly. So that's just one simple example. But this problem
is just really nasty, Like we are probably not familiar with how painful it
was because it's been so long that I've been doing everything reactively, but like
six years ago, I remember doing a lot of imperative code and it was
just so annoying. For example, a lot of bugs that were like,
oh, you updated a variable before, got to update in this other place,
and I was like, jah, this is so stupid, like stupid
issues, small issues across the code base, and all of that can be
fixed with reactivity. But the thing is, there's no universal standard to reactivity
in JavaScript, and I mean JavaScript itself, because some other languages do have
natives for reactivity, but JavaScript doesn't. There's a proposal to add observables to
JavaScript, but other than that, which wasn't implemented yet, there's no native
way in JavaScript to define how everyone should do with reactivity. It's kind of
like how the world was before promises were standardized, so you had libraries and
mental promises, and then you had other libraries implementing other solutions to deal with
a synchronous responses. And this is what we're talking about. Like every framework
brought up its own solution, and we don't know yet which one's going to
be the winner. So probably in three years or so, we're gonna have
some native implementation and then every framework is gonna say, okay, now we're
just going to use the native implementation. But until then everyone's doing it differently.
So yep, now we have proper introduction. Yeah, exactly. So
I think maybe maybe maybe I could add in something to reactivity, right,
so I think those three reactivity I was trying to sink up the so we're
key for example, and made it change. Maybe I have available where I
needed something maybe like PETA, and then i'd said to just move it up
to lucas I want the reference of that vailable to kind of have to sync
with the with the update, with the recent update I need. But so
all the activity does does is to ensure that happens. Quite so it does
it your the other Okay, maybe for example, I make a change to
this vailable and then it could probably use the call back or listening to that
change, and then on listening to the change, its kind of reflects to
all lot of instances of that vailable all it could what million many many frame
of do we render the whole right course, and render to the dumb and
just make it to those just like more likely a very gigantic reload, so
that everything that's updated rights. That's so I think that just how you can
see it. Just to sink updates with those sinking data updates, we ensured
that Okay, whatever change you make in a new whatever new change changes you
make to always going to be reflected in wherever it's devailable or self reference,
right, So I think that's just it occurse. Do you have anything to
add to Yeah, I think it also comes down to I mean Lucas mentioned
how a lot of frameworks are kind of going to this pattern, and it
comes down to this concept of what's declarative and what's imperative. Right, So
there's there's a nice link a link at the end of the show. But
like Facebook was talking about why they kind of went to this reactive pattern.
Anyway, like Lucas mentioned, like imagine, okay, maybe for just a
full name and you have to add the last name. Okay, that works
fine. If you have to put an if statement and like hard code it
like is this different than I change it? But as soon as you have
like five ten, you know, any modern application with hundreds of things that
can potentially change, and each of those things maybe change only one or two
of the other state variables, it becomes I mean, imperative programming is kind
of out of the question, at least on the front end. So I
think all that all these frameworks you know, over time of recognized this and
and that's kind of the pattern. It's it's that they're all moving to.
So yeah, I guess that's that's all I have. Yeah, okay,
so beyond the introduction, all right, so let's go through how those other
frameworks are dealing with that. So I can bring a bit about how Angler
is dealing with that. I mentioned it a couple of times, but I'm
really curious to know what you guys know about how other frameworks are are dealing
with that. Like I kind of know from theory how Solid deals with that,
But I gotta say, like I never really built anything with Solid,
like for real, so you can't really speak much about it. But which
frameworks did you guys experience and you can talk about how they're dealing with reactivities
Peter, Okay, Yeah, So I think for reactivity, one that I
kind of know about this React, and I think I've worked with that of
View. I think the difference is that for view view users and what call
foxy objects, and I think object is kind of like a new concept,
right, where with a foxy object you can kind of set or get some
variable. So I think View kind of combined media reactivity with frozy objects.
So most of the time when you're doing reactive states with View, you're kind
of using like ay object reference, right, So once it changes, then
it's not rigas it changed to the original object you wanted to change. Yeah,
I think that's how it works for for View. Then React, I
think reacts on this kind of you're used hoisting with the virtud and constant revend.
That's still kind of events based, right, doing with events I made
this change, and then it's with twigger, so it's listed, there's some
I'm listening to the changes made to the state and then courses everywhere in the
Yeah, I think apart from that, then with signals yeah, I don't
really have like a very good grasp SIG and like you said, I'm just
on the same boat as we have. It's still right, it's just it's
knowledge. But then I think Angla spe is kind of quite you have before
we active signals, but I'm still I'm still not I've still not gotten them
of it yet. But then I think for ALEXJX, because I've kind of
worked with more with Angler, good business use that uses the lexs button.
Yeah, I think that is still events based. While you're listening to an
event and then you're listening to changes on the veable and once that happens,
she just broadcasting to other instances our name updates, right, So I think
that's technically the ones I've worked with all CRIZ. Do you have an idea
of any one like any how do you work with your activity kind of?
Yeah, I can talk about what I mentioned briefly as we were talking before
the show. I was looking into these this concept of ruins in spelt,
so they also have kind of moved or or added rather thinking spelt three or
whatever version they're on now. They have just here this like their their way
of lettings. Felt know that it's a reactive variable is this dollar signed state?
So to me, it's basically like a stealing used state. Uh,
and it's ironic. It's exactly what I was just talking about that. I
promise I didn't read this before the before what I was saying before about like
complex apps, because they say, like, okay, at first glance,
I'm reading directly from their documentations, is this this move looks like a step
back. Shouldn't we just use let count and automatically make it reactive? And
they say, well, no, the reality is that applications grow in complexity,
figuring out which values are reactive and which aren't can get tricky. So
they now have moved where they want you to specifically state this case is count.
Yeah, that count is with this dollar sign state, and we want
that to be reactive in our in our component. So yeah, that's that's
all I have. I too, like you guys, I'm guilty of only
knowing React here on the React podcast, so I don't have much experience with
with with many other front end frameworks. I think one thing that you touched
that is kind of important is this convention about using a dollar sign as a
post fix on reactive values. It's not enforced everywhere, but I've seen a
lot of different frameworks having developers adopting this convention, and I think it really
helps to make it clear that the variable is indeed reactive. So yeah,
an angular this hasn't catched yet, just because it already catched for observables,
like we always in Angler, we got used to using dollar sign at the
end for observables, but now that we also have signals, we don't want
to use it for signals because people are gonna think that it's unobservable. Like
they're both reactive, but they need to be consumed in different ways. So
with Angler, people are not adding a dollar sign at the end, but
they it's still not a problem because we have to call the value like a
signal in Angler is a function, you literally call it, so you have,
for example, first name, you would have first name open and closed
parentheses. You're actually calling the variable and that returns its value. And it
also creates a connection between the thing that is rendering it and the signal itself.
So every time that the signal changes, Angler already knows that it needs
to re render that particular part of the UI or even the within the typescript
code itself. If you have if you call it the computed, Angler has
a computed function, and then this computed function takes a callback. So imagine
that you write computed and then you call it, and you pass a callback.
Within this callback, you can just use signals as normal, and Angler
will automatically understand that this function depends on those signals, so when they change,
that function will automatically be triggered. So it's it's very smart, which
is a bit different from the explicitliness of React effects, where you need to
explicitly say like hey, rerendous effect when and those values change, you know,
kind of like they are keys and if the key change, then you
rerun this. Angular does that automatically, So I think that solves a lot
of issues because with React we can just forget to add I've seen like nasty
bugs that took me out why to figure out what it was, and it
was just a person forgot to add a variable into the effects array of dependencies.
So it's really nice that we don't have this problem with Angler. Some
people complain it at the beginning because they were accustomed to how React does it,
and they were like, oh yeah, but you're not being explicit like
this is a bit too magical, but it should be. A framework should
provide some level of magic. Otherwise, why are you using it if you're
going to type a lot of boilerplate all the time. So yeah, that's
basically how this is being handled on Angular. On the Angular side, I
do really like another convention which is used as a prefix, so React standardize
that with hooks, so every time a declatter hook is like use something.
And I'm trying to push this convention for Angular too, because Angular also has
this concept of functions that can be injected, because you can just use the
inject function internally within the function. And then that creates a problem because just
to give you a bit of context without it is becoming super complex. The
inject function in Angular can only be called if you are at a component constructor
or, like it can only be called within an injection context. But to
explain what it's an action context would be too complex. So let's just imagine
that you can only call it in the component constructor. Okay, so you
can only call it when the component's being constructed, all right, So what
the problem is if you call a function that internally call this cause this inject
function, and you don't know that this function calls the inject function internally,
then you don't know that you can only call it in the constructor and you
might call it at a later point at which it will not have the injection
context, and then it's going to fail. So what I'm trying to push
forward as a convention is to always perfect those functions with use, and then
if the function starts with use, you already know that you can only use
it if you are within an injection context. Otherwise it's just going to fail.
So those two conventions are really helpful. Dollar sign at the end and
the use prefix. Yeah, I think I think you bring up a good
point there with I think even with these kind of these whatever you want to
call it magic or syntactic sugar, even with reactivity, you're always i mean,
we're always doing this as software engineers, but you're always fighting against complexity.
You mentioned you've you've seen some nasty bugs, and I've also seen some
as well. And also just the hooks themselves can get really nasty and messy,
right because uh, you know, you have maybe have dozens of dependencies
and and maybe one is not even used, So I think, I think
what is still important probably regardless of framework, but I know it's something React
pushes is like your own how you compose the hooks themselves. So and I've
I've been guilty of that. I've looked at some of my hooks and oh,
okay, actually, you know these, I'm kind of mixing, you
know, I'm mixing reactivity again. It's this kind of disadvantage that React is
disadvantage and advantage that reacts so easy to write. Sometimes you end up just
quickly putting together hook and you get way too many dependencies or whatever. But
if you take a step back and you look at, you know, the
composition of your hooks, because this is probably more React advice, but there's
probably simplifications that you can make. But but you talking about these these things
in Angular, it makes me wonder if now there will be like almost like
a third generation in React. So like going from you know, we had
the class components that may have hooks, I wonder if or maybe you know,
maybe it is by design they should be explicit. But I wouldn't be
surprised that there's some sort of other abstraction layer where somehow you know it would
save so many beginners from you know, we all have seen that infinite rendering
thing right where it's just as simple as leaving out that array and then you're
just you're just infinitely rending your components. Wow, what's going on? So
I wonder if if there's something on the horizon would be quite interesting. Yeah,
I just just wanted to add that in. I don't know, I
don't know else where we want to go from there. I don't know if
if you had some comments too, yeah, like yeah, I agree with
so they just they need to be a way for you to actuably know what's
like since yeah, since the activity looks like magic a lot, like we
need to know how to kind of differentiate this reactively well this job. So
I've worked a lot of clothes and so many kind of boiler plates and confusing
coulde yeah most of the time get that A lot of many could business where
it kind of confused, how like especially in Angola, Like I think look
as get the example way I've actually seen they coulde biz were by observable,
not even with dollar. So I'm just litally and confusion like whoa, I
know this? Like whoa? And yeah, so I think the conversion is
very important. Just to know how like what it is, right, is
kind of very important for identification, right, And yeah, I think over
all, yeah, I think that's actually very important. And I think one
thing we need to know about the activity is that for for us, so
I kind of actually work to work with reactivity better. I feel we need
to know the underlying principle behind reactivity in any framework were using, right,
So that why most of the time I usually try to just look at their
underline principle. Okay, yeah, I know for react or is it working
with one javasket, I concept that maybe something new, Okay, Like I
gave an illustration in the beginning for view whereby we use it use kind of
the objects and kind of using for your objects and then kind of brigging like
an observer pattern with it. Kind of I think signals work with that with
that similarly as well, I think it's kind of signals to us in signal.
But I've not really kind of like extensively read about it. Kind I
don't really have more, but I think it's very much important, even for
for React. For React there's on every form of jask developer, so those
know the principle of reactivity in those frameworks. For example, you give an
example of use effect and then I think I think the mother moth the reacting
gave is setting. I think they adopted a post on the right like why
we shouldn't be kind of used environing might not need a use effect. I
think I would the link on the I think I adopted on the chat right,
so you might not need a use effect for certain things we are trying
to kind of use the effects and then adding some dependency are just some values
in the dependency. So I think one thing we need to do this the
underline principle of reactivity of those frameworks and how to use the kind of I
think that's kind of very important. So Chris, what do you think that
like maybe piece for or issues that a lot of people face, we're using
the activity maybe a sespecially in React you work with as well. Yeah,
I think it comes with with those kind of special magic. I mean usually
with magic you pay for for special rules. So I know React, I'm
sure it's still somewhere in their docks. They have like that rules of Hooks
page, right, So I mean you you get huge advantages, but there's
stuff you just can't do like you can't put a hook within a hook.
That's like one rule. And also that what what you were mentioning, Peter
is what came to mind is also how you update even just a simple state
variable with in React. Right, so you're I'm sure it's similar in most
frameworks, but in React you you typically want a fresh object, right,
You're not supposed to mutate, you're not supposed to append directly do an array
for example. The fix is easy, right you You you create a new
ray and a new array as you said the state. So yeah, small
things like that, but it's a really good point that you need to whatever
framework it is, and unfortunately they're usually framework specific, but you should know
those those details to avoid confusing, confusing bugs. And that's probably like what
Lucas mentioned in in Angular apparently this inject Unfortunately I can't speak much more to
it, but it seems like that's rue, like you can only use certain
things in certain context. So yeah, that's what that's as well. So
look as speaking of like, I think I like a general like also as
a confusional, I think it's more like a debits because I've had I kind
of have digital love they look like this before, like the aspect of do
you think I think it's based on the activity as well? Do you think
set state or you STI it is synchrons or synchronos. Yeah, Like the
answer for that, like because I kind of get that a lot on reactivity,
I think so many people argue that because of the way you stick to
work. So it's React, it's kind of synchrons some seats. So what
do you think, like from working with React at least? Yeah, Yeah,
first, like that's that's a really good question, and this is not
even just specific to React, like other frameworks also also get into this debate.
And basically the thing here is, at one point, you when you
think of code being synchronous, you think that like you call it, you
call the function, and everything that you're doing right now just stops, and
then it goes round that function and Danny comes back and runs the rest of
your cup. That's what we generally think about when we say the code is
synchronous. But the thing is when we're talking about reactivity, then people started
giving different meanings to sink and a sync because you can technically have a synchronous
refresh or an asynchronous refresh, and if you think too much about it,
you're just gonna go mad because it doesn't really make that much sense, Like
if you stop to think about it, like everything that you're executing is going
to be executed and this other thing that you called is only going to be
executed afterwards. So that's kind of like the definition of asynchronous, right,
So why are we debating if it is synchronous or not? But the question
I think is less about it being synchronous or not, but more about at
which point does the JavaScript run time decides to execute that callback, because there
are many things that happen within those idle moments in which your code is quote
unquote not running. Like there's always something running, right, the browser is
running, even if your code itself is not running. There are a lot
of listeners, there are a lot of other stuff going on. The user
is scrolling through the application, so something is clearly running, but your code
is not running anymore. So what's going on is that the browser has stages
and basically like it's going to execute your code, and while it is synchronously
executing your code, it can't repaint the page. But once your code stops,
then it will repaint the page, it will refresh, and then it
will it might like trigger another code that you have, like maybe it's going
to trigger an event you have, or you are listening to request animation frames
something like that. Now, when we talk about hooks being synchronous or not,
this is what we're referring to. It's like, okay, of course,
when you call set value, when you call set state, the rest
of your component render code is going to finish running before React rerenders or retriggers
your component with new with the new value. But when is React going to
trigger this rerender? That's the question. And what a lot of people are
calling synchronous is when the code is re rendered before the browser actually has a
chance to render. So it's kind of like the framework triggers this recalculate of
the UI before the browser has time to really render the UI, and that's
kind of like being called as synchronous. And when it waits for the next
tech or the next I don't know if sick is the right technical way to
call it, but there is like the right name to call. The next
time that the brother is going to do something, then we're calling it asynchronous,
which is what our XGS by default does, but you can also configure
our XGS to run in an immediate way. So yeah, all the context
to say, I think there are both a synchronous ways, and we just
need to stop calling it sync because it's just super confusing to everyone. So
we should just make it clear that it is asynchronous. But uh, it
hyder happens at this point of the browser event or it happens at this other
point, so we've got to figure out another way to refer to that.
Yeah, my only comment there, I think I would have to look into
the at least from React, like the use state it's super I mean you
have to like at this end of the day, it's JavaScript is single threaded,
right, so I think even yeah, looking into the source code of
youse state, you would assume there's like some sort of queue, but yeah,
like you said, like you know, there could be other things going
on. And then it really comes down to probably not even React or any
framework, but like what what the the JavaScript engine wants to do, right,
and what thinks is most efficient? Right? I mean yeah, so
yeah, you're probably right. You know, you can there's probably tricks where
or there's there's ways you can force things or try to get them to be
as sync or as ACYNC as possible. But at the end of the day,
I think if you if you really get into complexity, you're kind of
victim to Yeah, just the the JavaScript engine OPTI trying to optimize as best
it can. Not to speak about web workers or things like that, but
that's what we can do for another episode. Okay, I think that was
enough talk about reactivity, So let's start wrapping up, unless Chris, if
you have anything you'd like to mention before we start wrapping up. No,
okay, all right, so before we we officially stop, let's do quick
promos. So I'm just gonna plug on Void. So, as I as
mentioned in the beginning, on Void is a design and software company. You
can hire andvoid professionals to work for a company remotely. And the interesting thing
about on avoid in comparison to other companies that provide the same services, is
that you have the option to hire on a task based manner. So what
the means is you only pay when tasks are delivered. Sure, that's you've
seen that thus far, but only when they are delivered and approved. So
if they are delivered but they're not up to the standards of your company.
Then you can just keep requesting changes until it is up to your standards,
and you're only going to pay once you really approve it. So that's a
major differentiator, and it makes companies much safer to outsource their parts of their
design and development teams, knowing that they're not going to lose any equality by
doing so. So yeah, if you're interested on that is you and vo
Id dot Comcovoid dot com. So yeah, how about you, Chris.
I think I'm just gonna promo the link I mentioned to this the really nice
presentation by Facebook. It goes into quite a few topics, a little bit
what we talked about today on reactivity of course, and also imperative versus declarative,
and also into the kind of I think what eventually became reducs, this
concept of the flux pattern basically all the problems they ran into with growing complexity
in their apps and how they kind of found all these patterns and why they
still use them today on the front end. So really really cool video.
They have like three or four different devs talk about, you know, certain
parts of what they ran into throughout their projects. Nice. Nice How about
you, Peter. Okay, Yeah, so I have like an mdan link
of chats right about like hoisting through I think most of them time, I
feel on one of the main concept about from how did the reactive how reactive
state walks with you have don't kind of works with hoisting right, So I
think it's the concept that's kind of failing. Most people don't have on the
build a bit kind of music kind of you don't know like that we use
it on this is how it works, and this is how we act kind
of work with stags with right kind of So I think I just I will
just drope a link on hoisting and then also they see the link of yeah,
I dropped earlier, but you might not need music effects, So most
of the time we just kind of use the effects for everything we really not
need. Issue I think are the two links I have kind of yeah,
okay, and we put them into the comments section, so if you're watching
this on YouTube or Facebook linked and then you will be able to see those
links in the comment section. If not, they're probably in the show notes.
So yeah, okay, I don't think I have anything else to contribute
to this discussion. So guys, thank you so much. It was good
for us to have a podcast again because for the last few weeks it was
really hard for us to find time, like the end of the year,
things like that. So it's good to be back, good to have you
guys back. So yeah, happy New Year for everyone, and I'll see
you in the next one.