Feedback on upgrading from vite-plugin-ssr to vike-react

[micah-redwood]

Hi, first off, thanks for all the time you spend making this framework fast and configurable.

I've been using vite-plugin-ssr at Redwood Materials for a little over a year now and finally spent a few days updating to the latest Vike and vike-react versions. Just wanted to share some feedback on how it went and some pain points along the way:

• Having separate files for each page template and config (e.g. +Page.ts, custom +Head.ts, +title.ts) is a clear pattern, but gets really verbose for lots of pages. I've stuck with +Page.ts and +config.ts, where I export both title and sometimes a custom Head (e.g. a version w/ particular meta tags for a subset of pages)

• Glad to see we'll soon be able to configure the html and body tags. I ended up adding my Tailwind styles globally as a workaround.

• As part of the upgrade, I realized that my Head meta tags never change between client-side page transitions. That's not ideal when they contain important SEO data like noindex tags (certain pages should be indexed, others not). It'd be great if there was a lightweight escape hatch to transition important meta properties, similar to how you do currently for page title. I could use Helmet, but would rather avoid a heavy dependency.

• The favicon solution is so barebones it doesn't feel that useful. Maybe others use a single favicon tag, but I've often found that for cross-browser compat, PWAs, etc I often have at least 4 of them, with different file types, etc.

  

• It took me a while to figure out that if I wanted to use a global provider (e.g. for SWR) I'd have to use a global +Layout.tsx. Would have been nice if the docs had that as an example of using a provider in +Layout.tsx since it seems like a more sustainable pattern than having to roll your own +onRenderClient.tsx (which is what I started doing before I realized I didn't have to)

• Is there any reason to stick config files in the renderer folder vs the pages folder? I eventually moved them all to pages.

• I stuck my tracking scripts at the bottom of +Layout.tsx, but ideally there'd be a way to inject them outside of React.

@brillout , feel free to close this issue, just wasn't sure the best way to get you feedback. Thanks!

[brillout]

• As part of the upgrade, I realized that my Head meta tags never change between client-side page transitions. That's not ideal when they contain important SEO data like noindex tags (certain pages should be indexed, others not). It'd be great if there was a lightweight escape hatch to transition important meta properties, similar to how you do currently for page title. I could use Helmet, but would rather avoid a heavy dependency.

Correct me if I'm wrong but usually these tags don't need to be updated upon client-side navigation because crawlers are HTML-based.

• Having separate files for each page template and config (e.g. +Page.ts, custom +Head.ts, +title.ts) is a clear pattern, but gets really verbose for lots of pages. I've stuck with +Page.ts and +config.ts, where I export both title and sometimes a custom Head (e.g. a version w/ particular meta tags for a subset of pages)

I'm aware and I knew that while designing the V1 design, but the the pros outweighted the cons so I still went for the current design which enables Vike extensions such as vike-react.

• The favicon solution is so barebones it doesn't feel that useful. Maybe others use a single favicon tag, but I've often found that for cross-browser compat, PWAs, etc I often have at least 4 of them, with different file types, etc.

Yes, it's on the radar and I'm actually currently working on this along https://github.com/vikejs/vike-react/issues/67 and https://github.com/vikejs/vike-react/issues/103.

• It took me a while to figure out that if I wanted to use a global provider (e.g. for SWR) I'd have to use a global +Layout.tsx. Would have been nice if the docs had that as an example of using a provider in +Layout.tsx since it seems like a more sustainable pattern than having to roll your own +onRenderClient.tsx (which is what I started doing before I realized I didn't have to)

Actually, <Wrapper> may better fit your use case. Yes, the docs are lacking and it's also on the radar to improve the docs.

• Is there any reason to stick config files in the renderer folder vs the pages folder? I eventually moved them all to pages.

The renderer/ directory is mostly gone from the docs; it isn't really needed when using vike-react.

• I stuck my tracking scripts at the bottom of +Layout.tsx, but ideally there'd be a way to inject them outside of React.

I agree and it's on the radar to implement +client.js.

@brillout , feel free to close this issue, just wasn't sure the best way to get you feedback. Thanks!

:+1: Closing, but let's continue the discussion.

[micah-redwood]

Sweet, looking forward to these improvements!

One more suggestion: might be good to have a "Remix comparison" section on your website. Moving to Remix has come up on my team a time or two, and the reason we're sticking with Vike is b/c it has first-class support for SSG. We can deploy it directly to a CDN and still have client-side page transitions. So would be good calling this out, especially as Remix promotes their new SPA support.

[brillout]

I think a feature comparison table with all frameworks would be quite neat, although it isn't a priority right now so I'm not sure when we'll do this.

[brillout]

AFAICT the upcoming release & docs are going to address all issues. It will still require manual work, but I do envision a as-simple-as-it-gets DX but it's going to take a while. E.g. using a Node.js/native/wasm image manipulator, which I'll research in later releases (the image manipulator will be contained in a Vike extension / Vite plugin to keep core lean).

[brillout]

I'm currently finishing the head management refactoring, stay tuned. Some of it won't be what you expect but I'll make the docs clear about it.