Hey, everyone, Welcome to another episode of React Roundup. I am your host today, Paige Needringhouse, and I am joined by our panelist TJ.
Vantold.
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.
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 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.
That's awesome.
So what kind of complex things are you learning about that you're trying to help others get better at?
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 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.
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.
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?
Yeah?
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 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 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.
That's fantastic.
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 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.
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.
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 got started. Cool.
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.
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 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 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 the project structure is?
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.
On it it is.
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 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 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 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 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
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 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 the rest of the article then just talks about how you can store your styles and public assets.
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.
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, that I made up myself. I guess, yeah, gotcha.
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 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.
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 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.
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 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 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.
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 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 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 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.
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.
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.
Totally.
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.
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 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 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
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, 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 try to get some other users for it.
Yeah, that's very nice of you to share that kind of software because that sounds really useful for different.
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.
Yeah, yeah, that's exactly what it used to do.
Very cool.
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.
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 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 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 video is not fun. Recording can be fun.
Sometimes I can totally relate to that.
That's what I do.
Nice.
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.
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.
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?
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
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 work with reacting typeescript, and I hope to learn rest soon.
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?
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 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 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 able to give this answer better. But yeah, that was my opinion on this.
It's funny page.
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 to be interesting to see how that changes over time. Maybe I'll have to learn it too.
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. I've used Python a little bit. I'd like to learn Go, I think, because I've heard really good things about it.
But it's there's just so.
Many languages and so little time to learn them and then apply them, I guess, is the main thing.
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, 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.
Absolutely.
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.
So yeah, you definitely have to have.
Something that you're trying to solve, not just trying to learn for the fun of I think.
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 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.
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 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 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 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 into its own concern kind of yes, And I'm not sure if the exact terminology here.
Yeah, that makes sense.
Yeah, I think I think we get kind of the separation of concerns is what you're an encapsulation, I guess.
But I guess. I mean these two terms are generally used for dictorian in the programming do so yeah.
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, 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.
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.
Still, yep, exactly.
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.
So cash another thing you've got you have and your.
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, 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.
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.
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? 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 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, 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 gets the data from the server.
Very cool.
So it's like your own version of server side rendering.
Yeah, I guess.
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?
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 or wherever you want to run it on. Basically very cool.
So, Akash, is there anything that we haven't covered yet that you think that you'd.
Like to talk about?
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.
Very cool.
So if people would like to get in touch with you, what are the best ways.
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.
Very very cool, awesome.
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?
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.
I have not tried it, but I've seen it at the grocery store.
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 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 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.
Just to say.
You say you've done it.
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.
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.
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.
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.
Nice, I like it. I will go next. TJ.
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 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 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.
It's available on Amazon.
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?
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 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.
I guess fantastic. That's always good.
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.
Very cool.
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.
Thank you, guys, it's been fun talking with you also excellent.
So we will see you next time on the React Roundup Show By everyone,