How to structure pages and components for a simple web app using t3 stack?
I am new to front-end development and I am using the t3 stack to create a simple web app for our customers to view their data. The homepage of the app consists of a login screen and once logged in, the user is taken to their dashboard. Currently, the dashboard has two pages: "My Lines" and "Billing".
My question is: how should I structure the pages and components directories? I was thinking of creating a dashboard page with a header and a sidebar, which will render the other pages for the user. Specifically, my folder structure would look like this:
Is this the correct approach or should I redirect the user from the dashboard to other pages? I am concerned about having to deal with the layout of the header and sidebar for each separate page. Additionally, more pages might be added in the future.
What is the best approach to building such an app?
5 Replies
If you want a shared layout between pages you can define a component with your header/sider that passes its
children prop somewhere in the middle. Then just use that component to wrap any content you want.
Other than that the routes are whatever pages you want. If /dashboard by its self isnt a valid route, only /dashboard/myLines and /dashboard/billing, you dont need a index.tsx in the dashboard directory,i like something along the lines of:
imo when you're not sure whether something should be a new page or not, the two things you should ask yourself are:
- do you want someone to be able to navigate there by url?
- do you want the back button to work?
if in doubt, err on the side of making a page
Thanks guys you've helped a ton!
Thank you, @cje, for being so helpful and dedicated to assisting others here. Your efforts are truly appreciated!
I am working on structuring my app and I am having trouble deciding where each component should go. I have drawn a sketch to help visualize the structure, but I am still confused about a few things.
Firstly, I am unsure about how specific a component should be. For example, should the header be just one component or should it be broken down into smaller components?
Secondly, in my original implementation, I had the filter tabs, search bar, table, and pagination all in the same component because they are all connected to managing the data the user sees. Is this a good approach or should I break them down into separate components?
Any advice on how to structure these components in a way that makes sense for the app would be greatly appreciated.
@Mendy there are a lot of ways you can slice this, and i've heard people say things like "header components are dumb because you only need to use them once, so why make a reusable component when you can just make the header in layout.tsx?", but you might find it clearer to make a header component just so you know where all your header logic lives and so it doesn't clutter the rest of your layout.tsx (this is my preference).
personally i also like to structure my apps in such a way where any calls to the backend are done in the files in the pages/ directory, then when the data is fetched it's passed into a component that constitutes most of the actual page content and lives in the components/ directory. I don't really like making API calls from within components as it's annoying to handle loading states etc that deep in the component tree.
in terms of tables, pagination etc it depends on the amount of data your table is displaying. if it's not a huge amount of data, it might be appropriate to pull the entire db query you plan to display in one go and then handle pagination on the table level. As your data grows, it's more likely you'd want to grab a batch of the data and fetch more from the db as you paginate. it's still good to have more data pulled at any given time than you actually need to display so the user doesn't need to wait for data to come from the db on every pagination change.
ultimately a lot of this comes down to preference and the design that's appropriate for your app. you might not need the most performant, optimized approach on your first build - I'd recommend just building as much as you can and rebuilding later, because you might find that some of your initial assumptions were entirely wrong (in this case, maybe you'll decide that tables overall are the wrong way to display the data - not saying it is, but anything could happen). building the thing shows you what you don't know.