Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out our plan for RSC / SSR / SSG, also SEO #911

Open
Martinsos opened this issue Dec 23, 2022 · 17 comments
Open

Figure out our plan for RSC / SSR / SSG, also SEO #911

Martinsos opened this issue Dec 23, 2022 · 17 comments

Comments

@Martinsos
Copy link
Member

Martinsos commented Dec 23, 2022

Things to explore:

NOTE: In the meantime, till we have more "official" support, to get meta tags per page, which is important for SEO, good potential solution is to use https://github.com/staylor/react-helmet-async .

EDIT: Big movement toward RSC, we should look at those in more details, see how we can support it and what it means in this whole picture.

@leoschet
Copy link

Hi there, any preview or update on this?

@Martinsos
Copy link
Member Author

Hi there, any preview or update on this?

Not yet @leoschet , we have been prioritizing some other features lately!

How important is this for you, what are you needing SSR for?

@leoschet
Copy link

leoschet commented Mar 19, 2024

I would like it for SEO. No urgency per se.

Perhaps this is a repeated question, but as I understand React natively supports server components. Can we use it with wasp? Or is this exactly what this ticket is about?

@Martinsos
Copy link
Member Author

I would like it for SEO. No urgency per se.

Perhaps this is a repeated question, but as I understand React natively supports server components. Can we use it with wasp? Or is this exactly what this ticket is about?

This is kind of what this ticket is somewhat about -> investigating how we are going to approach SSR / RSC / SSG and other stuff in Wasp. It wasn't super important so far, but we will want to address it at some point!

@Martinsos
Copy link
Member Author

Note to self: while SSR is good for SEO, we can also get very good SEO without actually doing SSR, but just allowing users to set meta tags per pages.

@Martinsos
Copy link
Member Author

@Martinsos
Copy link
Member Author

Related to #1910 .

@Martinsos Martinsos changed the title Figure out our plan for SSR / SSG Figure out our plan for SSR / SSG, also SEO Mar 20, 2024
@Martinsos
Copy link
Member Author

We might want to look into using https://vike.dev/, seems like potentially a good solution to build upon!

@jswizard09
Copy link

jswizard09 commented May 2, 2024

Hi
I recently came across the wasp ecosystem and the open-saas product, I do really like what team was building.
........................................
I am working on a project with open-saas and I am at a point where SSR is important for the project, I understand that team is still working on it, wondering if there an options I could write custom handling of the rendering with the express server
until a supported version is released

@Martinsos
Copy link
Member Author

@jswizard09 thanks for the kind words!

What exactly do you mean by "custom handling of the rendering with the express server"? How would you go about that, can you share more details? What are you trying to achieve?

@AdnanHussainTurki
Copy link

@jswizard09 thanks for the kind words!

What exactly do you mean by "custom handling of the rendering with the express server"? How would you go about that, can you share more details? What are you trying to achieve?

Hi @Martinsos,

Thanks for your team efforts in this project, it's been a fun-ride using wasp-lang to quickly develop cool apps.

Similar to @jswizard09, I myself stuck on the SEO/Meta-tags per page/SSR issue which we do not support here at the moment.

I was wondering if we can modify the build process which may inject our custom meta-tags for each page. I know it would require different HTML page for each wasp 'page', which may be in conflict with the current philosophy of the project.

Love to know your thoughts!

@Martinsos
Copy link
Member Author

@AdnanHussainTurki thanks for the comment, that makes perfect sense!

So the plan is to introduce SSR as an option, but we haven't started working on it yet -> it is among one of the things we will be looking to tackle quite soon for sure though, so likely in the next half a year.

There is no way to "hack" SSR in the meantime in Wasp, in the sense that you can tell the server how to render a component server-side.

What you can do in the meantime though is use something like https://github.com/staylor/react-helmet-async -> it will allow you to define in your React component, that you are using for a specific Page, how to set meta tags, so they will be picked up by the SEO, which is already a big deal.
We will also be looking to possibly offer a bit more streamlined support for this, but react-helmet is actually a pretty simple / neat solution, so should do the job well here!

@karlhorky
Copy link

karlhorky commented Jun 12, 2024

Maybe "React Server Components" and "RSC" should be added to the original issue description?

Because it seems like the canonical way that React frameworks are moving forward in this space:

  • Next.js with App Router
  • upcoming React Router/Remix implementation
  • upcoming RedwoodJS implementation
  • RSC-like things in Astro

@Martinsos
Copy link
Member Author

Yup certainly! I will update it.

@Martinsos Martinsos changed the title Figure out our plan for SSR / SSG, also SEO Figure out our plan for RSC / SSR / SSG, also SEO Jun 12, 2024
@Martinsos
Copy link
Member Author

Discord discussion on how to do SEO in Wasp: https://discord.com/channels/686873244791210014/1296007418911916092/1296007418911916092 .

@Martinsos
Copy link
Member Author

@infomiho
Copy link
Contributor

infomiho commented Jan 7, 2025

Since we are using React Router 6 for our routing needs, one possible solution for us could be going with React Router 7 as our SSR solution. I've played around with it - it is not that hard to migrate to it - but there are issues with code that depends on the browser APIs when we try rendering it on the server.

Specifically, the use of localStorage to store the sessionId which prompts me to think that we should move away from localStorage and use cookies. Which then prompts me to think that we should move to using a single app for serving both the client and the server (API) to get around problems with using cookies across different domains.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants