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.