Hello, Welcome to React around Us, the podcast where we keep you updated
on all things React related. This show is sponsored by Breakdown and produced by
two companies, Top and Devs and Onvoid. Top and deves is where we
create top and devs so get top and pay and recognition while working on interesting
problems and make meaningful community contributions an Void which provides remote design and software development
services on a performance basis, so clients only pay when tasks are delivered and
approved. In today's episode, we will talk about patterns for React hooks.
This episode is going to be for you that is already used to hooks,
already used to functional programming React, but also to all of you that are
coming from a class based background, maybe from a back end language, and
you're just trying to understand why is everything done way that it is done today
with React and how can you take how can you make use of that and
structure your code in a way that other developers are going to thank you for
it. Joining me in today's episode is Charles Maxwood, Hey, everybody,
Chris Fruin, Peter Oza, Hi everyone, and of course me Lucas Paganini
and Yeah, let's get into it. So, Peter, you were the
one that proposed this idea. So I imagine that you have a lot of
things to share with the audience in terms of patterns for React hooks, code
structure for that, when to isolate something in a hook, when to just
use the native React hooks. So yeah, let's start with that. So
I guess my first question would be when would you create a hook for something?
Okay? Yeah, so when you create to create a hook, you
have to consider setting scenarios, right, So like if I want to create
a hook for a settain components, I will try to look at the component
and see which values are changing. Okay, does it is it going to
contain reactive states or is it going to contain setting things that are going to
change? And then also do I need to maybe process those states those values
and then we turn something back. Yeah. So in that kind of instance,
when I look at those criterias, does when I decide, oh,
I'm going to just start this to hook. Also it comes to things like
API cause yeah, I know that the API course is the APR cause can
be called the components. Easier for me to just live it in that component,
I could just isolate it to the hook. Mostly it's just on things
that are kind of changing or things that are kind of intent. Yeah,
so that's why I use hooks. I kind of also live into So yeah,
I think that's just what I generally do. Okay, makes sense to
me, But when would you For example, of course, every time that
we need state, we're going to have to use React hooks and use state
or any other hook that is going to allow us to react to changes and
re render a component. But when do you feel it's the time to really
isolate that into a custom hook so that it can maybe be reused later,
Like would you only reuse something in a custom hook if it's definitely going to
be reused right now, or would it be advised to isolate things in a
hook in a custom hook, even if they are used in a single component,
just for the sake of reducing the total size of that file. What
do you think of that? Okay? Yeah, So for me, okay,
in cases where I need to create a customer, one thing I consider
is actually reusability. Right, So if I'm going to create a custom book
for a component, I mean, it has to be usable, right,
So it's really makes sense to just create a custom book for something that was
that's just specific to that component that can be used, right, So it's
more much more important that, Oh I know that, Yeah, this state
is going to be used these certain components. Maybe I have an APR call.
I'm going to make this a PR call and different components. Yeah,
I can just upstart that to custom book and use that. Or I need
I need a setting value and maybe something like I need to trag like school,
school events or something. Yeah, you know that that can be using
different components. I could just build that to be a hook, or yeah,
I want to do if finish school Obviously you know that many components going
to use that or the popular one. I want to ensure that when you
click outside, that's the one that kind of use events propagation to yeah,
to close down setting events and so on. Yeah, I know I'll use
the hook for that because they're kind of reusable. But in an instance where
maybe certain things like business logically, you know that you can't really use them
elsewhere they're just localized to that component. Yeah, I won't really that the
best way is to just upstart them to out to hook a custom hook,
because then it's just only going to be one used. That's it. You
can't believe we use them anywhere, So I think increasing the costom we just
considered with their reasonability. Yeah, so that's just my philosophy for it.
Interesting. Interesting, Okay, I have strong feelings about this, but I
would like to get Chris and Check's opinion on that. So, Chris,
how do you feel about that? Like when do you isolate something in a
custom hook? Yeah? So I kind of view hooks for me fall into
kind of different categories. I can think of like two off the bat,
you kind of have like what Peter mentioned. Maybe some are almost more like
util hooks. I was just looking at a code base, and I typically
have like the used interval or use time out. Those you probably know you
probably use them more than once around your code base. But then even really
truly your own custom hooks maybe their application specific. But then those two,
you know, I'm probably gonna need this in more than one component. So
yeah, for me, it really just comes down to I'm typically the kind
of dev As soon as I'm using something, probably twice somewhere, I just
refactored into a hook. And even I mean even even for one off sometimes
I mean it might just become a standard function anyway. But if there's really
quite a lot of logic for i don't know, some crazy complex component,
sometimes it just makes sense to say, like, you know, like use
whatever the use state for this component, and then you at least have all
of your reactive code kind of separate from the market from the markdown. Right,
So you have just probably like a one liner of accessing all the state
that's changing, and then you can keep kind of that those two concerns,
like the display side and then the reactive side separate at least at least in
code. So nice. Okay, so you are like still leaning towards isolation
only when there is reusability, but there are also some other cases where you
would isolate is not just for reusability, but still is mostly due to reusability.
Interesting. Okay, how about you, Chuck. I'm gonna be honest,
I haven't done much React lately. I'm kind of still ramping things up
and starting a project for React geniuses. So yeah, I'll have much more
to say here in a few weeks. Okay, all right, So what
I actually wanted to get at is, and I think Chris touched on that
point, is when a component starts to get really complex and there are just
too much logic happening in it, then you might want to isolate your hook
in another file, even maybe just so that you can clean up a bit
the logic of that component, even if that hook is not going to be
reused anywhere else. And if you're gonna do that, you don't even need
to put your hook in like a separate folder just for reusable hooks. You
can put that side by side with the component if it's just going to be
used by that specific component. And I think this should be used way more
often. My feeling is that React component files are generally much larger than they
should be. There's just generally way too much happening. So I think that
most developers could definitely benefit from breaking down more things, more of what they
have in their component files in other files, even if that's not going to
be used in more than one place, Like even if it's used in one
place, just one place, I still think that in a lot of cases,
probably most, it's a lot more beneficial to do that than just being
on edge case. I don't think it's on edge case. I think this
should probably be the default for most situations. Just to give you guys an
idea, the average file size for a React file that I open is generally
like eight hundred lines or so. That's the average. I don't know what's
the experience for you guys, but that's what I'm used to seeing in other
projects. And I think that's just too much. That's way too much.
I think we should be striving to stay at at least less than five hundred
lines, but ideally three hundred or something that that should be enough. So
yeah, my take is I tend to isolate things in other files way more
often than other developers, even when things are not going to be reused right
away, even when things don't seem like they're going to be reused at all,
I still generally isolate things. Also makes it easier for me to write
tests for those functions. So yeah, yeah, and you you have to
think about, like, what's what's the actual quote unquote risk or overhead.
I mean, now that we have functional components, you're adding what the name
okay, the props and then the name of the component, even if it's
only just once, and then two brackets, so you've added whatever three lines
to save you know, to get away from those eight hundred line components.
And I've seen that, and I'm even I'm I think we're all guilty of
that. I think it's one of the advantages and disadvantages of React is that,
you know, once you've learned the basics, it's very easy to quickly
build and write these these components, and then before you know it, you've
got you've got some giant thing like yeah, it's probably even then at those
sizes still understandable, but it's just like a lot of usually markup you have
to skip through and see like, okay, where does this variable go?
You know what's happening here? But yeah, that's in you know, help
why I'm why I'm here on this podcast, why I love reacts so much?
You can just snag you know, you've got I'm thinking of like an
example, like maybe like a table row. You just pull out that mark
down you see you know what state variables in there? They just become props,
right, and then you're halfway, you know, you're halfway done to
refactoring those those larger component files. So I'm gonna go even further and say
that sometimes I even isolate just the styled components like sometimes I have just the
styles dot t s file just for the diout components, because sometimes like fifty
percent off the file is just those dumb presentational components that are taking up space
and the bottom, and they're not really making the experience of understanding the file
harder because they are like in the bottom. They're like isolated in their own
in their own space. But still sometimes when they're just way too many of
them, I just can't stand and I just isolate them in other files.
But that one is definitely just a personal preference, is not something that I
do that I do a lot. What I do mostly is isolating hooks,
but even style components I think sometimes can be isolated in their own files.
It even reminds me of the old days where we actually had like a file
for HML, another for typescript, another for CSS. Right, so when
I isolate the style components, it kind of feels like that's the CSS file.
I like that, probably because I also do a lot of Angular development,
and Angular separates those things. So maybe that's and it's something that I'm
bringing from my Angular development stuff. Yeah, does actually true. So I
think what an issue that most we have developers actually face is the fact that
because the art is not opinionated quite because yeah, you could just it doesn't
really have like an ups A style of its own. You could just do
whatever you want, just like the the whole components is just like your your
field to just do whatever you want to write. So a lot of people
kind of you know, decide to be the way they want to write.
So I think if they actually have an idea of setting patterns rights to building
stuff, I feel it's virtually helped, for example, parking a lot of
like logic in more, we are components. First of all, it's not
really nice at first all. What I actually would do is a first different
differentiate my components into two. Okay, there is a component another maybe like
a business logic, an API call or setting things. That would be a
setting component. That would be like a container component. Right, so that
component would just be a container. Then I've done that. It's a presentational
components that's you are clearly like you won't see any till I used it or
whatever. Any hook is just receiving data from it as props. Right,
So these kind of patterns, there's there's stillso the pattern of writer, as
you said, isolating for setting out sets in books. Right. So if
a lot of people adopted that as well, I think they could become more
cleaner and more much better and they're still Like I said, I also do
a lot of umblood development as well too. I like the pattern of amblers
services, right, So I actually kind of adopted that aspecting react to.
So I think there was a reference we said, as there are certain things
we need to letting a hook, right. But if you actually have like
an idea of a service, maybe you put your business logic in the service
you create like a class or it will be a very big functim if that
was just look, you won't really have any need to really isolate much in
your component because at the end of the dagion multiple drink calculations in your component,
everything is done in your service and you're just important it to your component.
So it's going to be kind of it's not going to be blooted,
right. So I think it's just how because reactive it's not openiord so a
lot of people just gives them the ability to kind of decide what they want
to do. And I feel maybe if design patterns can be taught very well
about that, like, oh, you could do this, you could do
that, Like now, I know, I feel a lot of if you're
actually don't know the result is why hooks, right, And they really abuse
a lot of hooks, like I've seen hooks like use memo Beiner Bese so
much like like things we're never supposed to memoiz, it's just stumping use memo
into it. So yeah, I think that's actually I think design patons is
actually very important to know, mostly identical because since we acts don't have that's
established paton, I think that's what they need to actually know so that it
can come better. INTI the good bit. Yeah, I agree, and
I think that can be something that we're trying to introduce here, right,
So since reactor is not opinionated, let's bring some some opinions into it,
see if we can help everyone out. But yeah, definitely a lot of
what we say here is going to be it's going to be based on personal
preferences. But also I would encourage everyone listening to think about this for a
second because even though a lot of code patterns are going to be based on
personal preference, that personal preference may have been built after years of working with
that technology and understanding what reduces the mental load of other developers and what makes
it clearer and easier for everyone else to understand. So there's always something of
a mutual benefit in a personal preference. It's rarely the case where a personal
preference from a senior developer at least is really something super specific to that developer
and others are going to agree. What I've seen the most is like personal
preferences from senior engineers in a particular technology tend to be kind of like a
general agreement that others have. I wouldn't say that it's like an anonymous agreement,
unanimals agreement and everyone agrees with that, because there are certainly things that
are purely cosmetic. For example, just adding underscore prefixes to your private private
members for example, that's very very cosmetic. But the things that we're talking
about here, like isolating things in custom hooks, when to isolate that,
how to organize or file structure, I think that's not cosmetic. That really
has a strong functional value for all the engineers in the colbase. So yeah,
I wouldn't just say that as being like just a personal preference. I
think in most cases this is definitely like a code quality improvement. Yeah,
let's see what else we got. So we talked about when to isolate things
into hooks. What else do do we have with regards to common code patterns
and React? Chris, Peter, maybe you have something your mind. Yeah,
I'd like I'd like to add something. This gets pretty pretty specific into
maybe what you're talking about about like fairly opinionated. But but it's something like
that I've finally kind of solidified in my own React career, and i'd like
to hear you guys. Maybe you disagree completely and then then we'll see.
But I have a I have a very specific order when I have a when
I write a component of how just how I I guess format it, so
I what I do is and yeah, I know these will be opinionated.
So like my first line, I'll like destructure all the props that I need,
so you know, the big big bracket off the props. Then what
I'll do is if I'm using reducts, so like a more global state or
at least a higher shared state, I use the appso elector, then I
use the dispatch. Then comes if there's any local state, I have those
and then anything else like use ref or anything below that, and then finally
they use effect or any other if you're doing like one of the like use
layout or something like that, and the way. So I would maybe I
would argue like that order doesn't matter, but maybe in a given code base
you should probably I think it's nice to follow the same same order in any
way You're like, I think at least like the use effect below makes sense
because you typically need state variable in there anyway. But I think if you
can manage kind of a the same pattern across at least one code base,
maybe not all code bases, but at least one project or something, it's
really nice because then when you look at a component, you know exactly like
you know exactly where everything's going to be right and in what line more or
less. So i'd be interested to hear you guys thoughts about that. Yeah,
that sounds great. I'm also a fond of redocs as well. So
yeah, although, yeah, so I started with videos, which is because
first of all, I tried to defense it. I tried like deficiate the
state of my application into two. Okay, yeah, I have a client
state and I have a SABA states, right, so disavastate aspects. Yeah,
I could use things like maybe we asked qually to handle that and then
find a way to kind of sync it to my redox. Yeah, then
after doing that as well, then coming to components centralized as well, then
I, like I said, I use hooks to actually setting business logics.
So if I like accomplish logic I need to execute in the component, I
could put that into a hook and then put that and then my ustage is
regularly for certain changes in that component and yeah, just changes. Yeah,
previously I usually use states for forms. For then I saw a kind of
bottle neck which is in use state that's using US state for form validation and
so on. Like I know a lot of people use it. I think
it's called I think it's on compute states patterns like yeah, whereas you have
like I know, it's kind of like the regular or you're typing on change
and then it's actually afflexes from the states, right, so that kind of
but so yeah, so I think generally do you use it use I just
use it now for just general components states. Things are going to change,
and so then sever state is then my sever state is useful and my clients
needed with videos. Yeah, I think that's generally how I work with I
like that trick about the order first off, like the use the fact at
the end. I think it's a no brainer, as you said, Chris,
like we generally need those state variables anyway, so there's no reason to
to not have that at the end, So I think that makes total sense.
I would still I don't know if I would always put them in order
of what they are, because I like to keep things in the order of
what they are related to. But in the same sense, like if you're
inside a particular component and that component has a very clear responsibility, then everything
is supposed to be very close. All the responsibilities should be very close,
so that shouldn't be a problem. But come on, let's be honest,
like a lot of components out there, they are doing way too much.
And then when you have components doing way too much, if you put things
in the order of what they are, maybe you have like let's say that
you have a component that renders users and user groups, for example, and
then you have hooks that are specific to the user's state, and other hooks
they are specific to the user groups state. I would rather keep all of
them close together based on the feature that they are related to. So all
the user related hooks together, all the user group related hooks together, then
just having like all use effect, all use state, all use rep together,
if that makes sense. But still like that, that also comes from
my mentality of thinking about how to even isolate those things into even even more
custom hooks. So I generally do that because it makes me it makes it
even easier for me to later just create a hook that is just going to
be responsible for exposed seeing the features related to users, and another for the
things that are exposing just the features related to user groups. Even again if
even if they're not going to be reused somewhere else, Yeah, I like
to keep them grouped based on the feature. Yeah, I think as kind
of a rule of thumb in general. I mean, as always it depends,
but if you're finding your component has like two or even two or three
use effects, it's not always, but it's typically a sign you're probably doing
too much in or trying to do too much in one component. Again,
it depends if you have a very you know, some very complex triggering triggering
stuff. But then maybe that's even an area for refactoring anyway. Yeah,
I would just out of my own curiosity. I'm interested because I've heard many
different opinions. What do you think about my the props destructuring? Do you
guys like the props dot whatever, or I like I always destructure them.
I mean, I know it can conflict then with local variables, but then
I don't know. I typically avoid that anyway. But I would like to
hear you guys, which pattern you prefer or maybe it depends. Yeah,
I go with I think I'm with you on this one as well. Chris.
Yeah, it's better to actually there pop. So I'm kind of be
fun of that as well. Yeah, so yeah, yeah, I'm be
fun of that because, first of all, I think if you use types,
if you're typing right the components, I think you know, yeah,
obviously the type is going to have like the setame feuds so required. Yeah,
I don't think you actually wanted to be in problem with that that.
I think that's actually much bitter and much easier because then seem pop stop dots
that kind of it. Yeah, I'm with both of you. I prefer
destructuring. There are some situations where I don't, but they're generally a sign
of a larger issue. For example, if I'm just doing a lot of
prop drilling, and then I don't want a destructure because I want to like
passing the like the structure the object itself to pass the properties to the child
component. But that's generally like a very bad sign, and that's something's really
wrong in the cow base. So that doesn't happen very often. But if
I find myself just getting the props to to drill them downwards, then I
might just grab the entire properties is just a variable called props and then do
that, But mostly I do the structuring too. That works, Yeah,
that's the best way. Kind of be fun of that. Yeah, that
that's that's actually another topic, right, So how do you guys deal it?
Just passing properties to two child components? Of course, like prop drilling
shouldn't really be the the recommended approach, but sometimes it just feels like it
would be such a small thing that it wouldn't make sense to create like a
context for that or something like that. But how do you feel about that?
Oh? Yeah, so for for drilling, Yeah, I'll be fond
of for feeling the way, but probably like one or two components might I
think the moment it takes it like we be two components, and I feel,
oh, yeah, maybe I have to study using context because then come
three, four, five components. The Yeah, so I kind of stop
using props and I say, this data required is going to be like needed
more than two components dip. Yeah, but over all, Yeah, if
I actually see it needs to use it to actually pass down things asps,
yeah, why not? Certainly easier to do so than to just maybe I
think I think this is another pattern. A lot of people kind of abuse
in the way, but they try to avoid props in general because of the
fear of propelling that they create context for every single thing, like every single
thing, like even like you just you certainly just look at the data and
be like, oh, this could just pass this with the props, and
you're seeing a very big context setting like something as something as small as or
I have a small component. I just want this component to flick out on
different modes, just one component, and I'm saying, no, the context
and this on them. It's just extreme. It's like he's in the sledge
to kill a man that's way backing right to I. Just in that stance,
I just advice to sports, because why not it's easy and it's just
one compient down. But then just maybe and I know that all what is
going to be more so I use context. What do you think, Chris,
when do you feel bob building is efficient or better? Yeah, it's
I'm finding myself kind of internally battling because I'm to be honest, I'm I'm
more of a I don't like when there's millions of prop options. But with
that said, I'm also thinking of you know, sometimes you get these really
nice, I mean very powerful components, you know, from some libraries somewhere,
and they do have you know, just by the way you know the
functionality provide, you have many many options. I guess, so maybe what
I should should refine that is when there's you know, twenty required properties for
a component, then it's then it's a little bit somehow that's a bit of
a smell. I think you're throwing too many things around, but you know,
like optional stuff. Then I guess maybe that's maybe that's where I would
would draw the line. But yeah, it depends for me. Like again,
I typically try to use or have Yeah, I would say like four
or five props. I just I can't think of an example where I have
a lot of stuff going around and in terms, I am more of a
instead of context. I typically use reducts for when there's something shared. I
typically I just haven't I haven't used context. But at the end of the
day, it's they're quite similar, right, like a reduct slice and contexts.
Right, you can grab at stuff where you need it across across multiple
components. But yeah, I'm not sure if I answered your question, I
I just lean more towards For me, it always comes back to kent,
do I understand what this one component's doing? And typically from the mental overhead
is you know three four required props is probably good. If you've got more,
maybe you still need you need some other components in between, or or
you need to move your state higher up into reducts or it does depend.
It does depend. But yeah, that's I guess my general opinion there.
Yeah, that's I think. One thing I know. I'm actually I think
one thing if you a little is that, Yeah, the kind of abuse
context in the way that they try to don't context the context API to redogs
because I, yeah, I've seen a lot of people finding me context APR
work for state management, right, I think that's an issue that's kind of
very presented. So many could bees and like why don't you just use redogs
like you want, Like this is actually just managing the state of the application,
and then you'll see context with the miss of you use reducers and and
that's the sure John good quite too. I think, Yeah, I think
I get your point on using redocs as because I think that's very much,
very very much preferred because yeahally acknowledge that, yeah, you have a kind
of the global STI you need to work with, and they use redocs for
that. Yeah, I think that's that's the okay as well? What do
you think? Look as I think I answer with Chris on this, like
the most important metric is if you can look at the component and understand its
responsibility and you can understand why it depends on the things that it's asking.
So why is this component requesting those properties to render? If the if you
can look at each of the properties and you can understand why they're being asked,
then I think that's a good metric for success. And I also agree
with lifting states to react to reducts when there's just too much going on in
the component itself. So yeah, I actually think that I agree completely with
with your opinion on this, Chris. Yeah, and also I should mention
so for listeners, I would also avoid don't just think, oh, I'm
going to put every single state variable in reducts. I used to that was
almost, you know, when I was starting out, that's almost the pattern
I would go for. But then you realize when you have you know,
then your reducs, then your reducts state itself is also looking you know,
humongous with fifty properties, and then you realize, you know, there's there's
a reason for the U state, you know, a local state variable.
There's a reason for that. It doesn't need to run through your entire reducs
tree. I just I think I'm thinking of examples. I think I was
doing that. I think Peter was mentioned like with forms, I was throwing
the whole form state into the reduct store. But it's like I don't need
that. The form lives here in this component, like it makes sense,
like keep it there. So yeah, don't don't don't throw everything into reducts.
I guess really really think about what needs to be shared and where.
Yeah, that that one is definitely a very important device. I think especially
for davs, they are getting used two to the events pattern. It's just
so easy. And by the way, for those of you that may not
know it from by this name, like REDUCS is just event sarcing. At
the end of the day, people say, oh, the redux pattern or
the flux pattern, but it's events surcing. It actually is event surcing.
That's the original technical name. And for everyone that learns events sarsing is just
such a mind blowing moment. They're like, oh, my god, yes,
why didn't I ever think of isolating things and building a stake machine?
And then people start thinking that that's the answer for everything. You know,
I myself, I got a bit crazy about SQRS, so I don't know,
that's not like super common. But QRS stands for command uvery responsibility segregation,
and it's basically when you isolate the actions from the events. So the
actions are the things that actually mutate or that can cause a mutation, and
the events are just things that already happened and they state the changes that they
applied. So what we currently call actions in reducts is probably it's generally a
mix of what we would call commands and what we would call queries. But
if you have an entire system that uses QRS, then you have like such
great scalability because every time that you're just making queries, those queries can be
getting the data from replicas of the original database, and those replicas can be
read only because they're not going to change anything. They're just queries, immutable
queries, right. It's also so much easier for you to cash and then
everything that changes the state is isolated in the commands, and these commands have
to talk directly to the instances of the database that actually can make changes and
that replicate the state to the to the read only replicas. So it's like
this gigantic infrastructure mostly for back end applications. I never seen it being done
in the front end. So it's like this entire architecture pattern to have like
really scalable back end applications. And it all starts from events sourcing, and
I was guilty of like getting into events surcing, learning about secure ass and
thinking this is the way everything needs to be built. Like if I do
a back end today, it needs to be in secure ass. Like I'm
gonna have infinite scalability. I'm never gonna have to worry about data migrations ever
again, because I have every single event that ever happened in my application.
Everything is going to be event first. But if you try to do it,
it's just such a pain. It's just so much boilerplate. There's no
everything is eventually consistent is not immediately consistent. And another big issue is that
even if you're just starting your new project, you're already starting with like such
a big overhead in terms of actual server costs. Because with that structure,
if you really wanted to be scalable, then you would at least isolate the
the command processors from the query processors, and that alone, you're already introducing
a micro service approach from day one. So it's like, is such a
high complexity to just start a project that way? That over time I realized
that, yep, this is great when the project I'm working on actually becomes
the next Instagram before that, and that's really there's really no need. So
yeah, there are like multiple layers of thinking that events sourcing is the final
answer, but really it always adds complexity, so we need to keep that
in mind. Are we really okay with having that level of complexity right now,
or should we just keep that in the backlog or when we actually need
that level of scalability. Yeah, I think that brings up a good point
too in general, like what we were mentioning, like if you're trying to
throw everything into reducs or some higher state, is this concept of performance right,
because this whole prop story is more or less what controls the re rendering.
Right. Of course, the IU may have internal state in your in
your components which causes rerendering, but it's also the props. So when you
have you know, who knows, fifteen to twenty props one may be changing
you. If you've got that many props going around, you may not even
realize am I even using this? Do I only need this initially? So
all these, all these things at the end of the day can can impact
performance. So if you're not careful and you know, taking too much advantage
of this, this whole flexible react ecosystem, I think eventually if it can
come and hitch you with with performance. So you know, yeah, I
think we've we've kept repeating this the whole show, but it really does come
down to not only readability, but you know, what is this component doing,
What does it really need in terms of props and state and and and
go from there and and not just not just take advantage of the flexibility of
reacting throw everything in some some giant state or some some giant proper somewhere.
Yeah, I kind of agree with what christis as well. So the best
mode does bloot you redog store? Yeah, it does blooded with so many
properties good to affect performance because at the you know it did's you kind of
like cool javascripts, right, just saving data the bigger auditor is right.
Procession is going to take time and approval and so on and so so also
the times to just use some use local states for certain actions and then also
used with dogs when you need to. Like I said, that's why it's
like it's your global states, things that are kind of you feel a kind
of global We kind of need that for setting components all most components, like
putting like worth putting formed data in legal components is kind of yeah, on
the VACU because it's kind of centralized your components. The components house in the
form that there's a US stage they can be used to localize that from data.
So it's actually very best better to use that, right too. I
think I kind of agree with what you said too. It's best to kind
of for work we said, just consider those consider like do not over bluet
or global skits as much as possible. Right, that does minimize issues as
most as possible. Yeah, a lot of a lot of stuff discussed today.
So let's start wrapping up. Let's do some quick promise and then we
can close up this episode. I hope this was helpful for lot of people.
I know that it definitely would have been helpful to me if I were
starting out a lot of things here, like took me a while to get
to the to the state, so I definitely think this would have been a
lot valuable, especially when you're working with other team members. So so yeah,
I think this was really good. I'm gonna do my mind really quickly.
So I'm just going to promote Onvoid. So for those of you that
might not be familiar with that, is you n v O I d unvoid
dot com And basically Void is the safest way to outsource or augment your software
development staff. Why because every single other software development company is going to build
you by the time and resources and Void is the only company that is going
to view you just based on the actual tasks that were delivered, and the
clients only pay after the tasks are approved. So it's not even a matter
of just the Void developers delivering the tasks and saying, hey, okay,
now give me the money. No, it's like they have to deliver and
ask to actually be approved by the client, which guarantees that it's going to
be within the quality standards that the client is expecting. So it's really it's
a very very interesting model, and it's the most meritocratic way to hire an
engineer because you're not just thinking about like, oh, this person is a
junior, this is a plane, this is a senior. No, you're
just hiring Void engineers as if it were a black box, and then you're
just going to pay by what they actually delivered. So I think this is
a much more meritocratic way, even for the engineers themselves, because I know
a lot of great professionals that have three years of experience and they do better
work than other professionals that have ten years of experience. So this model is
actually also beneficial to the engineers because even if they have less work experience.
If they can deliver more, if they do a better work, then they're
going to deliver more points at the end of the day, which is going
to reflect on how much they get paid. So really an interesting model for
both parts. So yeah, if you're interested in either outsourcing your software development
project or just augmenting your staff to do some other tasks that maybe your full
time engineers are just full of other things to do and they can't tackle those
other projects, then definitely take a look at Void dot com. And honestly,
if you're into that, don't take too long because end of the year
is always like kind of crazy. A lot of companies are like approving their
budgets, so they're even there's a real possibility that if you take too long,
I Avoid might just say hey, we're literally out of engineers at the
moment. You're gonna have to wait a while because AVOID engineers are not freelancers,
their employees, so they are hired and trained before before they start doing
client work, so that takes a while. So yeah, this is gonna
be my promo for today. Okay, so Peter, what do you have
for us? Yeah? Well, okay, so not too much willing to
do. Yeah, so I okay, maybe to follow up, I think
I can give up my profile rights to follow on LinkedIn on loo custom setting
posts right on. Yeah, should I share that? Yeah? Sure?
Yeah, yeah, I'm kind of most kind of kind of not too big
on titter kind of I'm just more like a LinkedIn guy. Sounds boring,
but yeah, I just yeah kind of. I just stam on LinkedIn to
just follow with different right too. Yeah, just give misick, let me
share. When you have the link, Peter, you can just send it
in the comments and everyone that is listening to us live will be able to
to see that. Yeah. Sure, I have it here and you pasted
it on the comments. Yeah, all right, okay, Chris, how
about you? Yep, I'm probably just gonna send a link to my blog
again. I have a post that's probably relevant to what we were talking about.
So for people who are maybe brand new to hooks or coming from from
class components, I basically tried to go through the hooks as if it were
alphabet soup. So really ABC, very small variables, and you know this,
this is what U state does, This is what use effect does.
Looking at it now, I think I have to I think that I have
to add a few more examples, but but yeah, I'll just I'll post
the link to that that post there. I think it's a good introduction without
without involving any other complicated actual effects from some project or whatever. Really just
focuses on what are hooks from the ground up? All right, cool?
Cool, A lot of a lot of learning material from you. Two how
about you check yep. So two things. One is you can go to
if you go to react round up dot com, or you can go to
topendevs dot com and click on react round Up. There's gonna be an option
on there for you to get the premium version of the podcast, which is
effectively no ads. The other thing that it does is I'm going to be
doing a monthly call. It'll be on stream Yard like this, except it's
using the webinar features, so you'll actually be in stream Yard. And what
we're gonna do during those calls is we're going to discuss the show. So
I'm going to be getting ideas from the listeners and from the other hosts.
So I'll invite the other hosts. This is news to them, by the
way, I just lined this up. But what we'll do is then if
there's a person that you want to hear from, So let's say you want
to hear from Dan Abramoff again, or you know, let's see if we
can get Jordan walk even though he's working on something mouse now, to come
in and tell us more stories about working on Facebook or whatever. Right,
So we'll get them in and then I can have my team go invite them
and say, hey, the listeners wanted to have you on, or hey,
the hosts wanted to have you on, and we can have that all
put together and figure it out. So those are the two things. We're
actually on the cusp of launching our app that has the content in it,
so you can either get the premium content there or when you sign up,
you'll also get an email that basically says, hey, here's a private RSS
feed for you to add to your podcast app so that you can just get
it with all of your other podcasts and then you can unsubscribe from the main
feed and you can just subscribe to the ad free feed. Cool. So
I think this is all for today. Everyone, thanks for tune in,
and we'll see you in the next one.