January 8, 2025 • 39 mins
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.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/react-round-up--6102072/support.
Links
- webup.org/blog | Miroslav Nikolov
- UnexpectedJS
- React Component Tests for Humans | CSS-Tricks
- mailchimp
- Substack
Picks
- Miroslav- erikras.com
- Miroslav- Application State Management with React
- Paige- Tom Clancy's | Jack Ryan
- TJ- DREAM SPORT Bike Computer Bicycle Speedometer and Odometer 16-Function Wired Bike Computer Waterproof
Become a supporter of this podcast: https://www.spreaker.com/podcast/react-round-up--6102072/support.
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome to React Roundup, the podcast where we keep you
updated on all things React related. This show is brought
to you by Void and top End Devs. Unvoid provides
high quality design and software development services on a client
friendly business model. Unlike all other software agencies, Unvoid allows
(00:20):
clients to only pay after the work is delivered and approved.
Visit unvoid dot 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 u n void
dot com and top end Davs helps you stay up
to date with cutting edge technologies like JavaScript, Ruby, Elixir,
(00:44):
and AI. Visit topandevs dot com to join their AIDV
boot camp, weekly community meetups and access expert tutorials. I'm
Lucas Paganini, founder of Onvoid and host of this podcast.
Thank you for tuning in. Let's jump into the episode.
Speaker 2 (01:07):
Hello everybody, and welcome to another episode of React Round That.
My name is TJ Van Tol and with me on
a panel today is Paige.
Speaker 3 (01:14):
Meeting guts Hey everyone, and our.
Speaker 2 (01:17):
Special guest today is mirslav nick Love which hopefully I
pronounced that correctly, but mirsta. Welcome to React round that.
Why don't you tell everybody who you are, what you do,
why you're famous, that sort of stuff.
Speaker 4 (01:28):
Thank you, hi, everybody. I don't think i'm famous, to
be honest, I work as a UI developer mostly front
ends so one dot com it's Danish company that is
currently expelling, and what I do is basically react and
in my free time, I try to maintain my block
(01:49):
so turning my experience in some useful articles. That's like
something like a hobby. And yeah, I'm a family guy.
My wife, Panta, kids a boy, so that basically takes
a hour all my free time, so I don't really
have much time to spend on side activities.
Speaker 2 (02:12):
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 drop it in 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 REAC
(02:34):
component tests. Do you want to outline sort of that
whole concept and what you mean by that to sort
of kick us off here?
Speaker 4 (02:41):
It's it's basically it's all about library called Unexpected Jays
and it's I know it's not very popular, but what
it does on what it adds on top of everything
else we have seen is actually out of playing English
when you when you write your tests. And I'm using
(03:01):
that library basically for the past five years, and I
just decided to write an article which is just a
short introduction to what is possible with the library. And
so I decided to write the article for cisys Tricks
so that it's basically rich a little bit wider audience.
(03:22):
And it was very surprising that I think right now,
if you write React component tests or just React tests testing,
that appears on the first page. But I believe this
is because of the strong domain of cesys Tricks. So yeah,
it's also brought some discussion because it seems like people
(03:45):
prefer different style of testing and it's a little bit opinionated,
but yeah, there are some there is some positive feedback
as well.
Speaker 3 (03:54):
So can you expand a little bit about about what
unexpected jas is because that's actually a framework that I've
never heard of before. I'm interested does it work like
with React testing library or is it Cyprus or is
it both unit and and can you tell us a
little bit more about it?
Speaker 4 (04:13):
Yeah, first just to say that I'm not a maintainer
of the library. 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 reg Testing library, so you can
use REAP testing library and some assertions custom assertions on
top so you can write your plain English tests and
(04:38):
behind that it's React Testing library, so it should be possible,
though I haven't tried. Yeah, and I also kept for
a light version of the article on my block, just
it's a little bit lighter without the introduction because currently
it's a little bit controversial on how we tests, and
I know the community is going strongly after reacticting library.
(05:02):
So people are sometimes speaky when you present something unusual
for you.
Speaker 3 (05:09):
Absolutely new things are not to be trusted.
Speaker 2 (05:12):
Developments don't have opinions and what you're talking about.
Speaker 3 (05:18):
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 how it operated. Uh.
Speaker 4 (05:31):
To be honest, I didn't have choice because when I
joined one dot com, they have already they already used
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're still using it internally.
Speaker 3 (05:53):
So that's a good reason.
Speaker 2 (05:55):
Is any did you get a little bit into I know,
one thing you cover in your article is trying the
right tests that are sort of a least 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 an audio podcast, but
(06:16):
just like high level like how you approach structuring tests
in a human friendlier, in a more readable way.
Speaker 4 (06:24):
So basically what we use is the usual arrange acts
assert kind of thing, which is I mean you first
arrange or 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
(06:45):
little bit different is the expect. Assertion is just a
function expect and inside you pass as many arguments as
you want, and these arguments are just plain strings, so
you don't really have a JP relax syntax like dot
(07:05):
dot equals or dot to be executed. You just play
in English and usually the editor is colors that 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 auto complete
different function goals, but it's it's it's really it's really
(07:29):
easy for the eye. 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 there.
Speaker 3 (07:42):
That's very cool. 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 just may be familiar with Enzyme,
(08:04):
maybe familiar with React testing library. But how easy or
difficult do you think it is to get up to
speed with unexpected and then start to potentially integrate it
into any existing testing frameworks that you might have.
Speaker 4 (08:18):
I think 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 really easy. And usually you
have just you have several common assertions that you would
like to use, and you don't really use so many
(08:41):
different features, at least for the React components. You want
to test if something has rendered, so usually you test
you equate for an element and you test for its
string that it contains. And also the other thing is
testing function that is also straightforward. So apart from these
(09:04):
two things presence of certain elements and executing functions, you're
most likely rarely going to use other other like assercial
So I would say, but it's it's very straightforward, at
least for at least for me.
Speaker 3 (09:20):
It us 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
(09:41):
interacting with that at a unit test level. So anything
that is easier to get up and started with is
definitely always good.
Speaker 2 (09:52):
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 both of you, is where is the
React world at right now for in terms of like
(10:13):
testing markup structure in your like individual unit tests, Because
I know Miroslov in some of your articles you went
in and you are like basically asserting against the exact
dom structure. Is there some advantages of that or like
versus like I'm if I want to test my component
render something specifically, like how specific should your as search
(10:37):
and 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 kind of curious where the React
world is at with that sort of setup right now.
Speaker 3 (10:50):
So for my understanding and what my team is doing
today is that we're a lot more focused on this
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 REDUCS dispatch
happen or did this particular function mock get called? And
(11:15):
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 like it a lot more because it seems to
(11:36):
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 REDUCS dispatch fired or not.
They just care that their 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
(11:56):
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 component. 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.
Speaker 4 (12:17):
I would say that we're using the same approach at least.
Comparing the dom structure is something that we use really,
and I know that the communities pretty much with React
Testing Library going away from that kind of assertions, So
we use it really and we mostly unit tests and
we have strong QATEAM, so the visual part is really
(12:39):
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's ourly.
Speaker 2 (12:52):
That makes a lot of sense. And because I remember,
like you said, Page, the way it used to be
is you would you would do things like ensure your
marks we're here, or that 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, I don't know, the test just
(13:14):
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
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 in your
buttons suddenly doesn't look like a button anymore. That there's
(13:36):
some other test is going to catch that, so you
don't need to like test your HTML parsing.
Speaker 3 (13:42):
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 awarever they using any particular
tools because visual regression testing is something that my team
has struggled with in the as, but we haven't really
found a great tool that helps keep that up to date.
Speaker 4 (14:06):
Yeah, they have their own tools, but a lot of
the testing is I think kind of ends 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. I know some people
suggest to write user stories as the part of the storybook,
(14:29):
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 is 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 box and we
(14:52):
are not really trying to have a full test coverage,
just trying to test the fragile paths 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 and back for that
(15:14):
product up until this moment. It was I think the
team did a good job of testing and iterations. So
it's I know, it's rare, something that's remarkable from time
to time.
Speaker 2 (15:28):
Did you get an award?
Speaker 4 (15:29):
Like, Oh, I'm not sure if people notice that achievements.
Speaker 3 (15:37):
I don't notice until it stops working.
Speaker 4 (15:39):
That's the problem.
Speaker 2 (15:40):
Yeah, that's the thing about testing is like there's you
don't get a 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 your stuff. What what made
you want to write about this and start a blog
and share some of this stuff.
Speaker 4 (15:59):
Yeah, I didn't do it before because I suppose that
our time is such a resource that we basically it's
not we cannot regain it, it's lost basically, so writing
an article, I mean, junior developers, writing an articles is
something that's at least I try to avoid because I
(16:21):
don't think I had something to tell, something variable to
take tell people, and reading my ten minutes article will
be a loss of time. So I decided to start
writing maybe after thirteen years of working with work applications,
just because I feel a little bit more comfortable and
(16:42):
maybe I have something important to say and people want
to just spend there ten minutes and forget after that.
It's a tricky area at least I feel uncomfortable. So yeah,
that's the main reason I suppose. And I have a
lot of ideas material during these years, so there's plenty
(17:04):
of topics.
Speaker 3 (17:05):
I think after thirteen 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.
Speaker 4 (17:16):
Yeah, yeah, explor six this was there back back then,
I remember.
Speaker 2 (17:22):
But yeah, thirteen years is about where I'm at as well.
I started. My first apps were i E six only
corporate apps, so this is these are fun times.
Speaker 3 (17:35):
Yeah, oh I see here, Oh go ahead, please go ahead.
Speaker 4 (17:39):
I just wanted to say that writing an auto about
to explore six is probably I don't know, what's not
going to be very famous.
Speaker 2 (17:47):
I don't know. It's about time for like the nostalgia
of that to kick in, because now now you can
tell them it's like war stories right like back in
the day.
Speaker 4 (17:57):
Yes, it's true. I mean today people are starting to
react directly. I mean they don't even learn JavaScript. For them,
JavaScript is now it's something like react and five six
years ago, which was maybe je.
Speaker 2 (18:12):
Query so query Angular I think like and we're talking
about testing too. 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 and other browsers, which like sometimes
sometimes you do catch little things like it's it's the
(18:35):
sort of thing where you still do kind of need
to test your code and other browsers, but for the
most part you kind of don't anymore, Like especially on
desktop browsers, Like chances are the code you write is
going to work. And that's still like quite the mind
shift from how it used to be. Where it used
to be you wrote your code and like you opened
your you just prayed before you opened all the other
(18:57):
five or six browsers you needed things to work in.
Speaker 4 (19:00):
True, I to be honest, I don't think I go
out of Chrome and I don't really test on other browsers. Yeah,
and you're right because even qare they don't they don't
find they don't find spucks often another browsers, So it's
things things are working.
Speaker 3 (19:18):
So one question that I had is when I visit
your website, 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,
(19:41):
like an individual contributor or how did how did that happen?
Speaker 4 (19:45):
Yeah, it's uh, I think it happened naturally. Again, it's
it's a small company where I was basically maybe I
was a CEO. Actually I was doing everything because the
owner were in a basic in Sweden and I was
back in Bulgaria at that time, so I was managing
(20:05):
the whole business plus 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
was freelancing a little bit, then moved away from that company,
(20:26):
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. Wow.
Speaker 3 (20:49):
So basically running a company wasn't enough for he had
a dove freelance work on the side too. That's dedication.
Speaker 4 (20:57):
Yes, at some point it became too much, but yeah,
you can do it for some time before you burn out.
Speaker 3 (21:05):
Yeah.
Speaker 2 (21:06):
So looking at the blog, is your blog built with Gatsby?
What what did you use to create this?
Speaker 4 (21:13):
Yeah, it's exactly gets and I was I was inspired
by Don abramovs bloke. It uses the starter team, so
it's really just the start theme Starter team with some
some tweaks. So I just wanted something simple up and
running fast, and after that maybe I will figure out
(21:36):
a better designed for it, but for now it's just
it just works good.
Speaker 2 (21:42):
Yeah.
Speaker 3 (21:42):
I like the just the clean look of it and
the fact that you have dark mode.
Speaker 4 (21:49):
Yeah, it's it's a default thing now, right everybody.
Speaker 2 (21:54):
And I also see you have a newsletter as well.
Speaker 4 (21:57):
Yeah, it's I'm trying to keep with. It's once a
month and I'm trying to send I'm usually sending my
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
(22:18):
interesting thoughts and links maybe I have found, but at
least I'm trying to write about the topics that you
It was difficult to find a quick solution by just googling,
So if I can't really find a solution, I would
write about it. And I remember it was an article
(22:39):
about something like a editorial on how to create a
sticky table header but would react but by using just
a normal table, not a deep based fleck or flax
books based layouts. And it was surprising to me that
actually there are not so many examples that you can find,
(23:01):
and this article is without any is you always now,
it's it's pretty high when you try to look for
something like that. Who will.
Speaker 3 (23:13):
Oh, 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.
Speaker 2 (23:26):
Well, I don't think I know what unique reads are.
Speaker 4 (23:29):
Yeah, it's it's not Google Analytics, because it's so not
straightforward to implement that thing in your blog.
Speaker 2 (23:38):
And I just I just saw it. Okay, you mean
like 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
(24:00):
don't think I've ever seen anybody list unique readers.
Speaker 4 (24:03):
Yeah, it was read, but then I found many blocks
which are just counting the visitors, so they have, for example,
they display sixty thousand views. But that doesn't really make
sense because I can reload my brother two hundred times
and then it's not really useful. And I'm using a
third party service that is just a counter, and whenever
(24:26):
your component renders, I just put in use effect a
call to this service, so it will count, but in
the same time return back the number of unique roods.
So this is the way how it's done.
Speaker 2 (24:40):
It's very simples, like.
Speaker 3 (24:42):
It might be worth a blog post.
Speaker 4 (24:46):
Yeah, it's one of these topics that are not very
well covered. If you try to search how to add
a counter and gets the block. It's all about Google analytics,
and it's so difficult.
Speaker 2 (25:01):
It's funny though, how little things like that people can
find useful. One of the most popular things I've ever
written is I wrote like my blog is a little
bit older, so it's written with Jekyl, and I came
up with some way like it's like a one liner
piece of code to have a jeckal like point to
an external blog post. So if you wanted to list
(25:22):
blog posts but include things that you wrote on like
other places, and that thing gets like, I don't know what,
but it's like a two paragraph blog post and 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.
Speaker 4 (25:43):
Yeah, it's true. 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 do something
like Firebase and try to easily put together some third
(26:04):
party services and vola. It works, but it's it's not really,
I mean, so much effort for for such a simple job.
It's at least I try to think about the simplest
possible solution out there.
Speaker 2 (26:18):
I like it. I feel like that. It's funny because
personal blogs or the one place where over engineering something
is like not only okay, but sometimes almost encourage, right,
because it's like a place that you can experiment and
have some fun with.
Speaker 4 (26:31):
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 don't really have so many readers. It's
it's it's yeah, it's now it's the time to do
crazy things.
Speaker 2 (26:46):
When you get a lot of readers, then they came
for the crazy things, and then you get.
Speaker 4 (26:50):
To yeah they can even see a four or four yeah.
Speaker 2 (26:58):
The yeah, go ahead page, We keep doing this, please continue.
The other thing I'm wondering about, speaking of, like little
implementation details, what are you using to implement the newsletter
it's a.
Speaker 4 (27:11):
Mail Chimp for now. They I think they give one thousands,
I think subscribers for free. So it's yeah, it's pretty
say forward choice for me, but I may change it
in the future.
Speaker 2 (27:27):
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?
Speaker 4 (27:35):
Do you mean the pop up the little.
Speaker 2 (27:38):
Thing says join a foreign end newsletter like little thing
that entices people to subscribe to the newsletter.
Speaker 4 (27:45):
The form on the bottom, Yeah, the form on the
bottom is just the custom made it's not really mail Chimp.
I just post to their service, so it registered the
email address and then I just so just play a
conformed message. But it's not it's not Melchin.
Speaker 2 (28:05):
You've got a little bit of design talent, because that
thing looks really nice. It's very I know you said
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 jealous and I might steal this.
Speaker 4 (28:22):
Yeah, it's it's an evolution.
Speaker 3 (28:27):
Are you hosting a newsletter on your on your website?
Speaker 2 (28:30):
TJ No, No, newsletter, but we do stuff for like
kind to react and progress sometimes and definitely take some
inspiration from this.
Speaker 3 (28:42):
Yeah, I implemented one 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 mail Chimp and mail gun, and I'm yeah,
convert kit is a big one. I ended up going
(29:05):
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
(29:26):
post them, and if people want to 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 crossing
(29:46):
those subscriber thresholds and then having to pay thirty bucks
a month, fifty bucks 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
(30:06):
doesn't matter how big your subscriber base gets, they will
not charge you.
Speaker 4 (30:14):
So it's a little.
Speaker 3 (30:15):
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 I ever want to change it and start paying,
or if I decide that I will not get a
(30:37):
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.
Speaker 4 (30:48):
YEA also heard about substack. I actually have seen Kent
Beeck for example. He's using you as well, so and
he's someone that will I think be immunities around him.
So but he's posting in there. Oh well, that's.
Speaker 3 (31:05):
That's encouraging then to know that people who have big
followings are using it to their advantage too.
Speaker 4 (31:12):
Yeah.
Speaker 2 (31:12):
Yeah, and all the cool kids have newsletters. What am
I even doing with myself?
Speaker 3 (31:16):
It's apparently it's 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.
Speaker 4 (31:27):
Yeah, that's true.
Speaker 2 (31:29):
Is there things that we haven't covered, I know, anything
about testing components that we didn't get to or ask you.
Speaker 4 (31:37):
Oh, I think we touched the basics and if we
have to wrap up, it's just it's very controversial topic,
and I think some sometimes people are too dogmatic about
what we should use in terms of flabbraries. I think, Jane,
it's all about it's all about what you really can
(32:00):
do in your certain situation with your team, with your
organizational structure, because something may work but others won't work
in different organizations.
Speaker 2 (32:13):
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.
Speaker 3 (32:24):
Yeah.
Speaker 4 (32:24):
I mean, for example, if you do all of d
comparisons in your tests and you are publicly doing that
in a 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
(32:47):
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 these things, but it's really
what works for you in this particular situation, because sometimes
don't comparison maybe required, and sometimes you want to test
(33:13):
for a function call, especially if it's somewhere between conditional logic,
So you should really think about, yeah, what works for you.
Speaker 2 (33:25):
Yeah, I feel like that's that's good advice for I
mean React, testing for Reactor, 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
on Twitter for for things that they're doing that you
don't totally have the context for either.
Speaker 4 (33:48):
Yeah, that's why I don't have Twitter. Also, it takes
too much of my time and I don't really have
time to get into converse station since yeah, right and
tweet about relevant.
Speaker 2 (34:05):
Cool Paige, did you have anything else?
Speaker 3 (34:09):
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?
Speaker 4 (34:19):
If you just go to my blog, you will find
a few links probably the best ways. I just email
and I have also linked and GitHub, so this is
the way.
Speaker 2 (34:33):
Well cool, So why don't we move on to the picks? Then, Paige,
you want to kick us off?
Speaker 3 (34:38):
Sure? So my pick this week is going to 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
is the Jack Reacher series on Amazon Prime. And I
believe that it's Tom Clancy's Jack Reacher. It's based on
(34:59):
the book Looks and it is just rewatching it after
having seen it, you know, a year or two 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
(35:22):
binge as we slowly start to come out of the
COVID Hayes 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 into
(35:45):
the show notes about that that I got it wrong
the first time. But Jack Ryan is the series. There's
two seasons. It's a great watch. I would definitely encourage
it if you're, like, if you're into the spy, espionage,
THEIA type of shows.
Speaker 2 (36:03):
Okay, I definitely remember seeing the the ads for this now,
so I'll have to check it out.
Speaker 3 (36:08):
That's a good one. Cool.
Speaker 2 (36:10):
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 just a quick and easy speedometer for it, which
I kind of like. It's kind of fun to like
challenge yourself to see how fast you can go without
dying on Michigan roads. But it's a diet. A little
(36:32):
bit of research and found one I liked, 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 fun times, Mireslav, how about your picks?
Speaker 4 (36:42):
I think I have two. The one is I recently
found out that Eric Crossmans and the person behind the
Rep Final Rep Final Form, he also starts publishing his
blog posts, and so right now he has a bloke
and he's one of the people who I actually learned
(37:03):
a lot and I think 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 and React for quite some time, so
you can you can visit his block based link. And
(37:24):
then the other one is just an article I read
recently from kempt dot'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,
(37:44):
for your React applications, and that is also the case
with many of applicanials I have done. If you really
care for you think about if you can do it
just with React and maybe a little bit of context,
then yeah, we don't really need three ducks. But the
article could be controversial. I will just put that.
Speaker 3 (38:07):
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 REDUCS, which holds the global state versus context, which
(38:28):
just passes state around the application. 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 as
engineers have way over engineered a lot of applications to
use reducts when we probably didn't really need it in
the first place.
Speaker 4 (38:48):
Yeah, it's true. Sometimes we inherit habits from previous applications
and we tend to copy in to pace the same approach.
Speaker 2 (38:57):
Yeah well cool, Well, thanks Mary stuff for joining us.
This was a lot of fun chatting with you. Thank
you too, all right, Well, thanks everybody again and see
you next week. Yeah, see you next time.
Welcome to React Roundup, the podcast where we keep you
updated on all things React related. This show is brought
to you by Void and top End Devs. Unvoid provides
high quality design and software development services on a client
friendly business model. Unlike all other software agencies, Unvoid allows
(00:20):
clients to only pay after the work is delivered and approved.
Visit unvoid dot 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 u n void
dot com and top end Davs helps you stay up
to date with cutting edge technologies like JavaScript, Ruby, Elixir,
(00:44):
and AI. Visit topandevs dot com to join their AIDV
boot camp, weekly community meetups and access expert tutorials. I'm
Lucas Paganini, founder of Onvoid and host of this podcast.
Thank you for tuning in. Let's jump into the episode.
Speaker 2 (01:07):
Hello everybody, and welcome to another episode of React Round That.
My name is TJ Van Tol and with me on
a panel today is Paige.
Speaker 3 (01:14):
Meeting guts Hey everyone, and our.
Speaker 2 (01:17):
Special guest today is mirslav nick Love which hopefully I
pronounced that correctly, but mirsta. Welcome to React round that.
Why don't you tell everybody who you are, what you do,
why you're famous, that sort of stuff.
Speaker 4 (01:28):
Thank you, hi, everybody. I don't think i'm famous, to
be honest, I work as a UI developer mostly front
ends so one dot com it's Danish company that is
currently expelling, and what I do is basically react and
in my free time, I try to maintain my block
(01:49):
so turning my experience in some useful articles. That's like
something like a hobby. And yeah, I'm a family guy.
My wife, Panta, kids a boy, so that basically takes
a hour all my free time, so I don't really
have much time to spend on side activities.
Speaker 2 (02:12):
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 drop it in 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 REAC
(02:34):
component tests. Do you want to outline sort of that
whole concept and what you mean by that to sort
of kick us off here?
Speaker 4 (02:41):
It's it's basically it's all about library called Unexpected Jays
and it's I know it's not very popular, but what
it does on what it adds on top of everything
else we have seen is actually out of playing English
when you when you write your tests. And I'm using
(03:01):
that library basically for the past five years, and I
just decided to write an article which is just a
short introduction to what is possible with the library. And
so I decided to write the article for cisys Tricks
so that it's basically rich a little bit wider audience.
(03:22):
And it was very surprising that I think right now,
if you write React component tests or just React tests testing,
that appears on the first page. But I believe this
is because of the strong domain of cesys Tricks. So yeah,
it's also brought some discussion because it seems like people
(03:45):
prefer different style of testing and it's a little bit opinionated,
but yeah, there are some there is some positive feedback
as well.
Speaker 3 (03:54):
So can you expand a little bit about about what
unexpected jas is because that's actually a framework that I've
never heard of before. I'm interested does it work like
with React testing library or is it Cyprus or is
it both unit and and can you tell us a
little bit more about it?
Speaker 4 (04:13):
Yeah, first just to say that I'm not a maintainer
of the library. 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 reg Testing library, so you can
use REAP testing library and some assertions custom assertions on
top so you can write your plain English tests and
(04:38):
behind that it's React Testing library, so it should be possible,
though I haven't tried. Yeah, and I also kept for
a light version of the article on my block, just
it's a little bit lighter without the introduction because currently
it's a little bit controversial on how we tests, and
I know the community is going strongly after reacticting library.
(05:02):
So people are sometimes speaky when you present something unusual
for you.
Speaker 3 (05:09):
Absolutely new things are not to be trusted.
Speaker 2 (05:12):
Developments don't have opinions and what you're talking about.
Speaker 3 (05:18):
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 how it operated. Uh.
Speaker 4 (05:31):
To be honest, I didn't have choice because when I
joined one dot com, they have already they already used
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're still using it internally.
Speaker 3 (05:53):
So that's a good reason.
Speaker 2 (05:55):
Is any did you get a little bit into I know,
one thing you cover in your article is trying the
right tests that are sort of a least 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 an audio podcast, but
(06:16):
just like high level like how you approach structuring tests
in a human friendlier, in a more readable way.
Speaker 4 (06:24):
So basically what we use is the usual arrange acts
assert kind of thing, which is I mean you first
arrange or 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
(06:45):
little bit different is the expect. Assertion is just a
function expect and inside you pass as many arguments as
you want, and these arguments are just plain strings, so
you don't really have a JP relax syntax like dot
(07:05):
dot equals or dot to be executed. You just play
in English and usually the editor is colors that 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 auto complete
different function goals, but it's it's it's really it's really
(07:29):
easy for the eye. 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 there.
Speaker 3 (07:42):
That's very cool. 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 just may be familiar with Enzyme,
(08:04):
maybe familiar with React testing library. But how easy or
difficult do you think it is to get up to
speed with unexpected and then start to potentially integrate it
into any existing testing frameworks that you might have.
Speaker 4 (08:18):
I think 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 really easy. And usually you
have just you have several common assertions that you would
like to use, and you don't really use so many
(08:41):
different features, at least for the React components. You want
to test if something has rendered, so usually you test
you equate for an element and you test for its
string that it contains. And also the other thing is
testing function that is also straightforward. So apart from these
(09:04):
two things presence of certain elements and executing functions, you're
most likely rarely going to use other other like assercial
So I would say, but it's it's very straightforward, at
least for at least for me.
Speaker 3 (09:20):
It us 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
(09:41):
interacting with that at a unit test level. So anything
that is easier to get up and started with is
definitely always good.
Speaker 2 (09:52):
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 both of you, is where is the
React world at right now for in terms of like
(10:13):
testing markup structure in your like individual unit tests, Because
I know Miroslov in some of your articles you went
in and you are like basically asserting against the exact
dom structure. Is there some advantages of that or like
versus like I'm if I want to test my component
render something specifically, like how specific should your as search
(10:37):
and 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 kind of curious where the React
world is at with that sort of setup right now.
Speaker 3 (10:50):
So for my understanding and what my team is doing
today is that we're a lot more focused on this
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 REDUCS dispatch
happen or did this particular function mock get called? And
(11:15):
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 like it a lot more because it seems to
(11:36):
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 REDUCS dispatch fired or not.
They just care that their 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
(11:56):
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 component. 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.
Speaker 4 (12:17):
I would say that we're using the same approach at least.
Comparing the dom structure is something that we use really,
and I know that the communities pretty much with React
Testing Library going away from that kind of assertions, So
we use it really and we mostly unit tests and
we have strong QATEAM, so the visual part is really
(12:39):
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's ourly.
Speaker 2 (12:52):
That makes a lot of sense. And because I remember,
like you said, Page, the way it used to be
is you would you would do things like ensure your
marks we're here, or that 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, I don't know, the test just
(13:14):
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
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 in your
buttons suddenly doesn't look like a button anymore. That there's
(13:36):
some other test is going to catch that, so you
don't need to like test your HTML parsing.
Speaker 3 (13:42):
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 awarever they using any particular
tools because visual regression testing is something that my team
has struggled with in the as, but we haven't really
found a great tool that helps keep that up to date.
Speaker 4 (14:06):
Yeah, they have their own tools, but a lot of
the testing is I think kind of ends 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. I know some people
suggest to write user stories as the part of the storybook,
(14:29):
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 is 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 box and we
(14:52):
are not really trying to have a full test coverage,
just trying to test the fragile paths 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 and back for that
(15:14):
product up until this moment. It was I think the
team did a good job of testing and iterations. So
it's I know, it's rare, something that's remarkable from time
to time.
Speaker 2 (15:28):
Did you get an award?
Speaker 4 (15:29):
Like, Oh, I'm not sure if people notice that achievements.
Speaker 3 (15:37):
I don't notice until it stops working.
Speaker 4 (15:39):
That's the problem.
Speaker 2 (15:40):
Yeah, that's the thing about testing is like there's you
don't get a 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 your stuff. What what made
you want to write about this and start a blog
and share some of this stuff.
Speaker 4 (15:59):
Yeah, I didn't do it before because I suppose that
our time is such a resource that we basically it's
not we cannot regain it, it's lost basically, so writing
an article, I mean, junior developers, writing an articles is
something that's at least I try to avoid because I
(16:21):
don't think I had something to tell, something variable to
take tell people, and reading my ten minutes article will
be a loss of time. So I decided to start
writing maybe after thirteen years of working with work applications,
just because I feel a little bit more comfortable and
(16:42):
maybe I have something important to say and people want
to just spend there ten minutes and forget after that.
It's a tricky area at least I feel uncomfortable. So yeah,
that's the main reason I suppose. And I have a
lot of ideas material during these years, so there's plenty
(17:04):
of topics.
Speaker 3 (17:05):
I think after thirteen 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.
Speaker 4 (17:16):
Yeah, yeah, explor six this was there back back then,
I remember.
Speaker 2 (17:22):
But yeah, thirteen years is about where I'm at as well.
I started. My first apps were i E six only
corporate apps, so this is these are fun times.
Speaker 3 (17:35):
Yeah, oh I see here, Oh go ahead, please go ahead.
Speaker 4 (17:39):
I just wanted to say that writing an auto about
to explore six is probably I don't know, what's not
going to be very famous.
Speaker 2 (17:47):
I don't know. It's about time for like the nostalgia
of that to kick in, because now now you can
tell them it's like war stories right like back in
the day.
Speaker 4 (17:57):
Yes, it's true. I mean today people are starting to
react directly. I mean they don't even learn JavaScript. For them,
JavaScript is now it's something like react and five six
years ago, which was maybe je.
Speaker 2 (18:12):
Query so query Angular I think like and we're talking
about testing too. 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 and other browsers, which like sometimes
sometimes you do catch little things like it's it's the
(18:35):
sort of thing where you still do kind of need
to test your code and other browsers, but for the
most part you kind of don't anymore, Like especially on
desktop browsers, Like chances are the code you write is
going to work. And that's still like quite the mind
shift from how it used to be. Where it used
to be you wrote your code and like you opened
your you just prayed before you opened all the other
(18:57):
five or six browsers you needed things to work in.
Speaker 4 (19:00):
True, I to be honest, I don't think I go
out of Chrome and I don't really test on other browsers. Yeah,
and you're right because even qare they don't they don't
find they don't find spucks often another browsers, So it's
things things are working.
Speaker 3 (19:18):
So one question that I had is when I visit
your website, 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,
(19:41):
like an individual contributor or how did how did that happen?
Speaker 4 (19:45):
Yeah, it's uh, I think it happened naturally. Again, it's
it's a small company where I was basically maybe I
was a CEO. Actually I was doing everything because the
owner were in a basic in Sweden and I was
back in Bulgaria at that time, so I was managing
(20:05):
the whole business plus 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
was freelancing a little bit, then moved away from that company,
(20:26):
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. Wow.
Speaker 3 (20:49):
So basically running a company wasn't enough for he had
a dove freelance work on the side too. That's dedication.
Speaker 4 (20:57):
Yes, at some point it became too much, but yeah,
you can do it for some time before you burn out.
Speaker 3 (21:05):
Yeah.
Speaker 2 (21:06):
So looking at the blog, is your blog built with Gatsby?
What what did you use to create this?
Speaker 4 (21:13):
Yeah, it's exactly gets and I was I was inspired
by Don abramovs bloke. It uses the starter team, so
it's really just the start theme Starter team with some
some tweaks. So I just wanted something simple up and
running fast, and after that maybe I will figure out
(21:36):
a better designed for it, but for now it's just
it just works good.
Speaker 2 (21:42):
Yeah.
Speaker 3 (21:42):
I like the just the clean look of it and
the fact that you have dark mode.
Speaker 4 (21:49):
Yeah, it's it's a default thing now, right everybody.
Speaker 2 (21:54):
And I also see you have a newsletter as well.
Speaker 4 (21:57):
Yeah, it's I'm trying to keep with. It's once a
month and I'm trying to send I'm usually sending my
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
(22:18):
interesting thoughts and links maybe I have found, but at
least I'm trying to write about the topics that you
It was difficult to find a quick solution by just googling,
So if I can't really find a solution, I would
write about it. And I remember it was an article
(22:39):
about something like a editorial on how to create a
sticky table header but would react but by using just
a normal table, not a deep based fleck or flax
books based layouts. And it was surprising to me that
actually there are not so many examples that you can find,
(23:01):
and this article is without any is you always now,
it's it's pretty high when you try to look for
something like that. Who will.
Speaker 3 (23:13):
Oh, 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.
Speaker 2 (23:26):
Well, I don't think I know what unique reads are.
Speaker 4 (23:29):
Yeah, it's it's not Google Analytics, because it's so not
straightforward to implement that thing in your blog.
Speaker 2 (23:38):
And I just I just saw it. Okay, you mean
like 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
(24:00):
don't think I've ever seen anybody list unique readers.
Speaker 4 (24:03):
Yeah, it was read, but then I found many blocks
which are just counting the visitors, so they have, for example,
they display sixty thousand views. But that doesn't really make
sense because I can reload my brother two hundred times
and then it's not really useful. And I'm using a
third party service that is just a counter, and whenever
(24:26):
your component renders, I just put in use effect a
call to this service, so it will count, but in
the same time return back the number of unique roods.
So this is the way how it's done.
Speaker 2 (24:40):
It's very simples, like.
Speaker 3 (24:42):
It might be worth a blog post.
Speaker 4 (24:46):
Yeah, it's one of these topics that are not very
well covered. If you try to search how to add
a counter and gets the block. It's all about Google analytics,
and it's so difficult.
Speaker 2 (25:01):
It's funny though, how little things like that people can
find useful. One of the most popular things I've ever
written is I wrote like my blog is a little
bit older, so it's written with Jekyl, and I came
up with some way like it's like a one liner
piece of code to have a jeckal like point to
an external blog post. So if you wanted to list
(25:22):
blog posts but include things that you wrote on like
other places, and that thing gets like, I don't know what,
but it's like a two paragraph blog post and 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.
Speaker 4 (25:43):
Yeah, it's true. 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 do something
like Firebase and try to easily put together some third
(26:04):
party services and vola. It works, but it's it's not really,
I mean, so much effort for for such a simple job.
It's at least I try to think about the simplest
possible solution out there.
Speaker 2 (26:18):
I like it. I feel like that. It's funny because
personal blogs or the one place where over engineering something
is like not only okay, but sometimes almost encourage, right,
because it's like a place that you can experiment and
have some fun with.
Speaker 4 (26:31):
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 don't really have so many readers. It's
it's it's yeah, it's now it's the time to do
crazy things.
Speaker 2 (26:46):
When you get a lot of readers, then they came
for the crazy things, and then you get.
Speaker 4 (26:50):
To yeah they can even see a four or four yeah.
Speaker 2 (26:58):
The yeah, go ahead page, We keep doing this, please continue.
The other thing I'm wondering about, speaking of, like little
implementation details, what are you using to implement the newsletter
it's a.
Speaker 4 (27:11):
Mail Chimp for now. They I think they give one thousands,
I think subscribers for free. So it's yeah, it's pretty
say forward choice for me, but I may change it
in the future.
Speaker 2 (27:27):
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?
Speaker 4 (27:35):
Do you mean the pop up the little.
Speaker 2 (27:38):
Thing says join a foreign end newsletter like little thing
that entices people to subscribe to the newsletter.
Speaker 4 (27:45):
The form on the bottom, Yeah, the form on the
bottom is just the custom made it's not really mail Chimp.
I just post to their service, so it registered the
email address and then I just so just play a
conformed message. But it's not it's not Melchin.
Speaker 2 (28:05):
You've got a little bit of design talent, because that
thing looks really nice. It's very I know you said
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 jealous and I might steal this.
Speaker 4 (28:22):
Yeah, it's it's an evolution.
Speaker 3 (28:27):
Are you hosting a newsletter on your on your website?
Speaker 2 (28:30):
TJ No, No, newsletter, but we do stuff for like
kind to react and progress sometimes and definitely take some
inspiration from this.
Speaker 3 (28:42):
Yeah, I implemented one 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 mail Chimp and mail gun, and I'm yeah,
convert kit is a big one. I ended up going
(29:05):
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
(29:26):
post them, and if people want to 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 crossing
(29:46):
those subscriber thresholds and then having to pay thirty bucks
a month, fifty bucks 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
(30:06):
doesn't matter how big your subscriber base gets, they will
not charge you.
Speaker 4 (30:14):
So it's a little.
Speaker 3 (30:15):
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 I ever want to change it and start paying,
or if I decide that I will not get a
(30:37):
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.
Speaker 4 (30:48):
YEA also heard about substack. I actually have seen Kent
Beeck for example. He's using you as well, so and
he's someone that will I think be immunities around him.
So but he's posting in there. Oh well, that's.
Speaker 3 (31:05):
That's encouraging then to know that people who have big
followings are using it to their advantage too.
Speaker 4 (31:12):
Yeah.
Speaker 2 (31:12):
Yeah, and all the cool kids have newsletters. What am
I even doing with myself?
Speaker 3 (31:16):
It's apparently it's 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.
Speaker 4 (31:27):
Yeah, that's true.
Speaker 2 (31:29):
Is there things that we haven't covered, I know, anything
about testing components that we didn't get to or ask you.
Speaker 4 (31:37):
Oh, I think we touched the basics and if we
have to wrap up, it's just it's very controversial topic,
and I think some sometimes people are too dogmatic about
what we should use in terms of flabbraries. I think, Jane,
it's all about it's all about what you really can
(32:00):
do in your certain situation with your team, with your
organizational structure, because something may work but others won't work
in different organizations.
Speaker 2 (32:13):
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.
Speaker 3 (32:24):
Yeah.
Speaker 4 (32:24):
I mean, for example, if you do all of d
comparisons in your tests and you are publicly doing that
in a 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
(32:47):
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 these things, but it's really
what works for you in this particular situation, because sometimes
don't comparison maybe required, and sometimes you want to test
(33:13):
for a function call, especially if it's somewhere between conditional logic,
So you should really think about, yeah, what works for you.
Speaker 2 (33:25):
Yeah, I feel like that's that's good advice for I
mean React, testing for Reactor, 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
on Twitter for for things that they're doing that you
don't totally have the context for either.
Speaker 4 (33:48):
Yeah, that's why I don't have Twitter. Also, it takes
too much of my time and I don't really have
time to get into converse station since yeah, right and
tweet about relevant.
Speaker 2 (34:05):
Cool Paige, did you have anything else?
Speaker 3 (34:09):
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?
Speaker 4 (34:19):
If you just go to my blog, you will find
a few links probably the best ways. I just email
and I have also linked and GitHub, so this is
the way.
Speaker 2 (34:33):
Well cool, So why don't we move on to the picks? Then, Paige,
you want to kick us off?
Speaker 3 (34:38):
Sure? So my pick this week is going to 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
is the Jack Reacher series on Amazon Prime. And I
believe that it's Tom Clancy's Jack Reacher. It's based on
(34:59):
the book Looks and it is just rewatching it after
having seen it, you know, a year or two 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
(35:22):
binge as we slowly start to come out of the
COVID Hayes 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 into
(35:45):
the show notes about that that I got it wrong
the first time. But Jack Ryan is the series. There's
two seasons. It's a great watch. I would definitely encourage
it if you're, like, if you're into the spy, espionage,
THEIA type of shows.
Speaker 2 (36:03):
Okay, I definitely remember seeing the the ads for this now,
so I'll have to check it out.
Speaker 3 (36:08):
That's a good one. Cool.
Speaker 2 (36:10):
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 just a quick and easy speedometer for it, which
I kind of like. It's kind of fun to like
challenge yourself to see how fast you can go without
dying on Michigan roads. But it's a diet. A little
(36:32):
bit of research and found one I liked, 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 fun times, Mireslav, how about your picks?
Speaker 4 (36:42):
I think I have two. The one is I recently
found out that Eric Crossmans and the person behind the
Rep Final Rep Final Form, he also starts publishing his
blog posts, and so right now he has a bloke
and he's one of the people who I actually learned
(37:03):
a lot and I think 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 and React for quite some time, so
you can you can visit his block based link. And
(37:24):
then the other one is just an article I read
recently from kempt dot'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,
(37:44):
for your React applications, and that is also the case
with many of applicanials I have done. If you really
care for you think about if you can do it
just with React and maybe a little bit of context,
then yeah, we don't really need three ducks. But the
article could be controversial. I will just put that.
Speaker 3 (38:07):
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 REDUCS, which holds the global state versus context, which
(38:28):
just passes state around the application. 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 as
engineers have way over engineered a lot of applications to
use reducts when we probably didn't really need it in
the first place.
Speaker 4 (38:48):
Yeah, it's true. Sometimes we inherit habits from previous applications
and we tend to copy in to pace the same approach.
Speaker 2 (38:57):
Yeah well cool, Well, thanks Mary stuff for joining us.
This was a lot of fun chatting with you. Thank
you too, all right, Well, thanks everybody again and see
you next week. Yeah, see you next time.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy, Jess Hilarious, And Charlamagne Tha God!