On this episode of React Round Up we chatted with Miroslav Nikolov, a UI developer at one.com, about his approach to unit testing React components. Miroslav discussed writing components in a human-friendly way, using the library UnexpectedJS. We also talked about Miroslav’s blog, including how he got started with it, and some of the tools he used, like Gatsby and Mailchimp. This is a great episode if you’re looking to learn more about how to approach unit testing in React.

Welcome to React Roundup, the podcast where we keep you updated on all things React related. This show is brought to you by Envoy and Top End Devs. Envoy provides high quality design and software development services on a client friendly business model. Unlike all other software agencies, Envoy allows clients to only pay after the work is delivered and approved. Visit envoy.com to learn more and reach out if you know a company that needs more professionals to help with design and software development.

That's unvoid.com. And Top End Devs helps you stay up to date with cutting edge technologies like JavaScript, Ruby, Elixir, and AI. Visit topendevs.com to join their AI Dev Boot Camp, weekly community meetups, and access expert tutorials. I'm Lucas Paganini, founder of Envoy, and host of this podcast. Thank you for tuning in.

Let's jump into the episode. Hello, everybody, and welcome to another episode of React Roundup. My name is TJ Van Toel. And with me on a panel today is Paige Mitraegas. Hey, everyone.

And our special guest today is Miroslav Nikolov, which hopefully I, I pronounced that correctly, but Miroslav, welcome to React Roundup. Why don't you tell everybody who you are, what you do, why you're famous, that sort of stuff? Yeah. Thank you. Hi, everybody.

I don't think I'm famous, to be honest. Speak to them. I work as a UI developer, mostly front ends. So one.com. It's a Danish company that is currently expanding, and, what I do is basically react.

And in my free time, I try to, maintain my blog, so turning my experience in some useful articles. That's like something like a hobby. And, yeah, I'm a family guy. I have, my wife and a kid, a boy, so that basically takes all our all all my free time. So I don't really have much time to spend on, site activities.

That's so fun. We were talking before. I'm very jealous. Denmark, Copenhagen is a super beautiful area. So I'm very jealous of that.

And your blog will will drop it in the the show notes as well. I like the design on it as well. And I know, like, reading through some of them, I know you wanted to talk a bit about testing and writing just human what you call human friendly React component tests. Do you wanna outline sort of that whole concept and what you mean by that to sort of kick us off here? Yeah.

It's it's basically, it's all about a library called unexpected JS. And it's I know it's not very popular, but what it does on what it adds on top of everything else we we have seen is actually a lot of plain English when you when you write your tests. And I'm using that library basically for the past 5 years, and I just decided to write an article which which is just a short introduction to what is possible with the library. And so I decided to write the article for CSS Tricks so that it's it's basically reach a little bit wider audience. And, it was very surprising that I think right now, if you write React component tests or just React tests testing, that appears on, on the first page.

And but I believe this is because of the strong domain of Sysys Tricks. So, yeah, it's it's also brought some discussion, because it seems like people prefer different style of testing, and, it's a little bit opinionated. But, yeah, there are some there is some positive feedback as well. So can you expand a little bit about about what unexpected JS is? Because that's actually a framework that I've never heard of before, but I'm I'm interested.

Does it work, like, with React testing library, or is it Cypress, or is it both unit and end to end? Can you tell us a little bit more about it? Yeah. First, just to say that I'm not a maintainer of the library. I'm I'm using it.

But as far as I know, it should be able because it works with plug ins, it should be able to use some of the plug ins with React Testing Library. So you can use React Testing Library and some assertions custom assertions on top so you can write your plain English tests. And behind that, it's React Testing Library. So it's, it should should be possible, though I haven't tried. Yeah.

And, I also kept a light version of the article on my blog. Just it's a little bit lighter without the introduction because currently, it's a little bit controversial on how on how we test, and I know the community is going strongly after React testing library. So people are sometimes picky when you did you present something unusual for you. Absolutely. New things are not to be trusted.

React developers don't have opinions on what you're talking about. Yeah. So how did you first come across unexpected? You said you've been using it for a number of years now. Did it somebody else introduce it to you, or was it just something you stumbled upon and you really liked how it how it operated?

To be honest, I didn't have choice because, when I joined 1.com, they they have already they already use have already using this library. And, some of the people who are maintaining the library, also work for the company at some point, though they are no longer part. But we're still we are still using it internally. So that was the reason. Any.

