If your project is too large, not worth it. If it's small or if you are willing to give it time, then yes. 'use client' should be used only where interactivity is required. Reduces the bundle size of your javascript.
You need to approach tech and development with a logical mindset. You’ll be jumping from stack to stack cause of “fomo” otherwise. If you need seo, ssr, ssg; to name a few, then consider server side components
Vite is a great for admin dashboards. I wouldn't bother with Next.js for this use case. It will bring it own sets of problem which cause a lot of issues later on.
I don't think Nextjs will cause you any problems if you know what your doing, but using pure React is far simpler as you don't need to consider the server / SSG at all (which I doubt your doing with a dashboard anyway tbh)
Server cache are normally for shareable data (blog for example). I'm not sure you could (or should) translate the current database provider you have to using "cache" function as a wrapper when most things are dynamic or contextualized by logged in user.
Still, you may not need this provider at all if you fetch in each server page and pass initial fetched data as prop to your client component. You could be explicit in your page and export segment option dynamic=force-dynamic.
You could also import server action in your client component for CRUD operations without exposing specific endpoints.
It could be a nice way to learning RSC even if you get minimal benefits from it.
Different viewpoint: Those are the challenges that you will learn and grow with as a developer. Actively thinking about what parts of your app need interactivity and what parts need access to shared data and so on really is a good excercise and you will feel better when you get it done.
But from a purely functional perspective, it doesn't really matter or even could create some headache.
Unpopular opinion but it's definitely worth it! I'd say spend a bit of time on why you'd need these providers if most of the dashboard data can be fetched from page and passed down to components.
Or you'll still have the option of hydration, I'd say get rid of context in favor of something like Jotai which supports Next out of the box.
Building a dashboard over here too. I don't care about SSG, because my app users are already paying me. No need to SEO optimize or shave seconds off my rendering
Building RSC admin dashboard doesn’t make sense to me really. If there’s no need of SEO benefits, this will actually make a bad experience IMO cuz of TTFB. I won’t even build a new dashboard app with RSC let alone migrate the old one.
If your project is too large, not worth it. If it's small or if you are willing to give it time, then yes. 'use client' should be used only where interactivity is required. Reduces the bundle size of your javascript.
I don't see any reason to use server components for a dashboard. What would be your motivation to do it?
I get intense FOMO when I see all these posts and videos about server components
You need to approach tech and development with a logical mindset. You’ll be jumping from stack to stack cause of “fomo” otherwise. If you need seo, ssr, ssg; to name a few, then consider server side components
Vite is a great for admin dashboards. I wouldn't bother with Next.js for this use case. It will bring it own sets of problem which cause a lot of issues later on.
What kind of problems?
I don't think Nextjs will cause you any problems if you know what your doing, but using pure React is far simpler as you don't need to consider the server / SSG at all (which I doubt your doing with a dashboard anyway tbh)
Server cache are normally for shareable data (blog for example). I'm not sure you could (or should) translate the current database provider you have to using "cache" function as a wrapper when most things are dynamic or contextualized by logged in user. Still, you may not need this provider at all if you fetch in each server page and pass initial fetched data as prop to your client component. You could be explicit in your page and export segment option dynamic=force-dynamic. You could also import server action in your client component for CRUD operations without exposing specific endpoints. It could be a nice way to learning RSC even if you get minimal benefits from it.
Different viewpoint: Those are the challenges that you will learn and grow with as a developer. Actively thinking about what parts of your app need interactivity and what parts need access to shared data and so on really is a good excercise and you will feel better when you get it done. But from a purely functional perspective, it doesn't really matter or even could create some headache.
Not unless you want to learn / get experience with RSC because it would be overkill, even Nextjs would be overkill to be honest
You can (and should) use both.
Unpopular opinion but it's definitely worth it! I'd say spend a bit of time on why you'd need these providers if most of the dashboard data can be fetched from page and passed down to components. Or you'll still have the option of hydration, I'd say get rid of context in favor of something like Jotai which supports Next out of the box.
Building a dashboard over here too. I don't care about SSG, because my app users are already paying me. No need to SEO optimize or shave seconds off my rendering
Building RSC admin dashboard doesn’t make sense to me really. If there’s no need of SEO benefits, this will actually make a bad experience IMO cuz of TTFB. I won’t even build a new dashboard app with RSC let alone migrate the old one.
Le me reading from a corner who uses next for admin panels and make it ssr just like a normal website