-
-
Notifications
You must be signed in to change notification settings - Fork 12
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
add useNavigate #123
base: main
Are you sure you want to change the base?
add useNavigate #123
Conversation
Different implementation for server and client: On the server:
On the client: Not sure about the folder structure and the types |
Neat, and indeed we need some special handling for HTML streaming. Let me know when the PR is finished and I'll have a closer look at it. |
I just thought a little more about it. When I created vikejs/vike#1707 I didn't think of the extra care HTML streaming requires for it. So I'm questioning whether it's worth it to work on this.
(An idea: we could build that streaming logic into Vike core, so that users can directly use So I'm thinking maybe we should postpone working on this until users stumble upon valid/important use cases for it. I went ahead a deprioritized vikejs/vike#1707. Let me know if you disagree. Thank you for digging and the new insights 馃憖 |
Yes, we would need to access |
Maybe something like this? import { getProfile } from "#root/src/components/auth/auth.telefunc";
export function Login(){
const navigate = useNavigate();
const { data: profile } = useSuspenseQuery({ queryFn: getProfile, queryKey: ["profile"] });
if (profile) {
navigate("/home");
return;
}
} VS // pages/login/+guard.ts
import { getProfile } from "#root/src/components/auth/auth.telefunc";
import { redirect } from "vike/abort";
export async function guard(pageContext) {
// load profile in the query cache, to be used in react components
const profile = await pageContext.queryClient.fetchQuery({ queryFn: getProfile, queryKey: ["profile"] });
if (profile) {
throw redirect("/home");
}
} |
In general, I share the sentiment that defining logic on a component-level is nice. But, actually for authentication, I ain't sure how natural that is. I don't know, but I feel like users are more inclined to think in terms of "these pages need authentication" instead of "these components need authentication". Actually, after thinking more about it, I think it's more natural to think on a page-level because any authentication requirement affects the whole page. So I guess we can agree that being able to use |
No description provided.