Yeah. Could you get a little bit into I know one thing you cover in your article is trying to write tests that are sort of when you say human friendly or easily readable. Could you give, like, some examples of what you mean by that? And I know, like, syntax is kind of hard on a on a on an audio podcast, but just, like, high level, like, how you approach structuring tests in a in a human friendly or in a more readable way. Yeah.

So, basically, what we use is the usual arrange, act, assert kind of thing, which is I mean, you first arrange your test, then you act on it, and then you assert. So this is basically shared approach for, I think, for every testing library. But what, unexpected does a little bit different is the the expect assertion. It's just a function expect, and inside you pass as many arguments as you want. And these arguments are are just plain strings.

So you don't really have a Jquery Lex, syntax like dot not, dot equals, or dot to be executed. It's just plain English, and, usually, the editor is colors that in, in the same color. So it's very easy to read. It's easy for the eye. Maybe not so straightforward to write it because your editor won't help you to autocomplete different function calls.

But it's, it's it's really, yeah, it's it's really easy for the AI. And we we are working in a in a team, and it's basically usually not just one person who is working with these, file testing files. So you want something, expressive here. This is very cool. I'm I'm looking at the article right now.

I guess one question I have is how how long do you think it takes a new developer to get up to speed with using something like unexpected? Like, most of us, if we've been working with React for a while, we're probably pretty familiar with Jest, maybe familiar with Enzymes, maybe familiar with React testing library. But how easy or difficult do you think it is to to get up to speed with unexpected and then start to potentially integrate it into your any existing testing frameworks that you might have? I think it's it's pretty easy, especially if you use examples as, a real examples as a reference. Maybe documentation is not going to be the fastest, path, learning path.

But if you use examples, it's it's really easy. And, usually, you have just you have several common assertions that you would like to to use. And, you don't really use so many, different features. At least for the the React components, you want to test if something gets rendered. So, usually, you test, you query for an element and you you test for its string that it contains.

Mhmm. And, also, the other thing is testing, function calls. That is also straightforward. So apart from these two things, presence of certain elements and executing functions, you most likely rarely going to use other other, like, assertions, I would say. Yeah.

But it is very it's very straightforward, at least for at least for me, it was, as I remember. That's always encouraging. It's I remember when I was first learning React Testing Library, it was kind of a massive mind shift for me to go from the way that just an enzyme had been doing it to trying to reorient myself towards the way React Testing Library focuses on what's in the DOM and interacting with that at a at a unit test level. So anything that is easier to get up and started with is definitely always good. Yeah.

That's still something is, like, I'm not as in the weeds with unit testing libraries anymore. So sometimes a lot of this type of stuff goes over my head. And I'm actually curious, like, this this is a question, I guess, for for both of you is, where is the React world at right now for in terms of, like, testing markup structure in your, like, individual unit tests? Because I know, Miroslav, in some of your articles, you went in and you were, like, basically asserting against the exact DOM structure. Is there some advantages of that?

Or, like, versus, like, if I'm if I wanna test that my component render something specifically, like, how specific should your assertion be for I'm looking for this exact markup structure, or do you just, like, try to pick out an individual string? Like, I just care that it spit this out correctly. Like, I'm kinda curious where the React world is at with with that sort of setup right now. So from my understanding and what my team is doing today is that we're a lot more focused on the same basically, the same interactions that you would try and do in an end to end test in the unit tests. So it's a lot less about did this redux dispatch happen or did this particular function mock get called?

And it's a lot more of, can I see this element in the DOM? Can I click this button or is this button disabled? Did this list appear and can I interact with it? Which, like I said, it's a little bit hard to get used to when you're coming from the old way of testing, did this function fire? But I I like it a lot more because it seems to me to be a lot more true to life and how as how a user would interact with our application.

They don't care if the redux dispatch fired or not. They just care that they're list loaded and, you know, they can click the button and go through their shopping cart. So that's kind of what we've been leaning towards. So not necessarily, you know, is there this particular h one tag with this ID, but can I see, you know, my page title? Or can I see this drawer that is supposed to be there at the bottom?

And can I open it? Or can I click buttons and, you know, do different stuff like that within the components? So that's kind of the approach that we're taking, but I'd love to hear how other people are doing it as well. I would say that we're using the same approach. At least, comparing the DOM structure is something that we use rarely.

And I know that the community is pretty much with React testing library going away from that kind of assertions. So we use it rarely, and we mostly unit tests. And we have strong QA team, so the visual part is really for them. So it's not something that we really deal with. It's, we focus on the unit tests and edge cases, especially.

