aha, although it works, Dan Abramov himself probably realises, how ugly that is. New react won't need that at all :D Ban use effect entirely

Last issue is not using typescript

im confused about the usage of !!, i understand it does a double negation and converts to boolen, but why concert to boolean if the value is falsy anyway?

❤ Thank you, I learned a lot

100% do more refactoring videos, these are rare and idk if it's specifically your unique idea to do this, but this is actually gold content

I wish I saw this YEARS ago, that was awesome and insightful

bro don't be so serious when you record a vid :D you look like ur about to get killed

Keep going 🎉

WTF is with the bot comments?

bitflag, where?

From reading the comments, it seems like Clean Architecture is not well received in the React community. Coming from Flutter, this is a very standard approach when building medium-large app. I'm currently learning NextJS and my first thought was, how can I apply Clean Architecture to it... But to be honest, it is simpler in Dart to manage DTOs and other stuff because I'm more used to classes than JS objects. But it is probably a matter of time to get used to it and find a way to translate my Dart architecture to Typescript.

can you attach github repo for this project

Wow this video was actually amazing, that's wild!

Great video! Keep making them

can't wait for the react query video!

I thin kyou talk too fast makes it harder to comprehend what youre saying. Otherwise great tips

Finally, someone who understands architecture on the front-end 🥲 There are way too many small and mid-sized firms whose front-end is wholly coupled to their data architecture, and managing adapters throughout their applications consumes 99% of their front-end efforts. You try your best to implement clean architecture, but managers and directors simply aren't used to seeing it on the front-end, so they just can't wrap their heads around the idea of investing any time at all into what seems like unnecessary "reorganization" to them. Oh, how they love to reorg a team though, but that's another rap. I'll tell you why people think this is weird: sexism. The front-end is seen as "girly". As a woman whose worked both in AI and as a web developer, the latter is so, so, so much harder...but no one will believe me because the front-end is "basically just design". I've seen statistics corroborating that female developers are disproportionately given front-end work because it's seen as "light", but I've lost the source. It's also important to note that this is a spectrum that affects everyone. Tech does not tolerate, much less reward, any kind of femme behavior, from women or men, regardless of value even to the bottom line. What most don't realize about a highly customized and sophisticated front-end is that it isn't "basically just design", rather it's closer to engineering a *design tool* like Photoshop. My academic background is in mathematics and theoretical computer science, and I was drawn to the front-end because it can be very math heavy. Again, remember that most pre-digital "computers" were women, and even Einstein's personal calculations were often carried out by his wife. All of this careful and meticulous calculation is still seen as trivial and "light" though, despite being necessary machinery. Despite Einstein himself saying this work was necessary for him to complete his theories, folks online will still argue with you otherwise that he could have produced the same results with anyone. Women in science and computing are treated as *fungible* resources. As a result of this perceived fungibility, managers and directors truly *can't imagine* spending the time to keep these workers' workspaces in order. Since we're primarily handed front-end work as femmes, the idea of giving our workspace a clean architecture is dismissed as a waste of time. Women (and femmes generally) have always had to work in filth and slop. Of course, this perception hurts all engineers regardless of gender, which is just one example of how Patriarchy is damaging to everyone and everything. This even includes productivity and ultimately profitability.

thank you sir a suggestion tho could you please zoom in

A lot of people in the comments are saying DTO doesn't make sense on frontend. I think the strengths become more apparent when you bring full-stack in frameworks like Next.js. You can consume data from multiple different services and bring it together in a nice clean package to send to the frontend using something like tRPC. Also, this is useful for data security. Since you are explicitly defining what gets sent to the frontend, you are protecting sensitive information from making it through the transfer layer

I use tRPC which seems to accomplish a lot of this automatically. What are your thoughts on tRPC?

I dont agree that this is a good pattern for the frontend. This is a nightmare for debugging. And when multiple components expect the same object from the server for different rendering ways it will break differently in different places. We dont want that. We can solve the main issue here by simply by grouping the marshalling functions near the consumers in something like a util file specific to that component. There is no more nested lookups and other issues. This will not complicate the codebase since there is no extra thing to remember and typescript will help us with the structural issues anyway

