Replacing Context with Data Access Layer
Hi! I'm a dev with 6-7 months of React/Next experience. I'm working on a small B2B SaaS app where users can be part of multiple teams. Each team in turn can have multiple projects.
I recently read this article by the Next.js team: https://nextjs.org/blog/security-nextjs-server-components-actions. I realized I was doing a lot on the client side, and I decided to move as much as I could to the server-side, to adhere to the recommended Data Access Later approach and using Data Transfer Objects to clean, verify access, and pass data to the client side. This is the pattern I'm trying to implement:
"server-only" components: fetch, verify, clean, and return data as DTOs --> server components (page.tsx mostly): fetch DTOs based on current user's id or route slug, and pass data to client as props --> client components: render ui based on data passed as props, and add interactivity
For dynamic routes like
/dashboard/teams/[slug] I have no problem grasping how to do it. I just use the slug to get the relevant data and verify user access. But for routes like /dashboard/home where I want to display a grid of cards for a users projects in a specific team I'm not sure.
I have been using useContext to keep track off and serve the relevant data based on which team the user has as their currently selected team (there's a team selector drop down client component in the sidebar/navbar), but I would like to not rely on context if I can to keep as much as I can on the server-side.
ASK: If anyone have any tips on how to easily track and access which team is the users currently selected team, without using context, I would really appreciate it.
P.S. I have not yet pushed any update to prod, after trying to make this transition, so the "old" version can be found here: https://github.com/NilsWestgardh/briefbuddy
Thanks!
NilsGitHub
GitHub - NilsWestgardh/briefbuddy: BriefBuddy uses AI to turn marke...
BriefBuddy uses AI to turn marketing briefs into campaign ideas in minutes, not days. - NilsWestgardh/briefbuddy
7 Replies
Hey Nils. There are multiple multiple ways to solve this.
First of all, even if you want to do as much on server as possible, there is nothing wrong with handling some of the data client side. But there are other options.
1. Put the team id into the url. So the url would be like
/[activeTeam]/home. I tried to open the app so I can see what's exactly is going on, but there are some errors and I can't actually create team. But if /home is same on every url, you can still render the same component on every /[activeTeam]/home.
2. Save last visited team for each user to db. This way you can call some server action like getLastVisitedTeam and you'll get the data you need. And when user switches the team using the dropdown, you can save the new team using something like visitTeam. I don't know if this is a right approach for you tho, because it seems like the team selection affects a lot of content.
Also, please take a look at trpc if you haven't already. It could simplify a lot of what you're doing.First set up a default rendered page, then use mutations to update the currently selected team and fetch the corresponding data from the database. Additionally, set up loading components and Suspense for better user experience.
Hi @Juraj98 thanks for the quick reply, and suggestions! I'm using Supabase for my db and auth together with Next.js 14 app router. Do you think tRPC is the way to go?
Yes. I'm currently using supabase for my db with trpc. Trpc is just a very handy way to define your communication between FE and BE. You write your BE functions(procedures) and it automatically infers all the types for api function you call on FE.
Great, I'll look into it! Thanks!
Setup can be a bit daunting, but take a look at create-t3-app. You can create empty t3 app with trpc, and just steal code from there. Or go other way, and copy your code into t3 app.
Cool, I think I'm gonna watch a few YT vids, read the docs, then install t3 and check it out / play with it. 🙂