So that that's how we That makes a lot of sense. And then because I remember, like you said, Paige, the way it used to be is you would you would do things like ensure your mocks were hit or that your your testing structure. But it felt like a lot of times you were just writing those tests to write those tests so that you get, like, better code coverage and such. I like that just because it feels like yeah. I don't know.

The test just makes more sense. And I feel like there's a lot better, not just QA, but, like, visual testing tools now as well to catch some of these things. Like, I I think a lot of these, like, snapshotting tools are becoming a lot more popular as well to catch, like, if you did screw up some, like, markup thing and your buttons suddenly doesn't look like a button anymore, that there's some other test is gonna catch that so you don't need to, like, test your HTML parsing. Yeah. And, actually, that's something that I'd be interested to hear more about.

Miroslav, you said that you've got a QA team who helps you with the visual portion of it. Are they using that you're aware of, are they using any particular tools? Because visual regression testing is something that my team has struggled with in the past, but we haven't really found a great tool that helps keep that up to date. Yeah. They they have their own tools, but a lot of the testing is, I think, kind of end to end testing.

For example, adding a product to the shopping cart, and we follow the whole process up until the end. This is, what is important for them. Some I know some people suggest to write user stories as the part of the storybook, and then you use something like Cypress on top to visually compare, your user stories, your components. I haven't tried that. I think it at least for our case, it's going to be too much of an effort.

If you really do your homework with the unit tests, at least our experience show that we don't really face production bugs, and we are not really trying to have a full test coverage, just trying to test the fragile parts of our applications. So but, actually, we have a we have a product which was launched in, somewhere October. It's heavily used, and we didn't have, a single front end back for that product up until this moment. It was I think the team did a good job on testing and, iterations. So it's I know it's rare to do something like that.

But That's remarkable. It happens from time to time. Did you get a reward? Like I'm not sure if people notice that, achievements. They don't notice until it stops working.

That's the problem. Yeah. True. That's the thing about testing is, like, there's you don't get a if if you do your job right, like, no one ever knows that you have all these processes behind it. It's sort of the good and bad thing about it.

So I'm curious, Miroslav. What what made you want to write about this and start a blog and share some of this stuff? Yeah. I didn't do it before because I I suppose the our time is such a resource that we basically, it's not we we cannot regain its it's lost, basically. So writing an article I mean, junior developers writing an article is something that's at least I try to avoid because I don't think I I had something to tell to something valuable to take tell people.

And reading my 10 minutes, article will be, loss of time. So I decided to start writing maybe after 13 years of working in with web applications just because I I feel a little bit more comfortable, and maybe I have something important to say and people won't just spend their 10 minutes and forget after that. It's, it's a it's tricky area. At least I I feel uncomfortable. So, yeah, that's the main reason, I suppose.

And I have a lot of ideas and material during these years, so there's plenty of topics. I think after 13 years, you could be considered kind of an expert in development. That's that's a fair amount of time to see a lot of stuff. Yeah. Yeah.

Even in Explorer 6. It was there back back then. I remember. But yeah. 13 years is about where I'm at as well.

I started my first apps were IE 6 only corporate apps. So this is those are fun times. Yeah. Oh, I see here oh, go ahead. Please go ahead.

I just wanted to say that, writing an article about Internet Explorer 6 is probably, I don't know, it's not going to be very famous. I don't know. It's about time for, like, the nostalgia of that to to kick in because now now you can tell them it's like war stories, right, like, back in the day. Yes. It's true.

I mean, today, people are starting, with React directly. I mean, they they don't don't even, learn JavaScript. For them, JavaScript is, now it's something like React. And 5, 6 years ago, it was maybe jQuery. Mhmm.

So jQuery, Angular. I think, like and we're talking about testing too. They the thing that amazes me nowadays is for the most part, when you write your code, you don't have to worry too much about your code just straight up not working in other browsers, which, like, sometimes sometimes you do catch little things. Like, it's it's it's the sort of thing where you you still do kind of need to test your code in other browsers, but for the most part, you kinda don't anymore. Like, especially in desktop browsers, like, chances are the code you write is gonna work, and that's still, like, quite the mind shift from how it used to be where used to be you wrote your code and, like, you opened your you just prayed before you opened all the other 5 or 6 browsers you needed things to work in.

