-
-
Notifications
You must be signed in to change notification settings - Fork 352
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
Client-only guard() hook for pre-rendered pages #1916
Comments
For context, this is on an SSG site, using (or attempting to use) the hook to redirect/render different pages under certain preconditions. |
Can you elaborate on that? |
Authentication with SSG is an example that was already mentioned in #1600, but there are other similar scenarios, such as having a whole part/section of a website that is only available after the user has taken specific action (e.g., added some data, made a purchase, ...) Essentially anything you might imagine as reasonable use cases for guard() on a SSR page. |
@brillout If this is treated as "enhancement" rather than a bug, would it be possible to at least make the documentation very clear about the current state in the meantime? For example, https://vike.dev/guard#environment mentions that guard() can be configured to run on the client side, and the section on hook execution order here seems to explicitly state that client-side configuration means the hooks are executed on both both initial render and navigation. It took me quite some time and manual debugging to understand the current state/limitations and inconsistency with documentation. |
IIRC the |
I agree that for pre-rendered pages The Vike's CLI (#1340 and #1341) is a blocker for implementing this, so I'm afraid this will take a little while until I can proceed with the implementation. After I'm done with my work on improving Vike's website and docs, I'll be working on these two blocking tickets and then finally this ticket. |
In the meantime, you can try to use |
Great, thank you!
I don't think either of these work, unfortunately. |
I'll have a look at why it doesn't work. ETA this week. |
(New ETA this week.) |
No,
I just tried calling I also tried inside |
Thanks for investigating! Did you also test this with SSG pages generated with |
Yes
…On Mon, Oct 28, 2024 at 11:59 AM Lukas Fleischer ***@***.***> wrote:
onBeforeRenderClient() seems to have the same problem as guard(): it is
not called client-side on the first page load.
No, onRenderClient() (and thus onBeforeRenderClient()) is always called
including for the first page.
When throwing render() or redirect() from onHydrationEnd() , nothing
happens
I just tried calling throw redirect() in onHydrationEnd() and it's
working. Reproduction welcome.
I also tried inside onBeforeRenderClient() and it's working as well.
Reproduction for this welcome as well.
Thanks for investigating! Did you also test this with SSG pages generated
with npm run build/npx vite build (and not just npm run dev/npx vite)? If
you can't reproduce, I'll try to put together a minimal example over the
coming days.
—
Reply to this email directly, view it on GitHub
<#1916 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHVQRXDRPOLQO7DTIYPVMTZ5YKKLAVCNFSM6AAAAABPRKL3NKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBRGI3DCMBUGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
It looks like you're right; I had an independent bug in my code. After fixing it, The last part that's missing for this to be a viable workaround is a way to set |
Yes, see https://vike.dev/pageContext#custom and e5dc5c4. |
Awesome, thanks for confirming! Still looking forward to having full client-side guard() hook support. |
Description
To reproduce, add a simple guard() hook and configure guard() to run client-side only:
The hook is only executed when using client-side navigation, and not on initial page load.
After reading the first few comments in #1600, I thought this was a known limitation, but after reading the whole discussion and re-reading https://vike.dev/guard, I am no longer sure this is known/intended behavior. (If it is, I believe the documentation should be further improved.)
The text was updated successfully, but these errors were encountered: