Path To A Clean(er) React Architecture - API Layer & Data Transformations

Step 3 in the architecture cleanup:
Move transformations of API data to a shared API layer. This hides the complexity of the response data structures decoupling API and UI code.
Here’s the blog post including a course waitlist: profy.dev/article/react-archi...

[@panchcw]

Really helpfull On RUclips there are a lot of tutorials about basic stuff but these are the real gems.keep it up

[@bryant3060]

I am having the exact same problems currently in my app! Thank you for this series!

[@sayedaliaqamousavi9064]

I was looking for such kind of videos. Thanks, alot.

[@gauravrawat7175]

keep these videos coming, really helpful. lots of love.

[@abbaskareem5281]

I hope you make a video on pagination with limit&offset and filters (query params)

[@BRP-Moto-Tips]

depending on what youre building you might want to extract that logic into a hook, i usually work with dashboards and its great because each table has it own hook instance with different config props and it all falls into place nicely

[@user-yz2mv8kn4x]

found these refactoring videos extremely helpful and insightful. thank you so much. 🙏

[@profydev]

Thanks a lot for the feedback. More videos to come :)

[@milad8436]

Very helpful. Thank you

[@bonedfps]

Hello there, I just came across your video on my youtube homepage.
First up: nice video and great sound quality! Tho, I think the separation of concerns, that you are basically talking about, is great, it becomes increasingly harder when working with server components. Moving your data logic to a separate function is the right choice, but error handling is still pain, even if one goes after what you suggest. It still requires either catch callbacks or an error state field to be used, which in turn makes the code unclean again like it was from the get go.
What is your opinion or way of working on that?

[@profydev]

That's a good question. I don't have a lot of experience with server components yet. Do you mean in the context of Next.js? Would be awesome if you could send some example code or a GitHub repository

[@bonedfps]

@@profydev Hey, yeah I meant in the context of Next, tho unfortunately the projects im working on are all closed source, so I can't share anything.
What is common tho is to return an object in a server action, that represents the current state, e.g. "error" or "success", with the appropriate response data. In the frontend we'd have to check for that state in ugly ways, which is what I meant with that, in the end, it all becomes unclean again.

[@gustavoeklund]

I just came from RUclips home and these videos caused me a disease: I die if you stop posting them

[@gamingxsvssdeva4245]

can you attach github repo for this project

[@realTalhaMeer]

As per your implementation, you only return the data, that is being used in that component, what if an API is being used in two different components. Please explain or create a video on it.
Thanks

[@profydev]

Actually the fetch function returns all the data from the endpoint but simply transforms it to isolate the components from the exact response data structures. Maybe this will become clearer in the next video where we introduce shared domain models

[@realTalhaMeer]

make some clarity. it would be better if you address this part in the upcoming videos.

[@NoName-bu5cj]

wouldn't it be better to return a more generic object from api? say you decided you don't want your users to shout. you want them to whisper. you'll have to change the code inside both the component and the api. you could instead return a generic `data` property and inside the component name it whatever you want:
```js
const { data: shouts } = API.getShouts()
```

[@profydev]

I think if the underlying entity changes you have to adjust a large chunk of the codebase anyway. But good point about the naming. It’s kind of like Twitter became X and Tweets became Posts, right? I’m wondering how many references to "tweet" are in the X/Twitter codebase 😂