That's true. I to be honest, I don't think I go out of, Chrome, and I I don't really test on other browsers. Yeah. And you're right. Because even QA, they're they don't they don't find they don't find Sparksoft in other browsers.

So it's things things are working. So one question that I had is when I visit your website, site, the first thing I see is that you were previously a CEO and a CTO. So how did you go from being in charge of whole companies and whole divisions to back to a developer? Did you want to be less of a manager and more of a team, like an individual contributor, or how did how did that happen? Yeah.

It's, I think it happened naturally. Again, it's it was small company where I was basically, maybe I was a CEO, actually. I was doing everything because the owner was, were in, basically in Sweden, and I I was back in Bulgaria at that time. So I was managing the whole business plus the development for the company, but it was relatively small one. So it's it's easy to manage and to have many responsibilities, even accounting and things like that.

But at that point, I also started freelancing. So I I was freelancing a little bit, then moved away from that company, and then I met my wife here in Copenhagen. It was related to one of our, freelance projects. And Copenhagen is I mean, it's a really expensive city compared to Europe. It's probably the most expensive one, and you really need a full time job to survive here.

So this is how I ended up in the company's web developer. Yeah. Wow. So, basically, running a company wasn't enough for you. You had to do freelance work on the side too.

That's dedication. Yes. At some point, it's became too much. But, yeah, you can do it for some time before you burn out. Yep.

So looking at the blog, is your blog built with Gatsby? What what did you use to create this? Yeah. It's exactly Gatsby JS, and I was I was inspired by, Dan Abramov's blog. It used the starter theme.

So it's, really just the starter theme starter theme with some some tweaks. So I just wanted something simple up and running fast. And after that, maybe I will figure out a better design for it. But for now, it just it just works. It looks really good.

Yeah. I like the just the clean look of it and the fact that you have dark mode. Yeah. It's it's a default thing now. Right?

Everybody. Perfect. Sorry. And I also see you have a a newsletter as well. Yeah.

It's I'm trying to keep up with it. It's once a month, and I'm, I'm trying to send I'm usually sending, my art new article, which at least, I have time for one article per month. I can't really write more often. It's difficult with family. And one article per month and some interesting thoughts and links, maybe, I I have found.

But at least I'm I'm trying to write about the topics that you it was difficult to find a quick solution in by just googling. So if I can't really find a solution, I I would I would write about it. And I remember it was an article about something like a tutorial on how to create a a sticky table header, but with React, but by using just a normal table, not a diff based, like or Flexbox based layouts. And, it was surprising for to me that, actually, there are not so many examples that you can find. And this article is without any SEO.

It's now it's it's pretty high when you try to look for something like that in Google. These are your notice. Oh, go ahead, Paige. Well, I just noticed because, actually, I clicked on that article in particular. I noticed that you have unique reads, and I was wondering how you did that because that's a really cool little feature to have.

Wait. I don't think I know what unique reads are. Yeah. It's it's not Google Analytics because, it's so not straightforward to implement that thinking in your blog. And it's I just saw I just saw it.

Okay. Yeah. You mean, like I I see it now. So, yeah, this is in case anybody else here listening to this totally didn't understand it either, he has on each blog post the number of unique people that have viewed an individual blog post. And that is definitely interesting.

I don't think I've ever seen anybody just like, sometimes you see views, but I don't think I've ever seen anybody list unique readers. Yeah. I I it was reads, but then I found many blocks which are just counting the the visitors. So they have Mhmm. Yeah.

For example, they display 60,000 views. But that doesn't really make sense because I can reload my browser 200 times and then it's not really useful. And I'm using a third party service that is just a counter. And whenever your component renders, I just put in useEffect a call to this service so it will count, but in the same time, return back the number of unique routes. So this is the way how it's it's, done.

It's very simple. Yeah. No. It's like it might be worth a blog post. Yeah.

It's one of these topics that are not very well covered. If you try to search how to add some counter in Gatsby blog, it's it's all about Google Analytics, and it's so, so difficult to do it. It's funny, though, how little things like that people can find useful. One of my the most popular things I've ever written is I wrote like, my blog is a little bit older, so it's written with Jekyll. And I've I came up with some way, like, it's like a one liner piece of code to have the Jekyll, like, point to an external blog post.

So if you wanted to list blog posts but include things that you wrote on, like, other places, And that thing gets like I I don't know what but it's it's it's like a 2 paragraph blog post, and I it gets like it hit a sweet spot in Google. So it's funny how sometimes these things that you think are really little can be actually super valuable to people. Yeah. It's it's true. I with today's, situation, you can really easily create a serverless kind of service.

