Additional Context is sync, why? #3810
-
|
I know this might be a bit of a beginner question, but why is async move || {
let auth_session = leptos_axum::extract::<axum::Extension<AuthSession>>()
.await?
.0;
provide_context(auth_session.clone());
provide_context(db.clone());
},I believe the current best solution is to create a different handler function and move the logic there, but if there is a more ergonomic way to pass the |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
|
I've done some research, and I believe I now know the reason why it is like it is now. As part of If I'm wrong I'd love to be corrected, otherwise this can probably be closed. |
Beta Was this translation helpful? Give feedback.
-
|
For reference if you do go and modify a lot of leptos_axum (and presumably the actix counterpart, a very breaking change (2240d23)) it does let you not have to rewrite it, and you end up with the syntax: move |mut req| {
let auth_session = req.extensions_mut().remove::<AuthSession>().unwrap();
provide_context(auth_session.clone());
provide_context(db.clone());
req
} |
Beta Was this translation helpful? Give feedback.
-
|
It's entirely possible there's an XY problem going on here. (I might be wrong, of course.) I think you'd ordinarily use the This is because if you do it in That's why the additional |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for getting back to me I'm still getting all this figured out, but from my perspective I believe that's what I want. Since I'm passing around an auth provider, I only want is available on the server. I guess calling extract in place of use_context would work in my situation though. I'll see about rewriting the logic to use extract instead |
Beta Was this translation helpful? Give feedback.
-
|
I rewrote it to simply use extract in the server function and it works now. |
Beta Was this translation helpful? Give feedback.
-
|
I'll note here that we have a session_auth_axum example where we do put AuthSession in context and its only accessible on the server. https://github.com/leptos-rs/leptos/blob/9128545388459a6ea06d81b0784fd8457d7fca54/projects/session_auth_axum/src/todo.rs#L28
…On Sat, Apr 5, 2025, at 10:19 PM, J wrote:
Thanks for getting back to me
I'm still getting all this figured out, but from my perspective I believe that's what I want. Since I'm passing around an auth provider, I only want is available on the server. I guess calling extract in place of use_context would work in my situation though. I'll see about rewriting the logic to use extract instead
—
Reply to this email directly, view it on GitHub <#3810 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVBTCIIQ54JMU4IOJR7YBD2YC2MVAVCNFSM6AAAAAB2HCF6GGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENZTHA2DKMA>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
It's entirely possible there's an XY problem going on here. (I might be wrong, of course.)
I think you'd ordinarily use the
extractfunction in this way in a server function where you needed it, rather than providing it as additional context in.leptos_routes_with_context().This is because if you do it in
leptos_routes_with_context(), it will only be there on the initial page load from the server, and not on subsequent client-side navigations (assuming you are using the ordinary routing setup). Whereas if you call it in the server function, it will be available in the server function whether it's called during server side rendering, or from the browser on a subsequent navigation.That's …