Hello, Welcome to React Roundups, the podcast where we keep you updated on all things React related. This show is sponsored by Raygun and produced by Topendeves and on board. Top and Doves is where we create topendves who get top and pay and recognition while working on interesting problems and making meaningful community contributions.
An Void provides remote design and software development services on a task basis, so clients only pay when tasks are delivered and approved, which is the safest way to extend your design and software development us. In today's episode, we will talk about the libraries we used in our general React projects. So which libraries do we commonly end up installing in our projects. My name is Lucas Paganini. One of the hosts in the podcast and joining me in today's episode is
Chris Ruen, Hi everyone, and Peter Ossa. Hi. Everyone. All right, so let's get to it. Chris, let's start with you. So what do you generally use in your React projects? Of course, the main question is with regards to libraries that you end up installing, but it could be some other form of utilities too. Yeah. So I was taking a look here at one of my recent projects, and of course I can't believe I forgot it is the top one would have to be bootstrapped, so
I'm a big bootstrap guy. I know tailwind is catching on, so there's that one Otherwise, also though, I guess like staples for me are of course the React reducks library and then the the reducs toolkit, so those probably I have probably in almost every project. And then along with Reducs, there's a nice Persist library, and basically what that does is handles a kind of keeping. You can configure what you want in your reduc store to stay in
local storage, for example, or different parts of your state. So those are a few. I think as we go through the episode, maybe we can get into some more some other stuff I'm always on the hunt for, like charting libraries and things like that, and other UI libraries, so maybe
we can get into that. I actually have some questions about some of those libraries that you mentioned, so before we go to Topeter, you meant this last library, which is to persist the state of your reducers into local storage or probably index TB two depending on the size of your state. I'd like to know a bit more about this library, because I think a lot of
people. If it's like a very transparent addition on top of reducts, I think it could be beneficial to a lot of people because they can get rid of that initial load in which you don't have anything to show, and you can at least show the stale data that you had from the previous session. So I wonder how much setup do you need to integrate that with React reducts, and yeah, just overall, how do you use the library? Yeah, so it's pretty I mean for just an initial configuration, I think it's
pretty painless. You just have to add a few lines to like your wherever you're configuring your store, and that's where I mean. I think initially by default you can just say okay store at all and that's it's like two or three lines. It's all on there on the project's get hub, on the on the read me. But then, of course typically it makes sense. You know, you're only persisting I don't know certain parts, certain branches of your state. And I believe I'm not lying. I believe it also can
work or React Native, but I'm not sure. It's been a while since I worked on a React native project. Yeah, like you said, it's it's super nice. Uh, so that you don't have to write any of that local storage logic yourself, because that can always be kind of true, or or you get stuff that keep sticking around when you don't want it to, and and and so on. So yeah, it's it's not too too hard. I guess it's the my final answer. It's pretty easy to get
started. And again, what's the name of the library reducs persists, So reducs dash persists should pop up. Oh yeah, interesting to know about it. It's true this right. Have you used that one too, Peter, Yeah, yeah, yeah, I actually used this for all my and all my podresdocs. It's kind of really could in the sense that it's you.
I think you. I think you don't need to add it to where you're creating your redoc store, and that should you walk out right to it to just kind of persist every store you have to stop so you don't need to worry about that fast love, but you have empty datail something. Yeah, it's really good, you know. I think it's simple and of adopt the mp MPM on the chart here. I sent it on the comment section two for anyone listening that wants to check out the link. Yeah, and Chris,
what about other areas? So for example, you mentioned stuff very related to state, but there's also testing. So for example, I don't know if you use Jazz or uh, Jasmine, Karma whatever for unit tests and for end to end tests. A lot of people are starting to divide themselves between Cyprus and Playwright. So there are those other complementary areas too, And even in terms of your package manager, like do you use NPM yarn bun Yeah. So if I'm a I do like Jess, and I'm a Cypress
guy as well. I really like the Cypress project. I think they do a really nice job, and you can even I know it's like the priority or or the main I guess like the main thing you would use it for is end to end test. But I've even written just because it's so nice to use. I've even written like integration tests, and they have ways of doing that as well, like API tests. And I'm also so this is a maybe it's an unpopular opinion. I am an NPM guy through and through.
I have always argued against YARN. I think I understood why there was yarn like long ago because something there was some like major almost like a bug in NPM. I can't remember. It was so long ago, and issues that Yarn kind of stuck around. I think just because of that, And I don't know, I've never seen I've actually had issues when I tried to use Yarn and install stuff, like everything would break. So but I'm very opinionated about that, so I've always used MPM and never had a problem.
For me, like because NBM is the it just seems redundant, like there's an extra package around a package manager. I don't know. You guys can of course totally go against me, because I know there's huge fans of Yarn, but that's just me. So I think most people that I spoke to there in favor of Yarn say that it is just more performance. But honestly, I never felt that the performance differences between Yarn and NPM were enough for me to consider switching to it. It's like it's gonna take a while no
matter what you do, because you're installing everything. So it could be faster if you just install the packages that you don't already have installed, but I don't even like to do that. I prefer to do a clean stall when I'm just pulling a branch that has updates in packageason, I don't want to just install the differences. I want to clean everything and reinstall. So I
don't think YARN would make much of a difference there. But and by the way, I actually even think that if you're comparing, if you're deciding Yarn just because of the performance benefits. I'm not sure about the benchmarks, but I believe P ANDPM would be even faster. So if you just choose something based on marginal performance gains, then you're going to keep switching them all the
time. But what I did, and it took me a while because I've always just used NPM, just like you, Chris, I've always been in favor of just MPM. There was no reason for me to explore the complexity of learning another package manager, and every time I tried to use others, I had bad experiences. In some cases, I don't have a choice.
It's just a project that I don't control. So yeah, but what I am doing currently is using BUN only on CI and only on CI first, because Bun, as far as I know, has not yet released a version compatible with Windows, so I can't encourage a team of developers to use it if the support is not there for everyone. But when we're running on CI, it's saw Linux, so there's not been holding us from using BUND there.
And you can't use BUN just as a package manager, not as a node, not as a full replacement for node, because it can also execute JavaScript and types could go. But you can use it just to install the packages. And to me that actually made sense because the differences between installing with the BUND versus NPM are really major. It's almost like two or three times
faster if you're like doing a clean stall. If you already had some of the dependencies there, it would be even faster, but if you're just doing a clean stall, it's still faster. So just because in CI, I want to optimize things as much as possible, because I hate the experience of a developer finishing their work, sending it to get help or something, and then having to wait five minutes to get an answert, you know, So I always try to optimize CI as much as possible so that it runs in
like ideally up to three minutes, but it should give you. It should cash as many things as possible to speed things up, and only do the calculations that he needs to do. So yeah, force CII use BUND. For every other situation, I just use NPM. I agree with you. I think doesn't make sense to me to use a different package manager. What about you, Peter? What do you think about this? Oh? Sorry, Chris? Yeah, I just wanted to quickly no, because I haven't
used BUND. But even on their website they list like against NPM and YARN and pn PNPM, Yarn is the slowest. So I don't know what happened, but yeah, and I just quickly wanted to mention maybe before we move on, I know that Yarn was maybe good in the sense because NPM saw what they did and they were like, oh man, we need to kind of like get our act together. And I think ever since like two or three years ago, they really focused on those install times and everything. But
now I guess they they're back to having YOUNG and beat. So so, Peter, what do you think about this? Okay, Well, my project, I kind of alternate between PMPM and YOUNG. Yeah. I use PMP and Young alternity because first of all, for Young, the idea of kind of packaging or the package like compiling and all the packages at first before installing them was kind of okay. Yeah, especially at the point where I had
like bad reception. Usually we're using MPM but just installed everything beats by bait and then we're having like maybe issues with network or something white kind of breaks and then you have, yeah, get some kind of errors, could cob some stuff. So yeah, I had to use them because of that first step, right, and not really because of his fast off, but just
the installation was kind of much packaged and better. The PMPN was kind of yes, the feature of kind of sharing, it doesn't like it's not modus, so it doesn't really like replicate dependencies. Like maybe you are installing dependencies and you have like two similar types, it's going to kind of put it under one bell and then use that that kind of stuff. So yeah, I think that was also what I did for the package management the side.
But then as alongside outside that I've just born for kind of personal projects. I've written a lot about it as well. For the Proact application I worked on, it was kind of okay, but like when I did that then I think that was like on the point versions all point something, right, so it doesn't it goes up to version one, so I really yeah, I wouldn't. I've not really used it as one at the moment though,
to see maybe if it's there's a lot of improvements. But I used I kind of visit officially for just projects, but you don't not like you see young GMP. So yeah, so that's interesting because we were just talking about how we are in favor of NPM, and then Peter starts with I either use yarn or p n PM, like he never uses NPM. So it's nice nice, I like this. I like this. Yeah, yeah, yeah, the diversity. That's a good point, I think, I because
maybe I mean, I yeah, good diversity. And I have no experience with the other two with the Yarner or Bond or pn PM, but I yeah, that's if yarn. So yarn does cash like previous downloads, that could be I mean, that could be nice because if you have like I know, like when I'm on the train or whatever, like if I had to install like I'm I'm toasted. So that's maybe a feature. No MPM. I don't know. I just I don't know enough experience with all these
all these tools. Yeah, I think there was also a time where Yarn had workspaces and NPM didn't right, So a lot of people started using yarn because of that feature, the idea of having your repository b conglomerate of packages that import each other. So yeah, nowadays, I believe NPM already has workspaces. I gotta be honest, I haven't used it for real, because every time I wanted to have mono repo, I just went straight to NX that it gives me a lot more power than just NPM workspaces. So never
really used NPM workspaces in a production application. But yeah, I think that there was this this point, Tore, I like to go back in one other thing that you said, Gritz, and then we got to go into what Peter uses because now I'm curious, like maybe he uses things that are
super different from the ones that we are using. But I want to go back to testing again and talk about Cypress and Playwright because I've been really interested in Playwright lately, because don't get me wrong, I've always had great experiences with Cypress, except with their asyncowight madness, because they did that thing where they make a synchronous code look like it is synchronous so that it would be
easier for people to get started. But and yeah, this is cool at first, but as soon as you actually want to include other utaies in your
back files that are indeed asynchronous, everything goes to help. And I have spent so much time trying to get an API client to work within Cyprus, and it just it's impossible, Like you have to use the Cypress APIs to make attP requests because otherwise then everything goes out of order and by the time it runs your code, it hasn't really waited for that promise to return, and it's just really a nightmare. So I'm really happy that Playwright doesn't have
that, and you just have regular asyncle weight. So I've been interested in learning more about it, honestly, though, I don't know of many other features, of many other differences between Playwright and so vipress. Besides that, I suppose that it would also be more cost effective for companies because Cyprus is a company. Right at the end of the day, they have to pay their bills and the only way that they have to do it is by monetizing
Cyprus itself. The tool, but Playwright is was created by Microsoft, and I don't think Microsoft gives it, you know, I don't think they care at all about making money with that. It's like if they were to make money with that, it would be so ridiculously small compared to their other income
sources that I think they just don't care. And that to me is appealing because I believe that we would be able to have a complete experience of the tool without needing to pay what would only pay to have Cyprus parallelization and video recordings and and things like that. So yeah, I'm still going through their dogs to to see more, to understand more about their differences, but it's definitely something that I've been interested. So I wonder if you guys have studied
a bit about playwright. Yeah, so I, for one, not religious to play right kind of. I think I'm moved like a said plus guide so religious for it through I think the one I kind of hope. I don't even know about coopetia, so also I know that, but I think I've just dot I won't well, I think cyplus is too in my opinion, but a bit, although I can't really see because I won't used to
play right. So maybe any average choice of a change of mind and I kind of exploit Yeah, I think I'm in the same position as as both you guys. I mean, I know sich I. The only reason I know of play right actually is I'm working on a Blazer app for work, and so I was naturally kind of led in the Microsoft path and oh they
have this end to end tool as well. But I would guess, I mean as like as my experience with software goes like it's slightly newer than sorry Cypress, so my guess is, and it looks I think, like you said, Lucas, it looks like Cypress, it looks like I'm reading Cypress code. So I would guess like if they've kind of fixed any of the weird quirks with Cypress but have almost the same feature set, h you know, it would definitely definitely for something for me to look into further. Yeah,
Peter also mentioned I forgot Puppeteer as well. That's a great tool and I even use that not just for testing, but you can do you know, other stuff, any any sort of automation or in screenshots and stuff too, So I guess I guess it. And so Puppeteers sometimes feels like super like lightweight, like in two or three lines you can do stuff, whereas yeah, with Cyprus, of course you're probably doing actual testing or something of that nature. So interesting stuff. Yeah, nice, nice note. So
Peter, now it's the time. Yeah, Now this is a time where you say, yeah, guys, I don't use any of the things that you mentioned. I use those other hipster technologies. So yeah, tell us what is it that you use in your React projects? Okay, yeah, from my React But just first of all, I justly doing Yeah, so I'm dealing with guys. So yeah, I was before like from yeah, just cast me, I'm took me away. So yeah, so yeah,
first of all you went my design system. Then yeah, if I want to probably kind of vieild a design system like within that will probably pick something like maybe anti design or materia u y maybe for more functionality. Right, then if I de said okay, I just want to build everything babboom from Scratcher, probably just you still with them, go with THESSL. Right. So then for state management, I kind of work with a lot kind of
I use different types personalities. First of all, for service states, I use the Artquay, right, So if I want to hunt to serve states, I used the arth Carey. Most of the time. I probably use the Artquay for most of my proof like you don't matter like my state management, because for most of my projects, I will need maybe close to an endpoint to an API that's server state and from the Earthquay kind of those those
great and handling server states. Right then, But then if I just want a layer of client state management, I go to either redogs those stands. I use those stand as well to stay from all those stands well, and then there's still Jota. Juta is I'm not going to actually use. I love Juta. It's so simplistic, but does gives the feeling of you're using a very powerful state management to board. Then it's loos like you state, like just like your regular yard states, like I'm at like, just so
simplistic. So that's why I love Judai. Like using Juta, I probably would recommend using Jutah for maybe if you have something like a microphontain system maybe where you kind of share states between different applications, you're just using Juda is kind of very efficient because it's easy to It's just like I just like the
boiler play the hook codes. It's just like you state. It's so simple right, you don't need much boiler plate stuff to set up not that right, So I use that for like small projects like projects I know that you
are. We just work with that. Then stand as well too. I think I kind of still use those stands for like React native stuff, so I work on and then sometimes when React applications, then readults is kind of like you go to if I see this app is gonna get very very big, and yeah, I'm based on Also like I have this kind of partiality to redults. It was like my first dis management stuff, so kind of
have like this partial love for redocts. Right. So yeah, so from that I see the other packages as well, like maybe things like defereness for this time, I was using moments before, but the moment got deprecated, so I deed oh no, no, no, I can't use that,
so the data ferdness yeah for this. There are still also maybe things like load dash once like if I'm even going to use load dash kind of partially, but most of the time I depend on maybe I think some utilities myself kind of, but sometimes I could use loadash for maybe if I if I see look at this group of the project, it kind of requires a lot of manipulations from kind of high competitions that will come me to manupulate always do certain things, and I need to do them in quick time, right,
so probably use loadash this then. Yeah, I think that's just basically the found this let just the fundamental part. Any other package I probably based on the need, and maybe like charts. If I'm working to analytics, I probably use like charts or shout out with apex chats. Yeah, so I use a pegs chat as well, and then after that, Yeah, I think that's just technically do for me. So what do you think, like, do I is it weird? Do is it's kind of strange? I
think you're definitely the hipster among us. There were some live is that you mentioned that I don't even know how to write them, so definitely you win, you win the game. Wow. Yeah, So I think that's technically well, well, there's for testing obviously, there's digest, right, and
there's the sideways. Yeah. Apart from that fundamentally, then probably if I if I want to go step further, I could maybe use like if I'm just being lazy, things like maybe some infinite school packages or I could just like to look for that then I think there was a day I became so lazy that I kind of installed the packages for like this, you know, events for publication when you click outside of a menu and then you want that pass the close like the men you open a menu. Ya. So yeah,
I just became lazy. You want there, I just study package for that. So usually a hook would do that, though I just decided to do that. So sometimes I just be very lyad and I just said to those picks some packages. But on the Norther movie, I will just probably write them myself. Well tho just copy them from Like could I have like a catalog of cood I use kind of so just take it from there, we use it. Yeah, yeah, like that, there's that React hook
site. I also I also like I'm weird. I know I can just install the library, but I don't want the whole thing, so I just copy like the few hooks that I want, but I would be I just added a bunch of stars to my GitHub. So thanks for all those. But I'd love to hear more about this. The React query So is that for like, does it like help you simplify API calls or or like what
what is it? Well? React qual It's kind of really nice in the sense that for savistys, right, you know, most of the time you have we kind of work with API calls, right, so you see that the aspect of Sevasti stoying the data for Sevasti and then cashing it, prefetching it when you need it, and so on and so forth, like that
does evolving end points APIs and so on. Yeah, so the art Corey kind of works with that or and like you technically if if more for it kind of very API heavy app you may actually just multiple use a client states manager like a widows or Juti or those stump if you actually do it very
work kind of we just use the art qualer just fetching. Probably for example an e commerce up, you just use your creed to kind of cash the products the wi fish and a PI and then with the identifier you could get the that same data cast like you could do a lot with the art query. So it's actually like for I use it for sever states, like that's why I probably serve states. Anything depends on maybe getting from an endpoint. I just use that for it and then go my own blewey. Then probably
there are certain things I need to store on the client. Maybe I have like a very big dies on list of something that I don't want to keep on fetching or the like, I don't want to keep on calling the end points as like constantly. I've probably used a videos like the client states for that on those stories, then persistic to local storage so that I could justice sleep with fetch it when I needed to. But yeah, I think we ask probably is kind of quite cool that I feel something. A lot of
people will check it out. It's kind of going to minimize a lot of client states managements you're going to work with. Yeah, yeah, I feel like I've probably been writing a lot of code like that. I could have been using this library the whole time. Okay, yeah, so yeah,
yeah most of the time. Like I said, you probably don't need the like depending on how you write work with the creat you probably won't need like you because for like you will be like a client state because you're working most times, like if you're working on an application that requires a lot of course, like you, you're dependent on data, you know, maybe you're not dependent on setting like details from a main point or so it's save us states,
right, you could just walk with your career and work with that, and I think something that kind of looks similarly to how it works. I don't know, if you work with all cash, Yeah, it gives that kind of yea yea yeah, so it kind of works similarly to graph your clients with, but I think it's kind more fight with much better kind of does it better and does it for like excally to use its multiple pose kind of? Yeah, So that's why it is. Generally it's kind of cool.
I think it's something a lot of people should check out and check it out and just start using. Yeah, I think it's something that you can't I think I've worked with a lot of company or on large cold business with that, and it's kind of easy to navigate because then you could always see your you casually know when okay, oh this is save us state, this is the identified just get your out with art that don't don't need to worry about so much. Yeah. Cool, Yeah, lots of lots of interesting
stuff. So I'm not sure if mine are going to be as interesting, but I think some of the utility libraries that I use could be really interesting. So let me start with with that. So one thing that I use, and it's definitely not common for people. Is a lot of functional programming, right, I use a lot of functional programming. So, for example, there's a library called FPTS, which stands for Functional Programming Typescript, so
it's FPTS and it is huge. It exposes a lot of functional programming data structures and they are all really well typed and none of them are class So it's kind of like the movement that our actually has had a while ago, where you have to pipe and then you have a lot of functions that a lot of pure functions that you use to pipe your observables. So the same way, this library gives you a lot of isolated pure functions that you can
use to modify what's coming through. So you have for example, either, which is a type safe structure for you to deal with success and failure scenarios, so you don't need to throw errors anymore. You can simply use an either and that forces you to handle the error cases. There's no way for you to forget to handle errors because it's just not going to compile if you
don't. Then you have task either, which is also used a lot, which is the asynchronous version of either, so it's basically either with promises and it's it's lazy, so the promise is not executed eagerly. It's only executed once you call it app like you pipe it through all the modifications that you wanted, and afterwards when you call it, that's when it actually triggers the request. So I really like this lazy aspect, this lazy execution aspect.
There's a lot of interesting things. If you go down that palf of learning FPTS, then there's another library which goes along with FPTS, which is IoTs, and that is basically the coders, so it allows you to do data validation. People generally use joy or things like that. I much prefer IoTs because I think it's much easier to compose, to create your your the coders,
and also to make it extremely strict and extremely type safe. It also integrates directly with FPTS because they were created by the same person, so you're kind of like in the same universe. Then I also use low dash a lot, specifically low dash FP, which is the functional programming version of the low dash utilities. The main difference is not like there are different functions for low deash FP. It's still the same utilities that you have for ladash,
but you have some differences in how you write them. For example, they are all curried by default. And for those of you that may not know what currying is, is you for example, if you have a function that takes two parameters, currying that function means transforming that into a function that takes one parameter and returns a function that takes another premer and then returns the result. So the go here is to have functions there are unit which means that
functions that only have one input parameter. And why is that important? Because that way you can write point free programming, which is basically, let's say that you're doing an array dot map. If your function just takes one input, then you don't need to call your function inside the map. You just pass the function. So let's say that you have, for example, you have an array of strengths and you want to map that into an array of
numbers, and then you have a function that is like two number. You know, so if this function takes only one argument, then you can just do array dot map and within the parentheses you write two number. You don't need to write an arrow function that takes the value and then passes it to
the function. And it's really important that we use unary functions for that context, because if your function takes more than one argument, then you can find yourself in situations where you weren't expecting people to put it into an array dot map, for example, and then you're getting the index of the array as the second argument, and there certainly things are not beating the way that you
expect. So there's that. And also when you're carrying your functions, you make sure that the arguments that are going to change the least are always the first ones to be passed. So let's say that you want to sort something, so you have a function like sort by. The most common approach to write a sort by function is to write it in a way that the first parameter is the collection of things that you're going to sort, and the second
parameter is the function that you call to compare the values. If you're using functional programming, you would do the opposite, So the first thing that you would pass would be the function that compares, and the second thing would be the collection that will be sorted. And the reason for that is because most generally the collection that would be sorted is going to change way more often than
the function that sorts the collection. So by having the function that starts the collection first, you can create a function that is like start by name is equal to start by and then you give it the compare function, and this is going to give you back a function that takes a collection returns it sorted by name. So yeah, there's a lot of functional programming madness that I'm really into. Peter mentioned date date functions data Offense. I also use that.
I prefer it as opposed to moment because yeah, especially because it uses functional programming. There's also a time zone extension for date funds, which is date Funds TZ, which exposes utilities to deal with time zone conversions. It's also very useful. I also use the library that I created. It's at Lucas Paganini ts and a while ago, like I think it's two years by now. I created an entire course for free on YouTube, so if anyone
wants to watch, you free about typescript narrowing. So basically it's a course about how to tell typescript which types you're dealing with. So all of us have had a situation where you you had like a number or strength, and you already did the necessary checks to make sure that that thing is a strength. The typescript still thinks that it's a number, so this would be narrowing.
And I did like eight videos on that, and by the end the last video, I built a library with all the utilities that I referenced throughout the previous videos, and this library is published on NPM under at nucas Paganini ts So I'm sending this in the comments section. It is not maintained, but it is stable. Like everything that I have here are just types, so there's nothing that's going to go into your actual runtime implementation. It's literally
just types. So I don't think anyone should feel at risk of using it. But honestly, it's just myself using it. I don't even like release. I haven't released new versions in a while, but it exposes a lot of interesting utilities for me. So, for example, I have a utility that extracts all the values from an object. I mean the types. For example, Let's say that you have an object which is a user, and this user has a name which is a string, and an age which is
a number. So if you call object values, then it's going to give you string or number. So these are the types of the potential properties of this of this object. And there are a lot of really really weird stuff, like I created an asynchronous type guard, so we have like type predicates.
When you have a function that returns a bullion and tells typescript if that that value is of that type, so I created a synchronous version of that, so you can return a promise of a bullion and that will tell typescript the correct type of this of that thing. So there are a lot of weird stuff in that library, so I use it a lot. I also use a library called expect type and this is going to be really interesting to
a lot of folks. So basically, there are a lot of libraries to do testing, but I always felt that I needed something to test my type definitions. So for example, let's say that I have a function that if I give a particular input, I expected to return something off a particular type. So if you give it a string, you should return on an array of strengths, but if you give it a number, you should return noul or I don't know, something weird like that. So this library allows you
to test the types of your code. It's really interesting and the idea is just genius. It's basically, if your code is returning the wrong types, then the library is it's not going to compile because Typescript will try to parse your BAC files and the types are not going to match with what this library is expecting, and then the types just fail. So it's genius the way that they that they did this, and I think it's a really, really,
really good library. I use it extensively because I do a lot of Typescript madness, so this is the only thing that allows me to guarantee that the types of when I'm returning are still what I expected. Other than that, I also use just in Cyprus. As I was just mentioning I might migrate to Playwright. I'm studying it. I use our EXGS a lot, not that much in React because within the React universe, our XGS is just not very necessary. There are other libraries that do what our xs does.
But I do a lot of Angular code and also just no JS things like that, and in those scenarios I use our actually as to have reactivity, And yeah, I think these are the most interesting things I could, like go on for three hours talking about the technologies that I generally use, but
I think those are the most generally useful for other folks. Yeah, I think we'll have to We'll have to say for another episode just the like front end, because I have a few UI libraries I like, But we can we can do that in some other because we could probably go another hour. Yeah, so most packages, and especially you're looking at JavaScript, right, So many packages, so many Yeah, definitely, So we're probably I do a round two maybe a few weeks or or months from now, to keep
you guys updated. But in the meantime, I think this is enough for all of you to study for three months. There's a lot of a lot of stuff. So yeah, let's let's start wrapping things up. Let's just do some quick updates on things that we're working on. And yeah, so on my end, I'm just gonna promote Onvoid. So basically, Unvoid is
the most risk free way of extending your software and design teams. And the way it works is that their entire business model was created so that it would address the main pain points that companies have when they are outsourcing designer software development services. So time zoning, compatibilities, for example, this is dealt with so Onvoid is near shore and it has big overlap with the United States and
even the coast of Europe also contracts. For example, all the contracts on Onvoid are based on the state in which the companies head border, and so you are in Tennessee, the contract is going to be governed by the laws of Tennessee, or in California, it is governed by the laws of California. So it gives you a lot of safety in that sense. You feel very secure. And there's also a two week money back guarantee for any reason.
So if you hire Onvoid and you're not satisfied with the quality of what their professionals delivered, you can just cancel the contract within two weeks and you're not going to pay literally anything, and you can even keep the work that was delivery that was delivered to you during that period. So really anything that you have in your mind of possible objection, like I don't know if this is gonna work, because X, Y and z uh they probably have you
covered. So if you're interested in that, check out avoid dot com is you and v O I D dot com And yeah, so what about you? Peter there are also on my end mostly more do or do. I really just appreciate the link to like some packages I talked about, like the State Management Jutai I kind of talked about really cool. I really I said it on't be shot, so I really really something A lot of people come and work with. Yeah, and then also yeah, I also rightful refined.
So maybe I's some somebody that looks like some articles for it the fine book. I only many know about to find it more like react right so that they try to automate some kind of we do the house shot. It'll sitting up on coutin React applications. I will show my auto profile on the chats on probably something you can't look out check out. Yeah, so I think that's just for me. Cool Yeah about you Chris. Yeah, Also not much new, uh, I'll post as an alternative to my blog in
case you don't like dark mode. I have medium. I still don't have a dark mode on my blog, but I have like basically a clone of everything. And again that's just the articles. Typically they're driven by me encountering some problem and not being able to find the solution, and then I just convert whatever I whatever the solution I find is I convert that to a blog post. So I've got all sorts of stuff, not just React but but everything from Go and even now I'm doing more Windows stuff, so cool.
All right. Yeah, so I'm gonna send you guys' links on the comment section, so anyone that is interested in checking those libraries and also your content will be able to see it. So, yeah, if you're listening to this and you're wondering, what was the thing that Peter said, uh, yeah, it's probably in the comment section, and you're like, oh, I'd like to read more about what Chris is talking about, then yep,
it's also going to be in the comment section. Yeah, guys, thank you so much, audience, Thank you so much for sticking with us. I know that sometimes we we end up getting really extended into our conversation, but it's because we really have a lot of things to share with you guys. But yeah, hopefully this was valuable to you. Have an awesome week and I'll see you in the next one.