And because it's so easy and people don't really need to have a local database or to own the database Yeah. They usually use something like Firebase and try to easily, put together some third party services and, voila, it works. But it's it's not really I mean, so much efforts for for such a simple job. It's at least I I try to think about the simplest possible solution out there. So Yeah.

I like it. I I feel like the it's funny because personal blogs are the one place where overengineering something is, like, not only okay, but sometimes almost encouraged. Right? Because it's like a place that you can experiment and have some fun with. Yeah.

It's it's, especially when you are just starting, you can do a lot of experiments. I'm doing that a lot because I I don't really have so many, readers. So it's it's it's, yeah, it's now is the time to do crazy things. I mean, when you get a lot of readers, then you're they came for the crazy things, so then you gotta keep doing it. Yeah.

And they can even see, 404. Yeah. The, go ahead, Paige. We keep doing this. Oh, no.

Please continue. The other thing I'm wondering about, speaking of, like, little implementation details, what are you using to implement the newsletter? Yeah. It's, Mailchimp for now. They, I think they they give 1,000, I think, subscribers for free.

So it's, yeah, it's pretty safe our choice for me, but I may change it in the future. And do they give you the little like, you have this little section in your blog post that encourages people to join. Is that something they provided, or did you code up the design for that yourself? Do you mean the pop up? The little thing that says join a front end newsletter, like, little thing that entices people to subscribe to the newsletter.

The form on on the bottom? Yeah. Yeah. The form on the bottom is just a custom made. It's not really Mailchimp.

I I just post to their service. So it registered the email address, and then I just display a confirmed message. But it's not, it's not Mailchimp. You've got a little bit of design talent because that thing looks really nice. It's very cute.

I like it a lot. I know you say you're using, like, the default, theme and such, but I can tell you've tweaked this quite a bit. It looks really nice. I'm I'm jealous, and I might steal this. Yeah.

It's, it's an evolution. Are you hosting a newsletter on your on your website, TJ? No. No newsletter. But we do stuff for, like, kinda react and progress sometimes, and we definitely take some inspiration from this.

Yeah. I implemented 1 on my own personal website, which I launched, about a month ago when we're recording this anyway. But I and I looked at all the different email providers like Mailchimp and Mailgun and Convertkit, I think also. Convertkit is a big one. I ended up going with one called Substack though.

And the thinking was that Substack doesn't charge you based on the amount of readers you have. It actually charges you if you start to monetize your newsletter. Because my blog is exactly what yours is. It's just a personal one. I write tech articles.

I post them. And if people wanna get notified when I do, great. But I don't really see it ever becoming some sort of a monetized thing. And I even though I'm very early in my own website or my redo of my website, I guess, the idea of of crossing those subscriber thresholds, and then having to pay $30 a month, $50 a month more than that just to send a newsletter probably once a month just makes me really unhappy to even contemplate. So that's why I decided to go with Substack because it seems like it doesn't matter how big your subscriber base gets.

They will not charge you. So it's a little bit weird because it takes you off of my site when you subscribe, but my thought is I can write short blogs on substack that link you back to the blogs that I've written on my site. So it seems like a decent solution for the meantime. And then, I guess, if I ever wanna change it and start paying or if I decide that I will not get a subscriber base that warrants that, maybe I'll go with something more sophisticated that keeps me keeps users on-site like Mailchimp or or something in the future. Yeah.

I also heard about Substack. I actually have seen, Kent Beck, for example. He's using it as well. So and he's, someone with, I think, big communities around him. So but he's posting in there.

Oh, well, that's that's encouraging then to know that people who have big followings are using it to their advantage too. Yeah. Yeah. And all the cool kids have newsletters. What am I even doing with myself?

It's Apparently. Just like all the cool kids are starting tech podcasts. It's like there's more podcasts than there is time in the day to listen to them. Yeah. That's true.

Mirosoft, is there things that we haven't covered? I know anything about testing or components that we didn't get to or ask you. Oh, I think we touched the basics. And, yeah, if if we have to wrap up, it's just it's it's very controversial, topic. And I think some sometimes people are too dogmatic about what we should use in terms of libraries.

