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.

Hey, everyone. Welcome to another episode of React Roundup. I am your host today, Paige Niedringhaus, and I am joined by our panelist TJ Van Told. 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, what we're gonna talk about today? Hey, guys. So my name is Akash, and I think the 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 vCodeCamp 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 HTML, CSS, JavaScript, and Bootstrap, 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 technique 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 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 learned, and, I guess I mean, you could call it teaching, 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 HackerNoon and publications like that? Yeah. Go for it. Yeah. So I kinda 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 I started with learning Node. Js and then contributing to a few open source repositories on GitHub. And as I learned new things while learning Node.

Js, 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 kinda 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 2 or 3 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 React.

So I used to reach out to various publications like CSS Trex, Odd 0, 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 Node. 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 2018, like, the end of 2018, I think.

So, yeah, that's how it got started. Oh, 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 cover in that and any advice you have to people because it's structuring React projects is not a small topic.

Right? There's lots of opinions around that. So I'm I'm curious what advice you have there. Right. Right.

Definitely. So, structuring React projects is one of the more recent articles that I have written, and I think it got more eyeballs on it, especially especially because it's such a polarizing topic. Everyone kinda 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 UIs which were, 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 what 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 is.

Yeah. So one of the first things is is that to not clutter the root folder of the project. It's helpful to have all of your files sep 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 JS has a, like, 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.

And but I don't recommend having any UI components of the code itself stored inside of these pages, but having separate component as having a separate component folder, and then naming these folders according to the page or the set the set of pages where these components will be used, and then storing these components inside these, named folder structures. And then I talk about about things like, data adapters and context stores. So data adapters will be adapters, like, in the adapter project adapter pattern of writing code where, these would just be functions which you will call, and then the adapter in its own back end would then make any API call or any well sorted call or any anything like that, and then return the data in whatever format that the original colleague 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, projects, but for more complex projects where, generally, people end up using our data management library like React, React Context or Redux, then, generally, these context folders can hold the context stores for these, for these set of pages.

And, yeah, that's what I recommend there. And the rest of the article then just talks about how you can throw your styles and public assets. So I'm curious just because I haven't done much with Next. Js. How much does Next enforce?

Because you said the pages folder is like a built in Next. Js thing. Does 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 2 things, which Next. Js 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 were all the rest of the folders were something that I enforced myself or that I made up myself, I guess. Yeah. Gotcha. So it sounds like you're because, usually, I find that most folder structure, there there's almost like 2 different paths people take. Either you group your stuff by your files by their type of file, like their components, their adapters, their whatever the case is, or you group by feature.

Like, you have a folder that this is my, I don't know, my 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 feature. But I've heard more I mean, I've heard the counterargument that my folder structure actually goes counter to having your having storing 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 they recommend not having folders like that because they'll tell you to do things like just just note name by by features. But that like, I 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 have nested features, and then you'll need to refactor them out of it. And I don't I don't think there's a clean answer to this. I but I always find it interesting what people, come up with for best practices.

I don't know, Paige, what you do at the Home Depot if you have a folder structure that you've magically solved solved this problem with at all. I don't think that we have that at all. But the 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 for components, which are the smaller pieces of a React application, like buttons, inputs, maybe even something as as large as a table. And then we we have containers, which are kind of the, I guess, the pages, quote unquote, that a Next.

Js project might contain. So it's things like our whole nav bar or the 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 it follows the Java pattern a little bit because most of our back end services are built using Java, and Java is very prescriptive in how it wants things done.

So we we lean on that a bit, but React is so unopinionated about it that, really, however it works for you is probably a pretty decent way to kind of build your application, I think. Yeah. Kash, I think that's why your article gets so much attention is because no one's no one's really solved this, and people like hearing others' opinions on the issue. Oh, yeah. It's a great opportunity to just see how other people are approaching it.

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 know 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 Kasparser and also a link to Product Hunt.

So can you tell us a little bit about what you're doing there? Yeah. So Kasparser is a kind of Fintech micro startup that I am running with a friend of mine. So he it's basically his brainchild, and I provide all of the front end help that he needs in going through that. So cash 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 gen stored in that cash 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 Parcel 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 bot 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 of a place of work that they wanted to work at or something like that. And so I had to take that board 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, basically.

Yeah. That's very nice of you to share that kind of software because that sounds really useful for different things. With SiteSeer, were you would you just ping, like, configurable amount to, like, ping 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 do 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 try 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 optimization, 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 will 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, but recording can be fun sometimes. I can totally relate to that. That's what I do. Nice. I I can definitely relate to that.

Not the whole monetizing thing, but the the second something goes from being just kind of like a hobby project to an 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 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. Yep. Well, that's cool. So what kind of day to day things do you get to use for your work with your 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 automate away most of my workflow. And then it's fine 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 React and TypeScript.

