December 4, 2024 • 35 mins
Akash Joshi Is a frequent blogger across many of the larger blogs across the internet.
He joins the Round Up to share his opinions on how you should put your React applications together as well as some tips on where you shouldn't put files and where you should avoid putting specific types of files.
Some of this is inspired by projects like Next.js and others by his own experience. Paige and TJ chime in with their experience to help provide more context to the conversation.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/react-round-up--6102072/support.
He joins the Round Up to share his opinions on how you should put your React applications together as well as some tips on where you shouldn't put files and where you should avoid putting specific types of files.
Some of this is inspired by projects like Next.js and others by his own experience. Paige and TJ chime in with their experience to help provide more context to the conversation.
Links
- Learn Structuring React Projects with a Dogs App [⚛ + 🐶]
- A Better Way to Structure React Projects
- Improving my OSS library and taking steps towards improving my YT quality
- Akash Joshi
- The Writing Dev
- Akash Joshi - thewritingdev - YouTube
- Twitter: Akash ( @thewritingdev )
Picks
- Akash- Lapel Microphone
- Paige- Harney & Sons Earl Grey Loose Leaf Tea
- TJ- Kombucha Tea
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:06):
Hey, everyone, Welcome to another episode of React Roundup. I
am your host today, Paige Needringhouse, and I am joined
by our panelist TJ.
Speaker 2 (00:14):
Vantold.
Speaker 1 (00:15):
Hey everybody, and our special guest today is Akash Joshi. Akash,
can you say hi to the audience and tell us
a little bit about yourself why you're famous? But we're
going to talk about today.
Speaker 3 (00:27):
Hey guys, So my name is Akash, and I think
the thing that I might be famous for is talking
a lot about myself and the things that I do online.
And primarily I work as a React developer, and I
try to simplify the complex things that I have learned
(00:48):
and try to share that knowledge through my blog and
through posts on places like record camp and YouTube. And
that's primarily what I try to do.
Speaker 2 (00:57):
That's awesome.
Speaker 1 (00:58):
So what kind of complex things are you learning about
that you're trying to help others get better at?
Speaker 3 (01:05):
So I think React itself might be a complex thing
because we have a lot of web developers here in India.
Most of my friends work in web development, but they
never seem to go beyond just htmls yes, his, JavaScript
and bootstraf and never go into the more productive parts
(01:26):
of web development. Like being able to build applications at
a much faster speed and in a much more scalable
way using technologies like React. So that's where I try
to position my content, and that's what I'm trying to do.
Speaker 4 (01:42):
So I'm curious before we get into some of the
topics themselves, what got you into the teaching aspect of this.
Was it doing running problems you ran into the work
that wanted to help into others, or what made you
want to actually blog and talk about some of these things.
Speaker 3 (01:57):
So, actually, I've been writing about things that I've learned,
and I guess I mean, you could call it teaguing,
but it was a way of noting down the things
that I have learned myself. I started. I mean, am
I allowed to name brands on here like hacker Noon
and publications like that?
Speaker 1 (02:18):
Yeah?
Speaker 3 (02:19):
Yeah, So I kind of started by reading hacker Noon
and it was kind of it used to be the
highlight of the day for me looking at posts that
people have written, and I saw that a lot of
them were people my age who were just learning new
things and writing about them. And that's how I myself
got started. I started with learning note js and then
(02:42):
contributing to a few open source repositories on GitHub, and
as I learned new things while learning notejs, like, for example,
how to publish your own NPM library for example, then
I used to write articles on those things, and that's
also what ended up. I mean, that's how I also
(03:05):
got my first job, because people found out about me
through my articles, And yeah, that's kind of how it's
been progressing so far.
Speaker 2 (03:14):
That's fantastic.
Speaker 1 (03:15):
I've I didn't start writing until after i'd actually gotten
my first job, so it was a little bit backwards
to the way that you went about it. But I've
definitely found that learning things at work and then writing
about them really helps me, helps it solidify in my mind.
And it also helps me when I've forgotten something like
(03:36):
an article I wrote two or three years ago, I
can go back and search through and find how I
did something. So definitely multiple benefits for it. But like,
what do you remember which articles it was that made
your current or your employer reach out to you.
Speaker 3 (03:53):
Those were actually articles about to react. So I used
to reach out to publications like CSS tricks on zero,
and I think publications were more open back a few
years ago to new writers and letting them write for
them basically, So that's how I got started with it.
(04:16):
Like through note js, I ended up learning React while
contributing to an open source organization, and then I tried
to translate some of those skills to an article and
trying to explain how to learn React hooks, which were
the big thing back in twenty eighteen, like the end
of twenty eighteen. I think, so, yeah, that's how it
(04:38):
got started. Cool.
Speaker 4 (04:39):
Well, I know one of the articles you had written
is about structuring React projects, So I'm curious maybe you
could walk people through roughly what you covering that in
any advice you have to people, Because it's stretching React
projects is not a small topic, right, There's lots of
opinions around that. I'm curious what advice you have there.
Speaker 3 (05:00):
Right, definitely, So structuring React projects is one of the
more recent articles that I've written, and I think it
got more eyeballs on it, specially especially because it's such
a polarizing topic. Everyone kind of has their own opinion
on it, and they're willing to read about someone else's
opinion and how I So, how I got started it
(05:25):
with it was basically in my first job, the React
the React projects that I was building weren't that complex,
so I didn't really get a chance to get to
the depths of React. But in my second job, I
had to build uish which had to scale between various
teams and so kind of while building upon the fundamentals
(05:48):
that next JS has set in for the how a
React project should be structured, I kind of added my
own sort of small twists on top of that, and
that's how I landed up at the project structure that
I'm currently using. So should I walk through that what
(06:09):
the project structure is?
Speaker 1 (06:11):
Yeah, definitely for anybody who hasn't read the article, which
we will link to in the show notes, but yeah,
it'd be great to hear what your what your take.
Speaker 2 (06:19):
On it it is.
Speaker 3 (06:20):
Yeah. So one of the first things is that to
not clutter the root folder of the project. It's helpful
to have all of your files separated into a specific
source folder. And then I mostly talk about how various
(06:41):
components of the project should be structured inside of the
source folder. So the primary aspect of any web project
is the routing. So next Days has a good way
of maintaining routes through the pages folder, and I talk
about that how you can create top level routes inside
(07:04):
of these pages, but I don't recommend having any UI
components or the code itself stored inside of these pages,
but having separate component having a separate component folder, and
then naming these folders according to the page or the
(07:25):
set of pages where these components will be used, and
then storing these components inside these name folder structures. And
then I talk about other things like data adaptors and
context stores. So data adaptors would be adaptors like in
(07:45):
the adapter project adaptor pattern of writing code, where these
would just be functions which you would call, and then
the adapter in its own back end would then make
any API call or any ware socket call, or any
anything like that, and then return the data in whatever
(08:06):
format that the original Collie expects. So I also recommend
splitting those splitting the adapters folder into various folders and
files according to the structure of the pages, and context
stores would be Generally, context stores wouldn't be applicable to
simple UH projects, but for more complex projects where generally
(08:32):
people end up using data management library like React, UH,
react context or reducts, then generally UH these context folders
can hold the context stores for these for the set
of pages and yeah, that's what I recommend there, and
(08:57):
the rest of the article then just talks about how
you can store your styles and public assets.
Speaker 4 (09:04):
So I'm curious, just because I haven't done much with
next GS, how much does next enforce Because you said
the pages folder is like a built in next GS thing.
Are there other like special folders with that framework or
is some of that just stuff that you made up
for your recommendations.
Speaker 3 (09:21):
So there are two things which next Days enforces, which
is having a pages folder for storing your routes and
having a public folder to store all of the static
asset files. And the rest of the things or the
rest of the folders were something that I enforced myself,
(09:42):
that I made up myself. I guess, yeah, gotcha.
Speaker 4 (09:45):
So it sounds like you're because usually I find that
most folder structure there's almost like two different paths people take.
Either you group your stuff by your files, by their
type of file, their components, their adapters there, whatever the
case is, or you group by feature, like you have
(10:06):
a folder that this is my I don't know my navigation,
or this is my widget, this is my menu, And
it sounds like you prefer just grouping by feature, right,
like components, adapters, that sort of thing.
Speaker 3 (10:21):
Right, So if you consider a set of files like
catering to a particular feature, then yeah, I agree that
it's kind of similar to grouping by a feature. But
I've heard more. I mean, I've heard the counterargument that
my full destructive actually goes counter to having your having
(10:43):
story having to store your files in terms of features.
So I guess it depends on how you see, how
you look at your application.
Speaker 4 (10:53):
I guess yeah, And I think there's no like right
or wrong way, because angular is very specific, just to
give one example of they recommend not having folders like
that because they'll tell you to do things like just
just no name by features. But that, like, I don't
think there's a right or wrong answer, because I've seen
(11:14):
both get messy when you start to deal at scale,
because then if you're grouping only by features, then in
a complex app, it's like, well, which features are within
what features? And like sometimes you'll have nested features and
then you'll need to refactor them out of it. And
I don't think there's a clean answer to this. But
I always find it interesting what people come up with
(11:36):
for best practices. I don't know, page would you do
at the home depot if you have a folder structure
that you've magically solved solved this problem with it all.
Speaker 1 (11:46):
I don't think that we have that at all. But
the way that my team typically approaches it is we
have a folder that is purely for the API calls
that we call our service layer. We have one four components,
which are the smaller pieces of a React application, like buttons, inputs,
maybe even something as large as a table. And then
(12:09):
we have containers which are kind of the I guess
the pages quote unquote that a next day as project
might contain, So it's things like our whole navbar or
the main contents of a page. And then we have
helper functions that are just used throughout the project, which
(12:29):
are usually kind of plain JavaScript functions that might be
used to format particular data or kind of transform it.
We have hooks, which are the custom hooks that we
use throughout different components in the application. But you know,
it follows the Java pattern a little bit because most
of our back end services are built using Java, and
(12:51):
Java is very prescriptive and how it wants things done,
so we lean on that a bit. But React is
so unopinionated about it, really, however it works for you,
is probably a pretty decent way to kind of filter
your application.
Speaker 4 (13:06):
I think, Yeah, gotcha. I think that's why your article
gets so much attention is because no one's really solved
this and people like hearing other's opinions on the issue.
Speaker 1 (13:17):
Oh yeah, it's a great opportunity to just see how
other people are approaching it, and maybe you can get
something good out of it that you can take back
to your own app.
Speaker 2 (13:25):
Totally.
Speaker 1 (13:26):
So, Akash, I was looking at your website, which I've
also linked to, and I noticed that you're not only
working full time. It looks like you've also got a
couple of side projects, and I'd love to hear a
little bit more about them, because you have a link
to this thing called cash parser and also a link
to product hunt, So can you tell us a little
bit about what you're doing there.
Speaker 3 (13:47):
Yeah. So, gas Sponsor is a kind of fintech micro
startup that I am running with a friend of mine.
So he it's basically his being and I provide all
of the front end help that he needs in going
through that. So cast statements are basically consolidated account statements
(14:12):
that get generated for all of the mutual funds that
a person holds. So mutual funds are basically a set
of stocks that people can buy, and a set of
these mutual funds is stored in that cast statement, and
we allow passing of that statement and generating the data
(14:33):
in whatever format that the user needs. So that's where
that's what cash pars is about. And on product hunt,
I generally try to post about some fun side projects
that I have I might have built. Like for example,
I used to have a telegram bot which used to
(14:54):
give notifications whenever a website changed. So I used to
use this spot to track the results page for my university,
and some other people did some other fun projects with it,
like tracking the careers page of a place ef work
that they wanted to work at or something like that,
(15:15):
and so I had to take that brought down because
it was too resource intensive. But I have made its
API open and basically the other projects small small projects
like this that I have found useful for myself, and
then I try to put them on product and to
(15:35):
try to get some other users for it.
Speaker 1 (15:38):
Yeah, that's very nice of you to share that kind
of software because that sounds really useful for different.
Speaker 4 (15:43):
Things with sites here, where you would you just paying
like a configurable amount like paying a site store. What
was there and like if if it notices like any changes,
then sends a message.
Speaker 3 (15:57):
Yeah, yeah, that's exactly what it used to do.
Speaker 2 (16:01):
Very cool.
Speaker 1 (16:02):
So are you continuing to work on side projects like
this or is there anything else that you're doing, like
I don't know, writing courses or kind of blogging more.
What are you like, what are you most focused.
Speaker 3 (16:17):
On right now? Yeah? I think I'm too young to
write a course or you know, ask payment for someone
to teach them something, while there are like more smarter
people who can who freely provide content for things that
people want to learn about. So that's what I also
(16:38):
tried to do earlier. I used to make side projects
for fun, and later on it became that I wanted
to try to monitor some of the work that I
had done earlier and try to build on that. But then,
I mean, when you're trying to monetize something, things start
to become less fun because you have to worry about
things like marketing. There might be search engine optimize, building
(17:01):
landing pages, stuff like that. So then I kind of
slowed that down a little bit, and now I'm creating content.
Content that is that would be fun for me to make,
if it makes sense. So when I feel like it,
I write a blog. When I feel like it, I
try to record a YouTube video. Now, editing a YouTube
(17:23):
video is not fun. Recording can be fun.
Speaker 1 (17:27):
Sometimes I can totally relate to that.
Speaker 3 (17:30):
That's what I do.
Speaker 2 (17:33):
Nice.
Speaker 1 (17:34):
I can definitely relate to that, not the whole monetizing thing.
But the second something goes from being just kind of
like a hobby project too, and I must do this
or get this to work, it's it's usually a lot
less fun that way.
Speaker 4 (17:47):
Yeah, having lots of users is like a double edged sword.
It's cool. But at the same time, then people have demands,
especially if they're paying money then they have they have
a lot more demands and.
Speaker 1 (18:00):
A lot more sway over what you'll actually do for them. Yeah, yeah,
well that's cool. So what kind of day to day
things do you get to use for your work with
your company that you work for, Like what kind of
tech stack and tools?
Speaker 3 (18:16):
So it might sound boring to some people that I
get to work with React a lot, but it's actually
really fun for me because JavaScript is how I got started,
and React for me is the best expression of JavaScript
and especially via typescript, where I can kind of automat
(18:38):
aly most of my workflow. And then it's fun to
think about how I can build something with the minimum
amount of lines of code by trying to create the
optimum function which can be reused everywhere, or basically reduce
the amount of work that I would have to do
to build something. So yeah, mostly I do get to
(19:02):
work with reacting typeescript, and I hope to learn rest soon.
Speaker 1 (19:08):
I've heard a lot of people who seem to be
jobs script developers kind of gravitating towards Rust. What's kind
of drawing you towards it?
Speaker 3 (19:17):
So I especially like the functional programming paradigms inside of JavaScript,
and I try to use them as much as possible.
So when I look at last, I like most university
students have of course learned CNC plus plus and nobody
(19:38):
like after playing with modern programming languages, going back to
that is not fun. But Rust is something different because it,
even though it has some complex programming paradigms like it
quite strictly defines the life cycles of a variable and
(19:58):
you have to deal with things like borrowing memory values
between variables. It's still fun because the kind of strictness
that it applies is eventually what results in better, better
code being written. But of course I don't speak this
from my experience. This is just from things I've read
on link. But more experienced Trust developer would probably be
(20:24):
able to give this answer better. But yeah, that was
my opinion on this.
Speaker 2 (20:27):
It's funny page.
Speaker 4 (20:28):
You're right, I feel like Rust is the cool thing
for JavaScript developers to do. I feel like we missed
the memo here at some point because I haven't gotten
into Rust at all. But I also think like it's
funny that a lot of JavaScript tooling is now starting.
There's like some Rust based tools that are supposedly faster
that are starting to become more popular. So it's going
(20:51):
to be interesting to see how that changes over time.
Maybe I'll have to learn it too.
Speaker 1 (20:55):
I now I hear this kind of stuff pretty regularly,
like Rust Go. But I guess my problem is a
time management one where I use Java and I use
React mostly for my job, and so that's what most
of my time goes towards, is those two programming languages.
(21:18):
I've used Python a little bit. I'd like to learn Go,
I think, because I've heard really good things about it.
Speaker 2 (21:24):
But it's there's just so.
Speaker 1 (21:25):
Many languages and so little time to learn them and
then apply them, I guess, is the main thing.
Speaker 4 (21:30):
Yeah, And I think like, at least for me, I
have to have a reason to do it, right, like
if I have a project in mind, and Akash, like,
it's interesting hearing some of your stories too, because you're
like a lot of these side projects came out of
actual problems you had or things that you wanted to do,
which is always interesting to see because at least for me,
(21:52):
and I don't know about you too, but I can't
just sit down and say, like, well, I'm going to
learn erlink today, right, Like if I do that, like
there's no amount of focus the world that's going to
get me to learn earlang. But if I had like
some problem that I needed to solve in my life
or for my job, and like, okay, sure, like that
gives my brain a reason to sit down and focus
and do it.
Speaker 2 (22:11):
Absolutely.
Speaker 1 (22:12):
I tried that with Haskell one time because a programmer
who I work with had a senior developer he had
recommended it as a good way to kind of get
your feet wet with functional programming. And I made it
through I don't know, maybe three two or three chapters
of getting started with Haskell book and then just put
it down and never picked it back up again.
Speaker 2 (22:33):
So yeah, you definitely have to have.
Speaker 1 (22:35):
Something that you're trying to solve, not just trying to
learn for the fun of I think.
Speaker 4 (22:41):
Actually, Akasha, I'm curious because you said that you had
kind of liked the functional style of programming, and I'm curious,
is that come from like work experience or school, because
I say this as someone that functional is never totally
clicked from me, and maybe like because like page, I
came from a Java background, and Java is very much
not I mean, there's you can kind of do some
(23:02):
functional things, but it's very much not a functional language really,
so I struggled to get my brain to work that way.
So I'm curious why, like, what made you interested in
that approach.
Speaker 3 (23:13):
Yeah. So I didn't pick up functional programming in university
because most of the university classes are based on objectory interprogramming.
But where I initially started picking up functional programming was
again when I was reading Hacker Moon back then, and
(23:34):
there were a lot of articles written about things like
I guess monads, which nobody really understands. But then there
were things about like topics like composibility of functions and immutability.
So immutability and pure functions. Those are the two things
which really got me into functional programming because then I
(23:57):
could write code, which wasn't surprising kind of so in
seeing you end up writing code which you don't understand
what it does, like at least I used to, because
I couldn't try see well, I guess. But with functional programming,
I could write JavaScript, which even if I come back
(24:21):
to later, I could still understand what it does basically.
And I that's also kind of how I got into
open source, because I see that open source repositories, which
are written in a more functional way, are generally more
readable because everything has its own like, everything is separated
(24:42):
into its own concern kind of yes, And I'm not
sure if the exact terminology here.
Speaker 4 (24:47):
Yeah, that makes sense.
Speaker 1 (24:49):
Yeah, I think I think we get kind of the
separation of concerns is what you're an encapsulation, I guess.
Speaker 3 (24:56):
But I guess. I mean these two terms are generally
used for dictorian in the programming do so yeah.
Speaker 4 (25:03):
Yeah, I feel like functional programming is like a cult
that I haven't gotten an invite into because everybody, like
I feel like, once you've drank the functional kool aid,
like you can't stop talking about it and you start
recommending has scale to your co workers and like like
all this stuff, and I still like, I still like, see,
(25:24):
I've heard the term monad literally hundreds of times, right
and if you ask me right now to explain to
you what a monad is, I couldn't even try, Like,
I will not nothing, nothing will come out interesting. So
it's actually I find it quite interesting that, like just
from some articles that you were able to pick up
on that, because it's, at least to me, it's pretty impressive.
Speaker 1 (25:46):
Yeah, Like, currying is something that I know is is
very big and functional, and I can understand the general
idea of it, but then actually trying to put that
into practice in my code somewhere is a very large
challenge to me.
Speaker 4 (26:00):
Still, yep, exactly.
Speaker 1 (26:03):
But it's definitely super powerful when you know what you're doing.
I've seen some really just great, great code written from it.
But man, the people who know how to do that
and can visualize it ahead of time hats off to you.
That's a great skill to have for sure.
Speaker 4 (26:19):
So cash another thing you've got you have and your.
Speaker 3 (26:22):
Getting I would definitely not put myself into the leagues
of great functional programmers because Monald is something which I
can still not explain. Currying is something I generally don't
use myself. But just with immutability and writing pure functions,
(26:43):
which is like functions which only have one use case
and don't affect any values outside of the function except
for the ones which are provided as input to it,
I mean, just by these two concepts, you can go
pretty far in functional programming, is what I feel very cool.
Speaker 4 (27:00):
But there's another project on your GitHub that I wanted
to bring up. Is you have this project called functions
without Borders. Maybe you could tell us a little bit
about what this is in what you're trying to solve
with this this project.
Speaker 3 (27:15):
Yeah, so functions without Borders was built to again solve
a problem that I had. I basically hate writing server
side interfaces because a lot of time gets spent in
doing that. Like whenever I have to write something, I
have to write ten httpa API. What is it called?
(27:38):
If I write it on the server side, like an
end points or yeah, I have to write a lot.
I end up having to write a lot of endpoints
and then a lot of getters on the client side.
So what this library does is it kind of abstracts
away everything and it also mixes in a lot of
(28:00):
typescript to basically make a server side ATI calls fail
like a native function call on the client side, So
it allows you to use the same typescript types between
the client and the server. So while defining your server,
(28:22):
if you're using a set of types, then you can
pass the same types to the client side also, and
then basically you can call those functions on the client
as if they were written on the client itself. But
actually the library makes a web socket call and then
(28:43):
gets the data from the server.
Speaker 2 (28:45):
Very cool.
Speaker 1 (28:45):
So it's like your own version of server side rendering.
Speaker 3 (28:49):
Yeah, I guess.
Speaker 4 (28:50):
So then where do you deploy the server code too?
Is it just like any like is it like a
Lamba city situation or where would the server code end up?
Speaker 3 (29:03):
I don't think. I mean, I haven't tried deploying it
to any server less library yet, but it's mostly about
a server full situation where you might have a server
constantly running and then the client can be anything. It
can be a browser, or it can be another server
(29:23):
or wherever you want to run it on. Basically very cool.
Speaker 1 (29:28):
So, Akash, is there anything that we haven't covered yet
that you think that you'd.
Speaker 2 (29:32):
Like to talk about?
Speaker 3 (29:33):
I don't think so. I've covered mostly everything that I'm
passionate about what I like to learn and talk about.
I guess yeah.
Speaker 2 (29:46):
Very cool.
Speaker 1 (29:47):
So if people would like to get in touch with you,
what are the best ways.
Speaker 3 (29:51):
They can reach out to me? On Twitter? At the
writing dev. They can check out my blog at the
writing dot dev where they can subscribe to my blog,
and if they reply to any of the emails, the
reply actually reaches to me directly.
Speaker 2 (30:09):
Very very cool, awesome.
Speaker 1 (30:10):
So I think this is the point in the show
where we're going to move into picks and we'll share
things that we've been using that we're fans of things.
It could be a site that you've found, a product
that you like, basically a show you've watched that you've enjoyed. So, TJ,
would you like to start us off this week?
Speaker 4 (30:29):
I can start us off yeat. So my pick for
this week is going to be kombucha. There's no page Akasha,
you have you had kimbucha before? Do you get the reference.
Speaker 1 (30:38):
I have not tried it, but I've seen it at
the grocery store.
Speaker 4 (30:42):
Okay, So I had never tried it in my life.
I didn't know yeah ferm entity, which I couldn't totally
explain exactly what it is. So I'm glad you know
more about it than I do, apparently, but the i'd
heard of it before in a fee shot near me
had it, so I was like, what the heck, let's
(31:03):
let's try it. And it was I think it started
a new obsession of mine because I just went to
the store and bought a whole bunch of it because
it's quite good. It's it's since it's tea based, it's caffeinated,
but it's got just a little bit of caffeine right.
So I've I've had a bit of a coffee problem lately,
where working from home, the coffee consumption was getting a
(31:24):
little out of control, and I've really enjoyed kombucha. The
place near me has it in a lot of different flavors.
So if you haven't tried it before, Paige, you might
want to just get some from the grocery store.
Speaker 2 (31:37):
Just to say.
Speaker 4 (31:37):
You say you've done it.
Speaker 1 (31:39):
I will definitely give that a try now that I
know somebody who is a fan of it. Is there
a particular flavor that you've liked.
Speaker 4 (31:48):
I like the fruit based ones Akasha. I don't know
if you have any. Let me see if I can
dig up exactly which one. I've Hadasha's kombucha popular in
India around you Mark Randy.
Speaker 3 (31:59):
I had kind of found it in a norveety Japanese book, So,
I mean, it's a bit expensive, but it's really tasty
at least I think the taste is quite different from regularity,
so it's fun to drink.
Speaker 4 (32:13):
Yeah, So I've had some that are like cherry based. Interestingly,
it was quite good and like like a cranberry orange
one as well that I like. So that the fruity
ones I thought worked really well. So that's that's my pick.
Speaker 2 (32:27):
Nice, I like it. I will go next. TJ.
Speaker 1 (32:30):
You've inspired me with your choice of kombucha. I will
choose a loose leaf earl gray tea that I recently
found and I've been drinking just typical tea bags of
Earl Gray probably about the past year or so. My
husband has been doing it since he was a kid,
and since I've been working from home also, and we
(32:51):
work from home together. We will now have tea at
about three o'clock and take a quick break and just
kind of check in and see how the other one's doing.
But recently we've upgraded from the tea bags to this
loose leaf version from Harney and Sons, and wow, what
a difference that day. It's It's definitely got a lot
(33:13):
of extra flavor in it. It's a little bit more
involved because you can't just dunk the bag and you
have to have a little tea strainer that you put
in your cup. But I think it's really worth it.
It's been really, really enjoyable. So that's what I would
recommend today. If we're going along the eating and drinking route.
Speaker 2 (33:34):
It's available on Amazon.
Speaker 1 (33:36):
It's not too too expensive and you can certainly get
a pretty decent amount of it for the price. So
I'm going to go with Harney and Son's Earl Gray
Tea and Akash. Do you have anything that you'd like
to share?
Speaker 3 (33:48):
Yeah, I don't have anything, especially on the eating and
drinking side, since the lockdown has stopped all of the
random things that I used to eat. But what I
would recommend is a label MIC. So I'm using one
right now, and it dramatically improves the audio quality that
(34:10):
I have in zoom calls and video calls or you know,
while just recording audio on for my YouTube channel or
anywhere else. So yeah, I would recommend having a label
MIC as a starter kit for a YouTube channel.
Speaker 2 (34:27):
I guess fantastic. That's always good.
Speaker 1 (34:30):
I think people are always looking for good microphones, good cameras,
good good, all that stuff, especially since our lives are
very video driven nowadays.
Speaker 2 (34:42):
Very cool.
Speaker 1 (34:43):
So we'll have a link to that in the show notes,
and we will have all of your links where people
can reach you, see some of your articles, check out
your website as well. So thank you so much for
joining us today. It's been really fun to talk to you.
Speaker 3 (34:57):
Thank you, guys, it's been fun talking with you also excellent.
Speaker 1 (35:01):
So we will see you next time on the React
Roundup Show By everyone,
Hey, everyone, Welcome to another episode of React Roundup. I
am your host today, Paige Needringhouse, and I am joined
by our panelist TJ.
Speaker 2 (00:14):
Vantold.
Speaker 1 (00:15):
Hey everybody, and our special guest today is Akash Joshi. Akash,
can you say hi to the audience and tell us
a little bit about yourself why you're famous? But we're
going to talk about today.
Speaker 3 (00:27):
Hey guys, So my name is Akash, and I think
the thing that I might be famous for is talking
a lot about myself and the things that I do online.
And primarily I work as a React developer, and I
try to simplify the complex things that I have learned
(00:48):
and try to share that knowledge through my blog and
through posts on places like record camp and YouTube. And
that's primarily what I try to do.
Speaker 2 (00:57):
That's awesome.
Speaker 1 (00:58):
So what kind of complex things are you learning about
that you're trying to help others get better at?
Speaker 3 (01:05):
So I think React itself might be a complex thing
because we have a lot of web developers here in India.
Most of my friends work in web development, but they
never seem to go beyond just htmls yes, his, JavaScript
and bootstraf and never go into the more productive parts
(01:26):
of web development. Like being able to build applications at
a much faster speed and in a much more scalable
way using technologies like React. So that's where I try
to position my content, and that's what I'm trying to do.
Speaker 4 (01:42):
So I'm curious before we get into some of the
topics themselves, what got you into the teaching aspect of this.
Was it doing running problems you ran into the work
that wanted to help into others, or what made you
want to actually blog and talk about some of these things.
Speaker 3 (01:57):
So, actually, I've been writing about things that I've learned,
and I guess I mean, you could call it teaguing,
but it was a way of noting down the things
that I have learned myself. I started. I mean, am
I allowed to name brands on here like hacker Noon
and publications like that?
Speaker 1 (02:18):
Yeah?
Speaker 3 (02:19):
Yeah, So I kind of started by reading hacker Noon
and it was kind of it used to be the
highlight of the day for me looking at posts that
people have written, and I saw that a lot of
them were people my age who were just learning new
things and writing about them. And that's how I myself
got started. I started with learning note js and then
(02:42):
contributing to a few open source repositories on GitHub, and
as I learned new things while learning notejs, like, for example,
how to publish your own NPM library for example, then
I used to write articles on those things, and that's
also what ended up. I mean, that's how I also
(03:05):
got my first job, because people found out about me
through my articles, And yeah, that's kind of how it's
been progressing so far.
Speaker 2 (03:14):
That's fantastic.
Speaker 1 (03:15):
I've I didn't start writing until after i'd actually gotten
my first job, so it was a little bit backwards
to the way that you went about it. But I've
definitely found that learning things at work and then writing
about them really helps me, helps it solidify in my mind.
And it also helps me when I've forgotten something like
(03:36):
an article I wrote two or three years ago, I
can go back and search through and find how I
did something. So definitely multiple benefits for it. But like,
what do you remember which articles it was that made
your current or your employer reach out to you.
Speaker 3 (03:53):
Those were actually articles about to react. So I used
to reach out to publications like CSS tricks on zero,
and I think publications were more open back a few
years ago to new writers and letting them write for
them basically, So that's how I got started with it.
(04:16):
Like through note js, I ended up learning React while
contributing to an open source organization, and then I tried
to translate some of those skills to an article and
trying to explain how to learn React hooks, which were
the big thing back in twenty eighteen, like the end
of twenty eighteen. I think, so, yeah, that's how it
(04:38):
got started. Cool.
Speaker 4 (04:39):
Well, I know one of the articles you had written
is about structuring React projects, So I'm curious maybe you
could walk people through roughly what you covering that in
any advice you have to people, Because it's stretching React
projects is not a small topic, right, There's lots of
opinions around that. I'm curious what advice you have there.
Speaker 3 (05:00):
Right, definitely, So structuring React projects is one of the
more recent articles that I've written, and I think it
got more eyeballs on it, specially especially because it's such
a polarizing topic. Everyone kind of has their own opinion
on it, and they're willing to read about someone else's
opinion and how I So, how I got started it
(05:25):
with it was basically in my first job, the React
the React projects that I was building weren't that complex,
so I didn't really get a chance to get to
the depths of React. But in my second job, I
had to build uish which had to scale between various
teams and so kind of while building upon the fundamentals
(05:48):
that next JS has set in for the how a
React project should be structured, I kind of added my
own sort of small twists on top of that, and
that's how I landed up at the project structure that
I'm currently using. So should I walk through that what
(06:09):
the project structure is?
Speaker 1 (06:11):
Yeah, definitely for anybody who hasn't read the article, which
we will link to in the show notes, but yeah,
it'd be great to hear what your what your take.
Speaker 2 (06:19):
On it it is.
Speaker 3 (06:20):
Yeah. So one of the first things is that to
not clutter the root folder of the project. It's helpful
to have all of your files separated into a specific
source folder. And then I mostly talk about how various
(06:41):
components of the project should be structured inside of the
source folder. So the primary aspect of any web project
is the routing. So next Days has a good way
of maintaining routes through the pages folder, and I talk
about that how you can create top level routes inside
(07:04):
of these pages, but I don't recommend having any UI
components or the code itself stored inside of these pages,
but having separate component having a separate component folder, and
then naming these folders according to the page or the
(07:25):
set of pages where these components will be used, and
then storing these components inside these name folder structures. And
then I talk about other things like data adaptors and
context stores. So data adaptors would be adaptors like in
(07:45):
the adapter project adaptor pattern of writing code, where these
would just be functions which you would call, and then
the adapter in its own back end would then make
any API call or any ware socket call, or any
anything like that, and then return the data in whatever
(08:06):
format that the original Collie expects. So I also recommend
splitting those splitting the adapters folder into various folders and
files according to the structure of the pages, and context
stores would be Generally, context stores wouldn't be applicable to
simple UH projects, but for more complex projects where generally
(08:32):
people end up using data management library like React, UH,
react context or reducts, then generally UH these context folders
can hold the context stores for these for the set
of pages and yeah, that's what I recommend there, and
(08:57):
the rest of the article then just talks about how
you can store your styles and public assets.
Speaker 4 (09:04):
So I'm curious, just because I haven't done much with
next GS, how much does next enforce Because you said
the pages folder is like a built in next GS thing.
Are there other like special folders with that framework or
is some of that just stuff that you made up
for your recommendations.
Speaker 3 (09:21):
So there are two things which next Days enforces, which
is having a pages folder for storing your routes and
having a public folder to store all of the static
asset files. And the rest of the things or the
rest of the folders were something that I enforced myself,
(09:42):
that I made up myself. I guess, yeah, gotcha.
Speaker 4 (09:45):
So it sounds like you're because usually I find that
most folder structure there's almost like two different paths people take.
Either you group your stuff by your files, by their
type of file, their components, their adapters there, whatever the
case is, or you group by feature, like you have
(10:06):
a folder that this is my I don't know my navigation,
or this is my widget, this is my menu, And
it sounds like you prefer just grouping by feature, right,
like components, adapters, that sort of thing.
Speaker 3 (10:21):
Right, So if you consider a set of files like
catering to a particular feature, then yeah, I agree that
it's kind of similar to grouping by a feature. But
I've heard more. I mean, I've heard the counterargument that
my full destructive actually goes counter to having your having
(10:43):
story having to store your files in terms of features.
So I guess it depends on how you see, how
you look at your application.
Speaker 4 (10:53):
I guess yeah, And I think there's no like right
or wrong way, because angular is very specific, just to
give one example of they recommend not having folders like
that because they'll tell you to do things like just
just no name by features. But that, like, I don't
think there's a right or wrong answer, because I've seen
(11:14):
both get messy when you start to deal at scale,
because then if you're grouping only by features, then in
a complex app, it's like, well, which features are within
what features? And like sometimes you'll have nested features and
then you'll need to refactor them out of it. And
I don't think there's a clean answer to this. But
I always find it interesting what people come up with
(11:36):
for best practices. I don't know, page would you do
at the home depot if you have a folder structure
that you've magically solved solved this problem with it all.
Speaker 1 (11:46):
I don't think that we have that at all. But
the way that my team typically approaches it is we
have a folder that is purely for the API calls
that we call our service layer. We have one four components,
which are the smaller pieces of a React application, like buttons, inputs,
maybe even something as large as a table. And then
(12:09):
we have containers which are kind of the I guess
the pages quote unquote that a next day as project
might contain, So it's things like our whole navbar or
the main contents of a page. And then we have
helper functions that are just used throughout the project, which
(12:29):
are usually kind of plain JavaScript functions that might be
used to format particular data or kind of transform it.
We have hooks, which are the custom hooks that we
use throughout different components in the application. But you know,
it follows the Java pattern a little bit because most
of our back end services are built using Java, and
(12:51):
Java is very prescriptive and how it wants things done,
so we lean on that a bit. But React is
so unopinionated about it, really, however it works for you,
is probably a pretty decent way to kind of filter
your application.
Speaker 4 (13:06):
I think, Yeah, gotcha. I think that's why your article
gets so much attention is because no one's really solved
this and people like hearing other's opinions on the issue.
Speaker 1 (13:17):
Oh yeah, it's a great opportunity to just see how
other people are approaching it, and maybe you can get
something good out of it that you can take back
to your own app.
Speaker 2 (13:25):
Totally.
Speaker 1 (13:26):
So, Akash, I was looking at your website, which I've
also linked to, and I noticed that you're not only
working full time. It looks like you've also got a
couple of side projects, and I'd love to hear a
little bit more about them, because you have a link
to this thing called cash parser and also a link
to product hunt, So can you tell us a little
bit about what you're doing there.
Speaker 3 (13:47):
Yeah. So, gas Sponsor is a kind of fintech micro
startup that I am running with a friend of mine.
So he it's basically his being and I provide all
of the front end help that he needs in going
through that. So cast statements are basically consolidated account statements
(14:12):
that get generated for all of the mutual funds that
a person holds. So mutual funds are basically a set
of stocks that people can buy, and a set of
these mutual funds is stored in that cast statement, and
we allow passing of that statement and generating the data
(14:33):
in whatever format that the user needs. So that's where
that's what cash pars is about. And on product hunt,
I generally try to post about some fun side projects
that I have I might have built. Like for example,
I used to have a telegram bot which used to
(14:54):
give notifications whenever a website changed. So I used to
use this spot to track the results page for my university,
and some other people did some other fun projects with it,
like tracking the careers page of a place ef work
that they wanted to work at or something like that,
(15:15):
and so I had to take that brought down because
it was too resource intensive. But I have made its
API open and basically the other projects small small projects
like this that I have found useful for myself, and
then I try to put them on product and to
(15:35):
try to get some other users for it.
Speaker 1 (15:38):
Yeah, that's very nice of you to share that kind
of software because that sounds really useful for different.
Speaker 4 (15:43):
Things with sites here, where you would you just paying
like a configurable amount like paying a site store. What
was there and like if if it notices like any changes,
then sends a message.
Speaker 3 (15:57):
Yeah, yeah, that's exactly what it used to do.
Speaker 2 (16:01):
Very cool.
Speaker 1 (16:02):
So are you continuing to work on side projects like
this or is there anything else that you're doing, like
I don't know, writing courses or kind of blogging more.
What are you like, what are you most focused.
Speaker 3 (16:17):
On right now? Yeah? I think I'm too young to
write a course or you know, ask payment for someone
to teach them something, while there are like more smarter
people who can who freely provide content for things that
people want to learn about. So that's what I also
(16:38):
tried to do earlier. I used to make side projects
for fun, and later on it became that I wanted
to try to monitor some of the work that I
had done earlier and try to build on that. But then,
I mean, when you're trying to monetize something, things start
to become less fun because you have to worry about
things like marketing. There might be search engine optimize, building
(17:01):
landing pages, stuff like that. So then I kind of
slowed that down a little bit, and now I'm creating content.
Content that is that would be fun for me to make,
if it makes sense. So when I feel like it,
I write a blog. When I feel like it, I
try to record a YouTube video. Now, editing a YouTube
(17:23):
video is not fun. Recording can be fun.
Speaker 1 (17:27):
Sometimes I can totally relate to that.
Speaker 3 (17:30):
That's what I do.
Speaker 2 (17:33):
Nice.
Speaker 1 (17:34):
I can definitely relate to that, not the whole monetizing thing.
But the second something goes from being just kind of
like a hobby project too, and I must do this
or get this to work, it's it's usually a lot
less fun that way.
Speaker 4 (17:47):
Yeah, having lots of users is like a double edged sword.
It's cool. But at the same time, then people have demands,
especially if they're paying money then they have they have
a lot more demands and.
Speaker 1 (18:00):
A lot more sway over what you'll actually do for them. Yeah, yeah,
well that's cool. So what kind of day to day
things do you get to use for your work with
your company that you work for, Like what kind of
tech stack and tools?
Speaker 3 (18:16):
So it might sound boring to some people that I
get to work with React a lot, but it's actually
really fun for me because JavaScript is how I got started,
and React for me is the best expression of JavaScript
and especially via typescript, where I can kind of automat
(18:38):
aly most of my workflow. And then it's fun to
think about how I can build something with the minimum
amount of lines of code by trying to create the
optimum function which can be reused everywhere, or basically reduce
the amount of work that I would have to do
to build something. So yeah, mostly I do get to
(19:02):
work with reacting typeescript, and I hope to learn rest soon.
Speaker 1 (19:08):
I've heard a lot of people who seem to be
jobs script developers kind of gravitating towards Rust. What's kind
of drawing you towards it?
Speaker 3 (19:17):
So I especially like the functional programming paradigms inside of JavaScript,
and I try to use them as much as possible.
So when I look at last, I like most university
students have of course learned CNC plus plus and nobody
(19:38):
like after playing with modern programming languages, going back to
that is not fun. But Rust is something different because it,
even though it has some complex programming paradigms like it
quite strictly defines the life cycles of a variable and
(19:58):
you have to deal with things like borrowing memory values
between variables. It's still fun because the kind of strictness
that it applies is eventually what results in better, better
code being written. But of course I don't speak this
from my experience. This is just from things I've read
on link. But more experienced Trust developer would probably be
(20:24):
able to give this answer better. But yeah, that was
my opinion on this.
Speaker 2 (20:27):
It's funny page.
Speaker 4 (20:28):
You're right, I feel like Rust is the cool thing
for JavaScript developers to do. I feel like we missed
the memo here at some point because I haven't gotten
into Rust at all. But I also think like it's
funny that a lot of JavaScript tooling is now starting.
There's like some Rust based tools that are supposedly faster
that are starting to become more popular. So it's going
(20:51):
to be interesting to see how that changes over time.
Maybe I'll have to learn it too.
Speaker 1 (20:55):
I now I hear this kind of stuff pretty regularly,
like Rust Go. But I guess my problem is a
time management one where I use Java and I use
React mostly for my job, and so that's what most
of my time goes towards, is those two programming languages.
(21:18):
I've used Python a little bit. I'd like to learn Go,
I think, because I've heard really good things about it.
Speaker 2 (21:24):
But it's there's just so.
Speaker 1 (21:25):
Many languages and so little time to learn them and
then apply them, I guess, is the main thing.
Speaker 4 (21:30):
Yeah, And I think like, at least for me, I
have to have a reason to do it, right, like
if I have a project in mind, and Akash, like,
it's interesting hearing some of your stories too, because you're
like a lot of these side projects came out of
actual problems you had or things that you wanted to do,
which is always interesting to see because at least for me,
(21:52):
and I don't know about you too, but I can't
just sit down and say, like, well, I'm going to
learn erlink today, right, Like if I do that, like
there's no amount of focus the world that's going to
get me to learn earlang. But if I had like
some problem that I needed to solve in my life
or for my job, and like, okay, sure, like that
gives my brain a reason to sit down and focus
and do it.
Speaker 2 (22:11):
Absolutely.
Speaker 1 (22:12):
I tried that with Haskell one time because a programmer
who I work with had a senior developer he had
recommended it as a good way to kind of get
your feet wet with functional programming. And I made it
through I don't know, maybe three two or three chapters
of getting started with Haskell book and then just put
it down and never picked it back up again.
Speaker 2 (22:33):
So yeah, you definitely have to have.
Speaker 1 (22:35):
Something that you're trying to solve, not just trying to
learn for the fun of I think.
Speaker 4 (22:41):
Actually, Akasha, I'm curious because you said that you had
kind of liked the functional style of programming, and I'm curious,
is that come from like work experience or school, because
I say this as someone that functional is never totally
clicked from me, and maybe like because like page, I
came from a Java background, and Java is very much
not I mean, there's you can kind of do some
(23:02):
functional things, but it's very much not a functional language really,
so I struggled to get my brain to work that way.
So I'm curious why, like, what made you interested in
that approach.
Speaker 3 (23:13):
Yeah. So I didn't pick up functional programming in university
because most of the university classes are based on objectory interprogramming.
But where I initially started picking up functional programming was
again when I was reading Hacker Moon back then, and
(23:34):
there were a lot of articles written about things like
I guess monads, which nobody really understands. But then there
were things about like topics like composibility of functions and immutability.
So immutability and pure functions. Those are the two things
which really got me into functional programming because then I
(23:57):
could write code, which wasn't surprising kind of so in
seeing you end up writing code which you don't understand
what it does, like at least I used to, because
I couldn't try see well, I guess. But with functional programming,
I could write JavaScript, which even if I come back
(24:21):
to later, I could still understand what it does basically.
And I that's also kind of how I got into
open source, because I see that open source repositories, which
are written in a more functional way, are generally more
readable because everything has its own like, everything is separated
(24:42):
into its own concern kind of yes, And I'm not
sure if the exact terminology here.
Speaker 4 (24:47):
Yeah, that makes sense.
Speaker 1 (24:49):
Yeah, I think I think we get kind of the
separation of concerns is what you're an encapsulation, I guess.
Speaker 3 (24:56):
But I guess. I mean these two terms are generally
used for dictorian in the programming do so yeah.
Speaker 4 (25:03):
Yeah, I feel like functional programming is like a cult
that I haven't gotten an invite into because everybody, like
I feel like, once you've drank the functional kool aid,
like you can't stop talking about it and you start
recommending has scale to your co workers and like like
all this stuff, and I still like, I still like, see,
(25:24):
I've heard the term monad literally hundreds of times, right
and if you ask me right now to explain to
you what a monad is, I couldn't even try, Like,
I will not nothing, nothing will come out interesting. So
it's actually I find it quite interesting that, like just
from some articles that you were able to pick up
on that, because it's, at least to me, it's pretty impressive.
Speaker 1 (25:46):
Yeah, Like, currying is something that I know is is
very big and functional, and I can understand the general
idea of it, but then actually trying to put that
into practice in my code somewhere is a very large
challenge to me.
Speaker 4 (26:00):
Still, yep, exactly.
Speaker 1 (26:03):
But it's definitely super powerful when you know what you're doing.
I've seen some really just great, great code written from it.
But man, the people who know how to do that
and can visualize it ahead of time hats off to you.
That's a great skill to have for sure.
Speaker 4 (26:19):
So cash another thing you've got you have and your.
Speaker 3 (26:22):
Getting I would definitely not put myself into the leagues
of great functional programmers because Monald is something which I
can still not explain. Currying is something I generally don't
use myself. But just with immutability and writing pure functions,
(26:43):
which is like functions which only have one use case
and don't affect any values outside of the function except
for the ones which are provided as input to it,
I mean, just by these two concepts, you can go
pretty far in functional programming, is what I feel very cool.
Speaker 4 (27:00):
But there's another project on your GitHub that I wanted
to bring up. Is you have this project called functions
without Borders. Maybe you could tell us a little bit
about what this is in what you're trying to solve
with this this project.
Speaker 3 (27:15):
Yeah, so functions without Borders was built to again solve
a problem that I had. I basically hate writing server
side interfaces because a lot of time gets spent in
doing that. Like whenever I have to write something, I
have to write ten httpa API. What is it called?
(27:38):
If I write it on the server side, like an
end points or yeah, I have to write a lot.
I end up having to write a lot of endpoints
and then a lot of getters on the client side.
So what this library does is it kind of abstracts
away everything and it also mixes in a lot of
(28:00):
typescript to basically make a server side ATI calls fail
like a native function call on the client side, So
it allows you to use the same typescript types between
the client and the server. So while defining your server,
(28:22):
if you're using a set of types, then you can
pass the same types to the client side also, and
then basically you can call those functions on the client
as if they were written on the client itself. But
actually the library makes a web socket call and then
(28:43):
gets the data from the server.
Speaker 2 (28:45):
Very cool.
Speaker 1 (28:45):
So it's like your own version of server side rendering.
Speaker 3 (28:49):
Yeah, I guess.
Speaker 4 (28:50):
So then where do you deploy the server code too?
Is it just like any like is it like a
Lamba city situation or where would the server code end up?
Speaker 3 (29:03):
I don't think. I mean, I haven't tried deploying it
to any server less library yet, but it's mostly about
a server full situation where you might have a server
constantly running and then the client can be anything. It
can be a browser, or it can be another server
(29:23):
or wherever you want to run it on. Basically very cool.
Speaker 1 (29:28):
So, Akash, is there anything that we haven't covered yet
that you think that you'd.
Speaker 2 (29:32):
Like to talk about?
Speaker 3 (29:33):
I don't think so. I've covered mostly everything that I'm
passionate about what I like to learn and talk about.
I guess yeah.
Speaker 2 (29:46):
Very cool.
Speaker 1 (29:47):
So if people would like to get in touch with you,
what are the best ways.
Speaker 3 (29:51):
They can reach out to me? On Twitter? At the
writing dev. They can check out my blog at the
writing dot dev where they can subscribe to my blog,
and if they reply to any of the emails, the
reply actually reaches to me directly.
Speaker 2 (30:09):
Very very cool, awesome.
Speaker 1 (30:10):
So I think this is the point in the show
where we're going to move into picks and we'll share
things that we've been using that we're fans of things.
It could be a site that you've found, a product
that you like, basically a show you've watched that you've enjoyed. So, TJ,
would you like to start us off this week?
Speaker 4 (30:29):
I can start us off yeat. So my pick for
this week is going to be kombucha. There's no page Akasha,
you have you had kimbucha before? Do you get the reference.
Speaker 1 (30:38):
I have not tried it, but I've seen it at
the grocery store.
Speaker 4 (30:42):
Okay, So I had never tried it in my life.
I didn't know yeah ferm entity, which I couldn't totally
explain exactly what it is. So I'm glad you know
more about it than I do, apparently, but the i'd
heard of it before in a fee shot near me
had it, so I was like, what the heck, let's
(31:03):
let's try it. And it was I think it started
a new obsession of mine because I just went to
the store and bought a whole bunch of it because
it's quite good. It's it's since it's tea based, it's caffeinated,
but it's got just a little bit of caffeine right.
So I've I've had a bit of a coffee problem lately,
where working from home, the coffee consumption was getting a
(31:24):
little out of control, and I've really enjoyed kombucha. The
place near me has it in a lot of different flavors.
So if you haven't tried it before, Paige, you might
want to just get some from the grocery store.
Speaker 2 (31:37):
Just to say.
Speaker 4 (31:37):
You say you've done it.
Speaker 1 (31:39):
I will definitely give that a try now that I
know somebody who is a fan of it. Is there
a particular flavor that you've liked.
Speaker 4 (31:48):
I like the fruit based ones Akasha. I don't know
if you have any. Let me see if I can
dig up exactly which one. I've Hadasha's kombucha popular in
India around you Mark Randy.
Speaker 3 (31:59):
I had kind of found it in a norveety Japanese book, So,
I mean, it's a bit expensive, but it's really tasty
at least I think the taste is quite different from regularity,
so it's fun to drink.
Speaker 4 (32:13):
Yeah, So I've had some that are like cherry based. Interestingly,
it was quite good and like like a cranberry orange
one as well that I like. So that the fruity
ones I thought worked really well. So that's that's my pick.
Speaker 2 (32:27):
Nice, I like it. I will go next. TJ.
Speaker 1 (32:30):
You've inspired me with your choice of kombucha. I will
choose a loose leaf earl gray tea that I recently
found and I've been drinking just typical tea bags of
Earl Gray probably about the past year or so. My
husband has been doing it since he was a kid,
and since I've been working from home also, and we
(32:51):
work from home together. We will now have tea at
about three o'clock and take a quick break and just
kind of check in and see how the other one's doing.
But recently we've upgraded from the tea bags to this
loose leaf version from Harney and Sons, and wow, what
a difference that day. It's It's definitely got a lot
(33:13):
of extra flavor in it. It's a little bit more
involved because you can't just dunk the bag and you
have to have a little tea strainer that you put
in your cup. But I think it's really worth it.
It's been really, really enjoyable. So that's what I would
recommend today. If we're going along the eating and drinking route.
Speaker 2 (33:34):
It's available on Amazon.
Speaker 1 (33:36):
It's not too too expensive and you can certainly get
a pretty decent amount of it for the price. So
I'm going to go with Harney and Son's Earl Gray
Tea and Akash. Do you have anything that you'd like
to share?
Speaker 3 (33:48):
Yeah, I don't have anything, especially on the eating and
drinking side, since the lockdown has stopped all of the
random things that I used to eat. But what I
would recommend is a label MIC. So I'm using one
right now, and it dramatically improves the audio quality that
(34:10):
I have in zoom calls and video calls or you know,
while just recording audio on for my YouTube channel or
anywhere else. So yeah, I would recommend having a label
MIC as a starter kit for a YouTube channel.
Speaker 2 (34:27):
I guess fantastic. That's always good.
Speaker 1 (34:30):
I think people are always looking for good microphones, good cameras,
good good, all that stuff, especially since our lives are
very video driven nowadays.
Speaker 2 (34:42):
Very cool.
Speaker 1 (34:43):
So we'll have a link to that in the show notes,
and we will have all of your links where people
can reach you, see some of your articles, check out
your website as well. So thank you so much for
joining us today. It's been really fun to talk to you.
Speaker 3 (34:57):
Thank you, guys, it's been fun talking with you also excellent.
Speaker 1 (35:01):
So we will see you next time on the React
Roundup Show By everyone,
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!