Closed micah-redwood closed 4 months ago
- 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 bothtitle
and sometimes a customHead
(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 thepages
folder? I eventually moved them all topages
.
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.
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.
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.
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).
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.
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 andvike-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 bothtitle
and sometimes a customHead
(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
andbody
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 thepages
folder? I eventually moved them all topages
.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!