And I hope to learn Rust soon. I've heard a lot of people who seem to be JavaScript developers kind of gravitating towards Rust. What 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 Rust, I, like most university students, have, of course, learned c and c 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 online, But, more experienced Rust developer would probably, give the be able to give this answer better. But, yeah, that was my opinion on this.

It's funny, Paige. You're right. I 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 gonna be interesting to see how that changes over time. Maybe I'll have to learn it too. I know. I I I hear this kind of stuff pretty regularly.

It's like, Rust, go. But I guess my problem is a time management one where I I use Java and I use React mostly for my job. And so that's what most of my time goes towards is those 2 programming languages. I 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 the your like, a lot of these side projects came out of actual problems you had or things that you you wanted to do, which is always interesting to see.

Because at least for me, and I don't know about YouTube, but I can't just sit down and say, like, well, I'm gonna learn Erlang today. Right? Like, if I do that, like, there's no amount of focus in the world that's gonna get me to to to learn Erlang. But if I had, like, some problem that I needed to solve in my life or for my job, then, 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 3 2 or 3 chapters of a 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 it, I think. Actually, Akash, I'm curious because you said that you had kind of liked the functional style of programming. And I'm curious. Did does that come from, like, work experience or school? Because I I say this as someone that functional has never totally clicked for me and maybe, like because like Paige, I came from a Java background, and Java is very much not I mean, there's you can kinda do some functional things, but it's very much not a functional language, really.

So I struggle 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 object oriented programming. Yeah.

But where I initially started picking up functional programming was, again, when I was reading Hacker 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 composability 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 c, you end up writing code which you don't understand what it does.

Like, at least I used to because I couldn't write c 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. I'm I'm not sure of the exact terminology here.

But That makes sense. Yeah. I think I think we get it kind of the separation of concerns is what you're and encapsulation, I guess. Right. But I guess I mean, these two terms are generally used for object oriented programming too.

So yeah. Yeah. I feel like functional programming is like a cult that I haven't gotten an invite into because everybody like, I I feel like once you've drank the functional Kool Aid, like, you can't stop talking about it, and you you start recommending Haskell to your coworkers and, like, you 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 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 it's very big and functional.

And I 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, Akash, another thing you've got you have on your GitHub. I would definitely not put myself into the, like, leagues of great functional programmers because a monad is something which I can still not explain. And, 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 to bring up is you have this project called functions without borders. Maybe you could tell us a little bit about what this is and 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, 10 HTTP API. What is it called if I write it on the server side?

Like, an end end point? Or it's Yeah. Yeah. I have to write a lot I I end up having to write a lot of end points 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 API calls feel 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 they were written on the client itself. But, actually, the library makes a WebSocket 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. So then where do you deploy the the server code to? Is it just like any, like, is it like a Lambda situation? Or where where would the server code end up?

I don't think I mean, I haven't tried deploying it to any serverless 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 whatever 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. It don't I've covered, mostly everything that I'm passionate about and, 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, it, 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 pics, We'll share things that we've been using that we're fans of, things that 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. Yeah. So my pick for this week is gonna be kombucha.

I don't know. Paige, Akash, have you have you had kombucha before? Do you get the reference? I have not tried it, but I've seen it at the grocery stores. Okay.

So I had never tried it in my life. I didn't know it was fermented tea. Right? Yeah. Fermented tea, and which I couldn't totally explain exactly what it is.

So I'm glad you're you know more about it than I do, apparently. But the I I'd heard of it before, and a coffee shop near me had it. So I was like, what the heck? Let's let's try it. And it was I 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, you know, 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 in a lot of different flavors.

So if you haven't tried it before, Paige, you might wanna just get some from the grocery store just to say you've say you've done it. I will definitely give that a try now that I I know somebody who is a fan of it. Is there a particular flavor that you've liked? I like the fruit based ones. Akash, I don't know if you have any.

Let me see if I can dig up exactly which one I've had. Akash, is kombucha popular in India around you? Not really. I had kind of found it in a novelty Japanese store. 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 that was that was quite good, and, like, like, a cranberry orange one as well that I like. So the 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 grey tea that I recently found.

And I've been drinking just typical tea bags of earl grey 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 3 o'clock and take a a quick break and just kinda check-in and see how the other one's doing. But recently, we've we've upgraded from the tea bags to this loose leaf version from Harney and Sons, And, wow, what a difference. 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 in. 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 a pretty decent amount of it for the price. So I'm gonna go with Harney and Sons earl grey tea. And, Akash, do you have anything that you'd like to share? Yeah. I don't have anything as especially on the eating and drinking side since the lockdown has topped all of the, like, random things that I used to eat.

But, what I would recommend is a label mic. So I'm using 1 right now, and it dramatically improves the audio quality that I have in Zoom calls, in video calls, or, you know, while just recording audio on for for my YouTube channel or anywhere else. So, yeah, I would recommend having a label, like, as a starter kit to 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. Bye, everyone.