Loved this kind of video!

You could’ve simply used Zod. Using a schema inside your API layer makes possible doing “transform” after parsing data. This way you write all data transformations at once

You could’ve simply used Zod. Using a schema inside your API layer makes possible doing “transform” after parsing data. This way you write all data transformations at once

I think this makes sense to me since I had a situation where I used similar approach. We had a frontend app that received a huge json response with 100s of fields to render a product offer. So instead of directly using its field throughout the app, I created a transformation file which maps it according to what makes sense in the app. Advantages: - If there is a change in backend api, I just need to update the transformation file in most cases - I can rename things/restructure the json to what makes sense to me and the frontend app instead of relying on backend developers naming/structuring We event had a huge change in backend api which caused the entire json response to change but because I had used the transformation function, it saved me hours of work since I had to mostly change that file to integrate with the updated api.

nobody use dto in Frontend codebase.

Cleaner architecture by what standards? This is applying wrong solutions to problems that do not exist. Instead of trying to force these patterns into your codebase, understand what kind of real problems these patterns are solving so you can apply them correctly.

If you have a list of Users for a getAllUsers method That would meen that dtoToUsers will do a for loop over each user object to have the good format right ? It could slow down your application if you have a lot of users in your json server response

Another weird-looking JS dev. Is it obligatory for senior JS devs to have a mustache and weird hairdo?

I'm still not sold on this one. DTOs are not a pattern for react, they're a pattern for server code within OOP. To me all of this seems really unnecessary when you could just define a custom user type and only use the values you really need from the server. These values are now directly linked to the server values and can be modified at any point of time, without affecting the rest of the application. You could have a simple user object that doesn't follow the API structure but links to different values in the API. like, userId: apiResponse.id, followers: apiResponse.relationships.followers. There's no need to complicate the code.

Thank you Profy! I am crossing each one of these hurdles just as you release a new video

Kinda stupid. What if it's the other way around and user data now has to be under the attributes property. Goes back to square 1 where you need to change 90% of the frontend code

should there not be a service layer that handles business logic in between the component and Api layer? Component -> service -> api?

React coupled structure with javascript, and it was great, then came tailwind and coupled styling with react, and it was great, ... came and coupled APIs with react tailwind... and it was fucking great.

this is really some professional coding advice. helps a lot in real world applications unlike the most beginner friendly tutorials on youtube

Very helpful tutorial, can u share names of any good tools that automates the dto type generation , if u have used any before , thanks

quite weird using dto in frontend

I really enjoy these videos! As a relatively new React developer who values a clean codebase, I find them incredibly helpful. I have a question about crafting a clean API layer i hope your could answer. Imagine an API returns rate-limiting info in the response headers. When the rate limit reaches a certain threshold, we want to inform the user before they hit the limit. The components consuming the API response do not care about the rate limit info. What would be a good pattern to implement this as a “middleware” between the API layer and component consumers, ensuring the components remain unaware of the rate-limiting logic? When the threshold is reached, we want to trigger a side effect on the client from the server to display the notification.

One question , the thing where you replace the for loop for counting elements that have the status open with a filtered array ( arr.filter().length ) just to have it just "pretty" impact the memory usage ? U don't just iterate thought the the array that you have , u create a new array so , allocating more memory .Maybe a middle ground can be a reducer :D

Amazing video ! May I ask when is it appropriate to use a map vs an array?

I feel bad I just don’t understand

I love these kinds of videos! Great stuff!

You hooked me as your subscriber. congratulations 🎉

Great video! I would love to see more of these

This is wonderful, this kind of content is very helpful

I subbed, hoping to see more refactoring videos!!

thank you very much for the video

This is awesome. The frontend community needs more resources like this. Subscribed +1 Thank you.

Mmmore of. This please

You can just use Set instead of Map, cause you only set value for the key to true.