I think, James, it's all about it's all about what you really can do in your certain situation with your team, with your organizational structure because some things may work, but others won't work in different organizations. Do you mean it's controversial in the sense that, like, some people give the impression that, like, you have to use the popular thing or else you're doing it wrong sort of thing? Yeah. I mean, for example, if you, do a lot of dumb comparisons in your tests and you are publicly doing that in, form of blog posts or maybe tweeting about it, you will get a lot of people commenting that, this is definitely in the past, and you should not do that. I see.

I have even, heard that, okay, testing if a function is called, by clicking something in your UI is also not a good idea. So it's some people could be really dogmatic about about, these things, but it it's really what works for you in this particular situation because sometimes, dumb comparison may be required. And, sometimes you want to test for a function call, especially if it's somewhere between conditional logic. So you should really think about, yeah, what works for you. Yeah.

I feel like that's that's good advice for I mean, React testing for React or just software development in general. Like, it's, it's good to have sort of best practices, but at the same time, like, don't yell at people at on Twitter for for things that they're doing that you don't totally have the context for either. Yeah. That's why I don't have Twitter. It's also probably a good idea.

It takes too much of my time, and I don't really have time to get into conversations and, yeah, write and tweet about irrelevant. Cool. Paige, did you have anything else? No. This has been a really interesting conversation, though.

So since you're not on Twitter, if people want to find you, where can they find you online? If you just go to my blog, you will find a few links. Probably the best way is by just email, and, I have also LinkedIn and, GitHub. So this is the way to do it. Well, cool.

So why don't we move on to the picks then? Paige, do you wanna kick us off? Sure. So my pick this week is gonna be a show that has been out for a while, but my husband and I have been recently rewatching it with, one of our friends who hasn't seen it before, and it's the Jack Reacher series on, Amazon Prime. And I believe that it's Tom Clancy's Jack Reacher.

It's based on the books, and it is just rewatching it after having seen it, you know, a year or 2 ago. It's still really well done. It just sucks you in, and we can't stop watching it. So I would definitely recommend that one if you're looking for something else to binge as we slowly start to come out of the COVID haze of the past year plus. So I think that that is going actually, I'm sorry.

That that is the movie with Tom Cruise. What I'm thinking of is Jack Ryan, another Tom Clancy novel. Please don't write in into the show notes about that that I got it wrong the first time. But Jack Ryan is, the series. There's 2 seasons.

It's a great watch. I would definitely encourage it if you're, like, if you're into the spy, espionage, CIA type of, shows. Okay. I definitely remember seeing the the ads for this now. So I want to check it out.

It's a good one. Cool. My pick for this week, I got a I've been getting my bike out a little bit more. It's been nicer here in Michigan. And I got a little thing that's a just a quick and easy speedometer for it, which I kinda like.

It's kinda fun to, like, challenge yourself to see how fast you can go without dying on Michigan roads. But it's, did a little bit of research and found one I like, so I will drop that in the show notes. And I'll just pick biking in general. If you're not a person that likes biking, it's fun times. Miroslav, what how about your picks?

I think I have 2. The one is, I recently, found out that Eric Krasmus and the the person behind the React final or, yeah, React final 4, he also starts publishing his blog posts. And so right now, he has a blog, and he's one of the people who I actually learned a lot. And I think he he has what to say, and it's it's good to if you if you really want to read something from the people behind React because he's, he's programming in React for quite some time. So you can you can visit his blog, paste the link.

And then, the other one is just an article I read recently from, Kent Dodd's newsletter. But the article itself, I think it's not it's older one. It's not new. But, basically, he's talking about, that in many situations, you don't really need a global state management solution for your application for your React applications. And, that is also the case with many of applications I I have done.

If you really carefully think about if you can do it just with React and maybe a little bit of context, then, yeah, you don't really need Redux. But the article could be controversial as well. I will just put that link. Yeah. Yeah.

We've had many discussions in past episodes about that very controversial subject, which you just mentioned. But Mark Erickson, who was a guest on the podcast a little while back, did a great job of kind of explaining the difference between Redux, which holds the global state versus context, which just passes state around the application but isn't actually in charge of holding it, which made it a lot more clear to me kind of when you might need one versus the other. But I completely agree with you. We we, as engineers, have way over engineered a lot of applications to use Redux when we probably didn't really need it in the first place. Yeah.

It's true. Some sometimes we inherit habits from previous applications, and we tend to copy and paste the same approach. Yeah. Well, cool. Well, thanks, Marisol, for joining us.

This was a lot of fun chatting with you. Thank you too. Alright. Well, thanks everybody again, and see you next week. Yep.

See you next time.