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.