SPA + SSR (pre-rendering) use case

[ignition42]

Hello,

I am considering using Vike to build an app that targets a backend API. I like its flexibility and I think it will suit my needs. Most of the app will be under authentication, so a simple SPA would be enough. For this, I thought Vite and React would be sufficient. However, I also need static pages for documentation, product descriptions, maybe articles or other pages that will be completely public and require SEO. Therefore, I would like to use pre-rendering (SSG) for them.

I don't want a Node.js server or SSR as I already have a completely separated backend with a REST API. I would like to serve the app as a completely static HTML/CSS/JS. But when I scaffold the app with Vike or Bâti, both come with the server part (I know I can remove it). Lately, frameworks are leaning towards SSR, server components, and running a Node.js server.

I noticed that Vike has a routing system and a guard that I would like to use. Does it make sense to use React Router or Tanstack Router for the SPA? Or can I use Vike's routing system for the SPA part as well? I'm concerned about the pageContext not being available in the SPA when using the guard. Is the authentication and login flow described in the auth page compatible with my use case?

I also intend to use Tanstack Query, and I saw that for data fetching, there are the data() and useData() hooks. However, the vike-react-query readme mentions it can be used instead of the data() hook. Does that mean it's intended to be used on the server side, or can it be used for both?

So, can I, or is it advisable to use vike-react and vike-react-query plugins for my specific use case? Would it be better to end up ejecting some parts or doing a custom integration?

Thanks.

[ignition42]

I think I have solved already some of the questions.

The guard() and data() hooks are only server side, as indicated on the hooks page, though this is not mentioned on the guard and data pages. It seems that data() and useData() are not for suitable my use case. However, it would be good if guard() could be used on the client side as well, as noted in #1600.

Looks like vike routing system is compatible with SPA so in theory there is no need for React Router or Tanstack Router for the SPA. Not for parameterized-routes as noted in #1476

[brillout]

I don't want a Node.js server or SSR as I already have a completely separated backend with a REST API. I would like to serve the app as a completely static HTML/CSS/JS. But when I scaffold the app with Vike or Bâti, both come with the server part (I know I can remove it).

Good point (FYI @phonzammi @magne4000).

I noticed that Vike has a routing system and a guard that I would like to use. Does it make sense to use React Router or Tanstack Router for the SPA? Or can I use Vike's routing system for the SPA part as well? I'm concerned about the pageContext not being available in the SPA when using the guard. Is the authentication and login flow described in the auth page compatible with my use case?

See https://vike.dev/react-router. If Vike's router is blocking you in some ways then let us know. (We're aware of #1476 and working on it.)

I also intend to use Tanstack Query, and I saw that for data fetching, there are the data() and useData() hooks. However, the vike-react-query readme mentions it can be used instead of the data() hook. Does that mean it's intended to be used on the server side, or can it be used for both?

Yes. It would be nice if vike-react-query documents this (FYI @nitedani).

So, can I, or is it advisable to use vike-react and vike-react-query plugins for my specific use case? Would it be better to end up ejecting some parts or doing a custom integration?

See https://vike.dev/extension-vs-custom.

It seems that data() and useData() are not for suitable my use case.

Why?

The guard() and data() hooks are only server side, as indicated on the hooks page, though this is not mentioned on the guard and data pages. [...] However, it would be good if guard() could be used on the client side as well, as noted in #1600.

I've improved the documentation around all that: d3c2e0e~...a1906e2. Most notably, have a look at the new content at https://vike.dev/guard. Does that answer your questions? Let me know what solution you ended up with.

Looks like vike routing system is compatible with SPA so in theory there is no need for React Router or Tanstack Router for the SPA. Not for parameterized-routes as noted in #1476

FYI it's fairly high priority to implement that feature.

---

Btw. would your company be up for sponsoring? (Beyond supporting Vike, also for tight-knit support and much increased feature request prioritization.)

[ignition42]

I noticed that Vike has a routing system and a guard that I would like to use. Does it make sense to use React Router or Tanstack Router for the SPA? Or can I use Vike's routing system for the SPA part as well? I'm concerned about the pageContext not being available in the SPA when using the guard. Is the authentication and login flow described in the auth page compatible with my use case?

See https://vike.dev/react-router. If Vike's router is blocking you in some ways then let us know. (We're aware of #1476 and working on it.)

I will try to make Tanstack Router work, since it looks like React Router is going to merge with Remix. Or wouter, not sure, it looks off mixing two filesystem based routers.

It seems that data() and useData() are not for suitable my use case.

Why?

That was a mistake, sorry. At the moment of writing I thought it was only server side. Anyways, I plan to use Tanstack Query.

The guard() and data() hooks are only server side, as indicated on the hooks page, though this is not mentioned on the guard and data pages. [...] However, it would be good if guard() could be used on the client side as well, as noted in #1600.

I've improved the documentation around all that: d3c2e0e~...a1906e2. Most notably, have a look at the new content at https://vike.dev/guard. Does that answer your questions? Let me know what solution you ended up with.

Thanks, now is definitely clearer.

Btw. would your company be up for sponsoring? (Beyond supporting Vike, also for tight-knit support and much increased feature request prioritization.)

We barely use Vike at this moment, we are still in a exploratory phase. But as soon as we finally consolidate the decision we'll consider it.