What are the advantages of using State vs Extensions?

[thomasmost]

Specifically, a route handler for me currently looks something like this:

pub async fn listed(Extension(pool): Extension<Pool>) -> axum::Json<Vec<Org>> {
  let dao = &mut OrgDao::new(&pool);
  let orgs = dao.get_listed();
  axum::Json(orgs)
}

vs

pub async fn listed(State(state): State<AppState>) -> axum::Json<Vec<Org>> {
  let pool = &state.pool;
  let dao = &mut OrgDao::new(pool);
  let orgs = dao.get_listed();
  axum::Json(orgs)
}

...but what are the advantages of using State for db pool management/why should I? I understand that state is shared between all routes but I think that's still true with this initialization, yes?

#[tokio::main]
async fn main() {
  ...
  let pool = init_pool();
  let app = Router::new()
    .route("/", get(service_info))
    .nest("/v0", v0_api)
    .layer(Extension(pool));
  ...
}

[davidpdrsn]

State is type safe, Extension is not. If you forget .layer(Extension(pool)); everything will still compile but fail at runtime. Not so with State.

[thomasmost]

Can you apply more than one state object to one router?

…

On Wed, Mar 8, 2023, 1:47 PM David Pedersen ***@***.***> wrote: State is type safe, Extension is not. If you forget .layer(Extension(pool)); everything will still compile but fail at runtime. Not so with State. — Reply to this email directly, view it on GitHub <#1830 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB44JJYWNCZ4QEYXVJTWFU3W3DH53ANCNFSM6AAAAAAVUDJRFA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[davidpdrsn]

With sub states sorta yes https://docs.rs/axum/0.6.10/axum/extract/struct.State.html#substates

[thomasmost]

I'm late following up on this but nice! This is exactly what I was looking for. Seems like a great pattern that affords the right flexibility/simplicity I'm looking for

[Geo-W]

Is it possible to use both? 😂

[oscar6echo]

I see that your router uses a state without the applying .with_state(), implying that the latter is not necessary with from_fn_with_state().
Do I understand well ? What if you still add with_state() ? What would it change ? Will it work ?

[davidpdrsn]

Middleware can't accesss state set by .with_state(). You have to pass it directly to something like from_fn_with_state. Hoping to fix that one day but dunno how to do it.

[oscar6echo]

Ok, this adds clarity.
I rephrase and summarize to make sure I get it - please correct me if wrong:

Each middleware is only aware of the state it receives in from_fn_with_state(). So each mw can use the same or different, presumably more specific, states. And theses are distinct from the one passed in with_state(). The latter is potentially available to handlers only.
Finally the way for a middleware to pass a state to handlers is via an Extension (not ideal as not type safe) or via a state if this one is passed both to from_fn_with_state() and with_state().

Is that a valid description ?

[davidpdrsn]

Each middleware is only aware of the state it receives in from_fn_with_state()

Yes they are distinct.

Finally the way for a middleware to pass a state to handlers is via an Extension

https://docs.rs/axum/latest/axum/middleware/index.html#passing-state-from-middleware-to-handlers

You cannot use state for this because state is global within a router. For request specific state use extensions.

[oscar6echo]

Ok clear thx 🙏

Middleware can't accesss state set by .with_state(). You have to pass it directly to something like from_fn_with_state. Hoping to fix that one day but dunno how to do it.

Btw I do not dislike this API: it allows fine grained control.
Various ways to pass states around are rather good I'd say, as long as it clearly documented.