Welcome everybody. Dan super excited to have you here. It's good to finally meet you after years of internet. Kind of. Exactly. Sure you get that a lot, but yeah, this is a, this is. So much people flow. With mentors. And developers here from the collab lab. You know, we're all like all our developers are early career people trying to break into the industry and stuff. So we're all super excited to kind of watch you go through a little bit of an interview panel here. We have. We have four interviewers. I'll let them introduce themselves. But yeah, they're going to. Have you go through some live coding? They ask you some questions and things. Some people, I think everybody probably knows who you are. I mean, you're a little bit of a. Well, I don't know if this internet celebrity isn't quite right. But yeah, that's like the niche celebrity. Right, right. But. I looked at the people at Facebook. Now call it. Or Facebook. Yes. Okay. Zapier call up, call our teams squads. And so we're still a chest, but anyway, And the maintainer of Redux as well. So. Well, I'm not anymore. I'm a co-creator, but I don't actively maintain it. So. It's a bunch of different people now. Okay. Yeah. Makes sense. But I will I'll turn it over to our, to our interviewers. I'm going to pin the people who are. Kind of actively involved with us or actually, maybe Chris, you need to do that. Oh, yeah. I'm the host now. Oh, I've never pinned anyone. On the fly. That's all right. Oh, I see. Yeah. Click on their face. Started with Monday, you can add pen and. Pin the five people at all. Let's get Giuliana in here. That's good. Dan and here. Edward, Steve. Let's get. Okay. There we are. Cool. Shall we take it away, Andrew. Yep. Go for it. Alrighty. Sweet. Cool. Well, thanks so much for joining us today, Dan. We all really appreciate it. TCL. We'll do a quick round of intros here. And then we'll get into some more questions. So my name is Chris. Located in Portland, Oregon. And I work with Andrew and a bunch of the other people here at Zapier. And let's do a popcorn style to keep it going. I'll popcorn over to Juliana. I'm Juliana. Nice to meet you, Dan. I am. A software engineer. A buffer. I'll pop it over to like, Hey. Thanks Juliana. A Dan and Hey everyone. I am Mike Lambert. A software engineer at Zapier and also a mentor here at the collab lab. And last, but definitely not least. Let's go over to Steve. Hey, Dan, I'm Steve Gardner. I'm an engineer at Zapier also. And. Mentor club lab really excited for this. Alright. Awesome. Thanks so much crew. All right. Let's real quickly sketch out how this interview is going to go. So we're going to split it into two sections. The first one is going to be a more of a technical coding challenge. And then the second half is going to be a combination of like some technical questions and some kind of behavioral questions about your previous experiences and things like that. So I'll go ahead and kick us off here with the coding question. And I'm going to send you a link to a code pen, Dan. Going to message it to you directly here in soon. Okay. Did that come through? Excellent. All right. If you could share your screen for us and pop, open that link, and then we'll talk about the prompt. Okay. One second. Let me. Let me figure it out. Green. Okay. So I just, I just need to, I think I might have to restart because it's the first time I used this computer. I got a new computer. So it doesn't have the permissions. Let me, let me try. Yeah. So I'll just, I'll just restart the call in a second. Cool. Okay. This is very much like being hired at a new company. The first thing you always have to do is get your permissions. Correct. So, And Chris, you could, you could probably pause the recording if you want. Nevermind. Okay. Okay. I'm back. Cool. Resume the recording and I need to repin. You as well, let me get that. Going here. Okay. Cool. All right. We can see your internet browser. Beautiful. Okay. Cool. So I'll talk you through the challenge here real quickly. So this is I think, a fairly common react coding challenge that I think some of our students here might be likely to run into out in the real world. I know I've had to solve something kind of similar. So we've got an application here and its job is basically to keep track of accounts. This could be. Any kind of count that you might see on the internet, like maybe likes or subscriptions, something like that. And we've got a few components in our app. We've got a form component that contains a couple of button components, which are incremental and detrimental components. My challenge for you. Dan is two. Hook all of these components up together so that when you click the increment button, it increments the state counter. And when you click detriment, it detriments the state counter. Okay. Do you. Daycare about the specific components structure, like for example, can I move this, this space of state? Oh, I see. Okay. See. We have. So like you care that the form component is I don't like Guthrie the fifth and just in line. This here. Right? So like you, you want. There have the form component, this stuff. Yeah, I'd. I'd like you to keep the component structure if possible, but also feel free to talk through like how you might restructure it. You know, if you were dealing with this problem in the real world too, because that's also interesting. Okay. I'll just start it by it. Like, I'll just like, make it first in fermentation and then I'll figure it out. Yeah. So I think. Like the state leave skier. So we kind of want to drill it down. So what I'm going to do is. We don't actually need this. Like this thing. The have handlers, right? So we're going to have like an unclick prop and this is going to have, and I'll click prop. So here. I guess we were going to have like, The. We don't actually need to know the current count. We. I need to have a thing that. Like on increment decrement, I look necessarily like used a specific component structure, like in practice, but maybe we can just start with that. So, When we click this. The increment. And the click this you want to decrement. And then we want to actually implement these. So. On increment. We want the. So that's county council spawn one day. We want to do. And I think that should, I would expect this. To work. Yeah. Nice. Yeah, that looks great. So one consideration that I've got for you here. I noticed that you're sort of following down the props hierarchy, hand, handing down these handlers. How would you tackle this situation if instead of being nested in like a single form component, you had a much more deeply nested structure. Like, you know, maybe. It doesn't components in the way, you know, how would you deal with that situation? Yeah. So I. I would say there's like kind of two ways. I would maybe think about this. Like I think the first thing I would try is kind of tweak the. Component hierarchy. And it really depends on like where. Where the nesting happens and like how exactly it happens. So I guess some situations, what, what could happen is actually. Like maybe these extra layers. They would. They kind of leave somewhere here. So maybe. Like one, if you have an example where you do have like, This component, renders that component and index. Now the conformance and so on. Like one thing you can sometimes do is a. Us children to it. So for like another example, like maybe. With restructured. So that maybe form. Actually except some children. And I could pass this things. Like inside of that form. And then, then like, this would be like children. I'm not like fully specifying as of course, I think that actually. Fix these up, but essentially. In some cases as possible. If you have like the fence to border or I dunno, like. Like a tree of those things here. Like they could. All go here, but this thing doesn't actually care about this because. W like the logic it's still, it is still very close. Like, I don't need to kind of spread it. The parts. But the other solution is. Like, if that is not feasible, for some reason, if, if. Like if, if this, if this pieces are really disconnected from each other so far that like, it's not meaningful to pass these buttons from. You know, through many layers from outside. I really want to kind of decouple them then. I would probably use context. So, do you want me to implement the context solution or. Should I describe it. I would love to see you implemented. Yeah. Yeah. Okay. So yeah, so basically. So this is. The scope and rights. Yes. Okay. So I'd say. Great. Context. You just context. From react. This is necessarily going to look a little bit. Convoluted for this example. But. Well, the thing that I want to put on context is really. It's not the state itself. Right. It's really the ability to kind of just set it. So maybe I would also use a reducer here. Again, not super necessary, but. It lets. We would need to decide, like, what do we want to put in context? Is it like a bunch of methods? Like increment decrement, maybe this. Okay. Actually for, for a start. So I'll start through that and then we can see. A fair with this herself. So I'm going to call this a step count context. So great. It's context. I'll say the default valley is now like a day loop, make it throw. If it gets used, but. Yeah, and we would want the. Make this a. Provider. For this thing. And the thing itself is. And ideally this would be minimalized, but I'm going on that I'm not going to do it for now. So. I would actually just spotless. I think in this case, I'll start at the, with just bus. And then we can discuss why. Might be a better idea. So I would just. At the count and. Here. The set count. Use context. Sit-com context. And I did the same here. And I would. So, because that don't actually have. I don't have. A little bit. Because I don't have access to the account. I'm going to use the. The update their function so that doesn't have the boss of him because. I can just do that anyway. Yeah, I think that. Well on that. I don't need this and I don't need. Oh, wait. I don't need this either. Yeah, I think. I would expect this. No, it doesn't work. Oh, So count is not a function. Oh, okay. Because I posted. As an object, right. So. Yeah, it was an issue. The posture things. But the nice thing is have other needs. Is it because it's going to be stable. So, yeah, so this works. The parts that I'm like not. It depends on how realistic the example is. Right? It's like we, if. Like we in practice would probably don't want the pass. The state center through context. Anything that the. Wants to use it because then it's very hard to tell. Like, what is the different parts of code that trigger it? And like, they don't have any limitations of what they could do. Right. So. I could. I could. Solve that by like Boston, specifically like increment and decrement as functions. So that we limit. What's what's components below can do. Our state. Or I could, another pattern that is pretty common is to pass a dispatch function down. And then the dispatch function kind of has like a switch that says, like, if you boss like an action that says like increment. And do this, otherwise do this. And the user reducers kind of a built-in way to do exactly that. Nice. Yeah, I like where you're going with that. Thought process. And I think that that maybe leads me into one of my followup questions here for you. So don't worry about implementing this one. I really just kinda want to talk through this with you, but how would you take this app and evolve it so that it could support in undo functionality? Where, if I like increment increment Decker manage, I can hit the undo button three times and it's going to end up back at the correct state where it was previously. Hmm. So how, how. How much do you want the. Does it remember? Like all. Updates or. Like, do you want to keep history? Forever or do you have like duke than a window? Like last done actions, like. How do you want. At the work. I think you can assume some fixed buffer of number of actions that you could step back through. I think that's usually a reasonable assumption, although I would be curious to know how you would do an infinite number of action. Yeah. Well, I guess. Like one thing you could do is just snapshots. The like every time you change the state, you also, like you have a separate state that is like in there, like a history array and. You're going to push the. Like, as you were about to change it, you pushed the previous valley into that. Like you have the history to have the thing. And so when you go. When you press on to you. We like, there's a question, like, do we show. All the under stack or. Did you just want the button to work, but essentially we just, we said that the count, the, what was in the history at the time, and we also make sure that we don't accidentally push. History because of it. So I think we would need to. So, for example, if you say like, if you do. Do you like five times? And then you increment the game. We need to make sure that we've discarded the parts of the history that is to the right, or like after this step. We're currently. On, because. I don't know if I'm making sense. I think what I'm trying to say is that. Like usually in the app. So with undo stack, You, if you do a bunch of fun dues, And then you do different actions. You need to make sure that the things between the parts to which you undid and the, in the. The state, if you were in, like initially they get this car that like, you don't want to keep that from history. Yeah, that totally makes sense. And do you see any ways that that sort of keeping track of, you know, the actions that have been executed on the app? Are there any kind of intersections with the dispatch pattern that you were discussing previously? Yeah. Yeah, like. Like. Depends on like how inefficient. He wanted to get. Like conceptually. One way to. Like one way to think of it. That is really inefficient, but it is. This is kind of a nice way of thinking about it is. Like alternatively, instead of keeping track. Off. Of the current state. You could give track of only, only of the actions that happened. Right? So like, Conceptually, instead of having the current count. That just kind of materialized, you could instead have only history and you could have like a point where you are in the history. So kind of the current index, which would normally be always incremental. When they press on the. You would like go up the stack. And the way you've calculated the current valley is just like replay all these actions through like a, something like a producer function. Yeah. So you could always calculate the current count from scratch using the initial valley, which is zero. And then the history. Erie or like that part of it that you're currently like materializing, but this is really inefficient, right? Because like, it was half the eat the way. Every every time you want to render something. So that's, that's not actually a good idea, but it is conceptually like. I think it is a nice, nice way of thinking about like actions. And that, I don't know if that th that is the connection he wanted to make. Like the, the reason I see the connection is because the, like, this kind of action log is something you naturally get from. Like riding your function as a producer and then describing each thing as an action. As in like, isn't the object. And so you, like when it called dispatch, you, you kind of push to that action queue. But I think also I actually like. I think it is a very naive approach to undo and redo. I don't think it's actually a good approach. Because in practice. If you. Can you identify implement the complex. If you try to include massive, like a graphic set of Thur, like ex-colleagues all, for example. And the wanting to implement undo, redo. It's not good enough to snapshot like the state every time it changes. But because actually, like, for example, if you're adjusting some parameter with a slide there, you don't want to. Snapshot, every intermediate valley, even though in the UI, you do actually want to reflect it as it happens. So there's some kind of group in that is necessary for undo actually makes sense. And so it needs to be intentionally designed this. That's just a matter of snapshot into state, but every point. Right. Yeah. So kind of keeping like a, almost a D bounce of when you're sort of sampling those changes. Yeah. That makes a lot of sense. And I think you had a previous question too. Which is sort of like, was that the right connection? You know, I was looking for with dispatch, but no, you totally nailed it. That's. That's one of the things I love about that pattern is that it captures the actions that are occurring to your app over time. So, yeah, that's awesome. Okay, I've got just one last question here for you. Before I hand it over to my other interviewers who are going to talk. For some other technical and Adrial questions, but I'm curious, how would you rearchitect this application if it needed to work in an online fashion? Where other users could also increment a document to counter. Hmm, that's interesting. I don't know. So I think there. Well, there should be something centralized. Like there should be, there should be. I think like there should be some. Something that is like the source of truth, because. Like, I don't think it can be kind of peer to peer in the sense that. There needs to be something that, that decides what is the economical. State of the counter and you don't want to like, None of the clients going to really know that because it takes a while for the response to come back. So none of the client's going to be like set it. They can own this because otherwise you'd have race conditions where. Like a client thinks the counter is 200 declines. Japan at one, but actually has been implemented by somebody else in the meantime. And that gets lost. We can't do that. So I think what the clients need, like there should be a server, like something that keeps track of the current count. Each client needs to send the, the action. So the client needs to send, I want to decrement or like, I want to increment. And then the server decides. What is the services? Receives the requests and decides what is economical state. The server makes sure that we can go below. Is it, well, I guess in this example, we actually can go below zero. It's allowed. So, but if we were not allowed to do that, then it would be up to the surface. Make sure that this doesn't happen. And then the server in like, as a response to the request. The service sends the current canonical count. The. To the client, but also the clients need to be notified when somebody else changes. The the accounts. So I guess. Like they would either have to kind of full the server periodically. So maybe like once a second ask. The server has the change has the. Changed. Or there needs to be some kind of persistent connection, like maybe like WebSockets connection. Where the server kind of every time, the count changes that server pushes the update to the clients. Yeah, I think, and initially of course, funny, loaded that needs to give you the, the current county. Yeah, I think that that's a great talk to her on that. And yeah, I definitely see where there could be some contention between clients almost sort of edging into a consensus algorithm area. I'm, I'm mostly just happy that you didn't decide to like, try to build a blockchain to solve this problem. So. Okay. Cool. So that was the technical coding challenge part of the interview. Thanks so much. I had a lot of fun and now I'm going to hand it over to my other interviewers to go through some other questions. I think to keep things simple and not to confuse too much. Why don't we just go in the order that we introduced ourselves again? So Juliana, do you want to kick us off? I was going to say, does anyone remember that? I'm kidding. Thanks. For that walk through. I think you can stop sharing your screen. We're not going to be using. Okay. So I will kick off or doing one question and then rounding, right? Interviewers. Yeah. My question is, could you walk us through a technical trade-offs that you worked through recently? Hm. That's. That's when you say recently I've been the bike in a lot of documentation. So I'm, I'm actually a bit rusty on the code in. Can I give me like a minute, the thing just to kind of reflect. Yeah, no, and no pressure. It doesn't, we're not going to know if it was recently or not. You can pick your most interesting one. Hmm. Well, I think maybe that, I guess. That does relate to documentation. Like. We. Want to have. Interactive examples in the documentation. So we wanted to have. Like code blocks that have previews with them. And that you can add in the. Edit the code. See the results in real time. And so on and. There, there is a bit of a trade of there where, which is. There's a bunch of codes we need to load, and there's a bunch of. Like there are questions like, okay, what, what are they do? Syntax highlighting. Like do, if you. For example, if you do. If they're doing kind of classical documentation, but just like cool. The blocks in the middle of the text. It makes sense to do the syntax highlighting, like at the build time. So that if it's already kind of pre-compiled and when the user loads, the HTML, before it is hydrated, Which I was scripted. The user can already see the highlighted then, but then. The thing with that is that it doesn't work. If the user can edit the code. Right. Because we somehow need to, like, we highlight it. According to what the user has, has edited. And so. In that case, we would have to ship the code for highlight into the, to the client. And then there's this weird case where if you started editing before it has hydrated, like. Like what. What do we do? Because we haven't actually loaded that. And it's maybe it's, it's, it's kind of like, maybe it's possible the. Have a nice solution to this for now, with the June is we don't actually highlight. The goat on the server at all, which escape. You know, we just keep it plain and then all to highlight in an older kind of reach interactions. Are they happen on the client after hydration? I'm not super happy with how it works right now. And we're also loading too much goats. So like the, in terms of interactivity like that is like, we kind of went like full interactivity. To the side of the trade-off, but then the load Anthem kind of suffers. And some of the, some of the, like, if your internet is slow, There's a bunch of like, [unknown]. We need to solve and so on. So. We need to kind of. Like work backwards. Actually like improve the user experience there. For people with like slower connections and stuff. Awesome. I don't know how much, if a train go. With this as it's just like. What are they cared about? The functionality? But we do need to kind of fix up the, the philosophy introduced because of that. Thanks for thanks for answering. Like donate what next? Sure. Yeah. So Dan, I'm wondering if you could walk me through your code review process. When somebody. It says, Hey Dan, can I, can I get a review on this PR? What. Yeah. Walk me through your process. And what do you look for? Yeah. Hmm. I think the first thing I look for is just like understanding what the hell. It is supposed to do so it's. Helps to have a description that. Gives an awful high level idea of like, What the cook. I want them to sound like. What the code was doing before. Well, the code is supposed to be doing now. And like why this approach is a good idea. Like why that is, that is the bath we take there. And. If I don't understand it. Like I do. I think like for this, I kind of look at tests. I see. See, like, okay, well, what tests did you add? Not in terms of verifying the change with more like. If you're changing. Well, if you're. Like presumably there is some effects of what their code is doing. So I want to know what. The intended effect is, so I kind of retest this documentation. I do want to preface that I worked in the library. I don't work on. Application code. So like an application code, a lot of just a really bad, like sometimes it's better not the right this than the right. The kind of tests that people sometimes, right. So, I'm not saying that like for application code, Like if I was reviewing like a, something that changes some UI, I would load that UI. Right? Like, I would actually like click on it, see like, And we actually expect like, We expect if you change the UI, you'll have a video with that. What the hell he was like before and after, because I want to be able to revisit them like five years later when I'm. I trying to change something. I want to know what you were trying to do with this line of code that I'm trying to remove or something. But yeah, I, I looked through the test. I kind of get a sense of like what the changes meant to do on that. I look through, they go, they scan for maybe. Like full common mistakes in general. Like, do I see like, is this. You said a race condition. Does this add like a, like a potentially no, a check or something that is like now, like, Something that is just looks kind of fishy from the coding standpoint. But also look out for. Like, does this seem weird? Compared to the rest of it. Like, does this seem like this addition is really. Doesn't VI. This is so like it doesn't vibe with the rest of the code or does it feel like it. It's like added without consideration for how they, you know, the code is already structured like that. Does it feel like it's written by the same team or does it feel like it's something else? And if it feels like it's something else, like usually there's just a bunch of different conventions, maybe different styles of right then. So I try to look out for that and. Not in a sense that that would be like, oh, we, you know, you have to do it this way. But it helps to like have some consistency. And the other thing I look out for, again, I work in the library on library code. So for us, like Destin is important. So I. I try to make sure I check out the code locally and I visited a common thought. Comment out some of the changes. And see, like, does anything fail? And if nothing fails, I'm like, well, I don't know, like how can they prove that this, this sexually, the it's something useful? So I'm, I'm looking for things that are uncovered for that. If I flip with the condition, like nothing happens. Yeah. And then if I feel like. If I. If I understand what the behavior is supposed to be. Like, I kind of feel like I have a spec. For what. What it should be. And also like I have the tests that verify. That it actually works. And I looked through the code. Makes, I don't see any correctness issues, others. The performance issues. I don't see like coded in the hotspots that, you know, we're supposed to be fast and so on. And. Just seems like it makes sense. Then. It's probably fine. And then if it's not fine, we have the desks. So that. We can rewrite the code, but at least we have the behavior respect. Awesome. Cool. Not really. Really great. It's steep. Your witness. Yeah. Then I just had to kind of an open-ended question, but how would you go about debugging performance problems in an app specifically? Like maybe the initial load. Hmm. Well, I would want to understand what it's doing, I guess that is. That is kind of the, the most important thing. Right? So. There are different tools to help with this. Like. Like Chrome performance timeline is pretty good. As the human that we're talking about, the client are being slow. Now the silver bar being slow because if the server doesn't matter, Things before. Like I would need to look at when does the request actually arrive? Like when did we get the first bites? And so on, but if the server part of is fine, but then the client. It's kind of slow. Like, I would just need to see like a kind of a bird's eye view. What is happening like. It could be, we're running a bunch of Charles' skirts on the main thread that is going to blog. It could be that. There's some kind of like the slow network calls. Could be that they're like waterfalls that the. KA that I liked solvable that. We don't start loading something until something else has loaded. But we could affect. So maybe looking for those parallelization opportunities. But yeah, I think mostly like profile and high level architecture, because like sometimes the architecture is obviously not, not good. And then it's not unexpected to. You know, it would be slow if they act. Lecture is. Kind of slow. Okay. Yeah. You'd mentioned a parallel live in. Long running tasks. If you find we are loading way too much JavaScript. Yeah. Well, it depends on like, if we need to load it or not. I think that that is an important question. Like. The way that we need. Because there are cases where like, if we were implementing like a father shop, In on the web, like. Like it probably needs a load. Like. It's just unavoidable. Right? And there's nothing you can even show before it's loaded because there's just nothing useful. You can that. That is the premise of the app, right? But then like, if you're a re. You can make him like a. Like a conference website, like, I don't know, like. Like a music reviews. This something like, then it probably doesn't make sense the block on. So there would be question of. Can we show something before the child skipped loads, do we have to load all of the JavaScript with bonds of a load in JavaScript that is not being used? Like can be like code splitted. Can we just like move some of this to the servers so that we don't even process something on the client? So, yeah, I think it's co it's. Like bro, this speaking, I would look at. Why have a load in this JavaScript? Is it being actually used. And at which point does it become critical? Right. Like, is this critical? Before we can show an infant because there's just nothing to show without it. Or is it kind of like a, an enhancement thing that can be added? You know, on top. Or is it just completely accidental and shouldn't be loaded in the first place. Or could it be looted like later when a specific kind of functionalities used. So it depends on what sometimes, like maybe we're using some kind of, some of the library that is written the large, but there is an equivalent that. It is much smaller. So it, it depends on what, what exactly we're doing. Yeah. Yeah, that sounds that's great. It, it depends. Independence. That's it for me. Sweet. Well, we. I got, I think four minutes left. So if anyone's super excited to ask Dan one more question, I'd say, jump in and do it. And then we'll end at the top of the hour. Dan, thank you so much for doing this. I posted this question a little earlier, but I was just wondering what your thoughts are on context versus. And when you would use one over the other. Yeah, I do get asked this a lot. Like. And every time I answer, like people like make a thing out of it. I don't think about it. Like it's not something I think about at all. If I were like creating a new project. Is difficult for me to think of a reason to like add the Redux. Not because like, I think like I don't. It's bad or anything, but because there. Like, why, why would I do it? Like. Like, there should be some reason to add it. Right. And like, for me, it just the kind of projects, like kind of. Like I spin up some hobby projects sometimes. Like they're pretty small. But. In general. I would think that if. It depends on like, what do you want to put in it? Like. Y Y. [Unknown] if it's something like server. They either like something fresh from the server or you want to keep it somewhere. Then. I don't think it makes sense to put either in context or in Redux, like, like usually there are libraries that are more specific for specifically like server cache. They're like you're squarely or polo really, or there's a bunch of them, but essentially the. They handle that kind of logic because it's not really a stateful. It's more like, like a snapshot of something that leaves somewhere else. So I wouldn't use it either for that. I think. And then for cases like UI state, like I think like you just stayed then. Put it's. If it's really. Like a lot of it is local. Like for a lot of it doesn't make sense. Like, if you have two things on. Of the same component on the page. Like, do you want. Like edits and one of them through immediately, like if it had like two posts rendered side by side and they type in a comment and one of them. You probably don't want the comments a bit types. And the other one, like. Look silly. So like that when you kind of do that kind of mental best for like, is this piece of state to local or not? Like, I think in a lot of cases, Isn't that ends up being local. So I would just like use local state determine where, where it should leave in the hierarchy. And then in the cases where we, and then the things that like, when I saved the post, yes, they should be updated, but this, because there's snapshots of the service state. So again, that, that is kind of the. The server cache thing. And then the remaining cases, like maybe you do have some kind of state that is global English, like to themes, to mature or something like this, but then it's also got a few Irish, like I think of it. Yeah. It's just the state of the entire application. And like, it does make sense for me to use context at the top. And then there may be, get cases where. Sure. Maybe you have some kind of weak rendering because of that context and this kind of slow wish, and you can easily like mean wise specific pieces to kind of optimize it and then get a look in for escape patches. And you're just looking for a thing. Like how can I update. A bunch of components. Without, you know, Without causing like a big pre render. And that is kind of incidental, right? This is not like. It's not that. Like if, if that were in the pro. Like, if there were no performance problem, you wouldn't. Reach for another tool in this case. But like sometimes you do because it's just doesn't work well enough. And so in that case, you might opt for like Redux or handwritten, like. And the reason event. At the meter or some other library. But. Yeah. That's, that's maybe like a case where I would add something, but not because like, oh, it's redox. I need to add a. More like, but like, yes, I've run out of options. I don't know what to do next. I might as well, just put this thing and see if it helps me here. Awesome. Thank you for clarifying. Appreciate it. Well, we've reached the top of the hour. So yeah, I just want to say thanks so much for joining up with us today, Dan, to do this a mock.
