Rethink of Router::state

[arniu]

The state is usually used for data sharing. It can be a db connection, cache client, HTTP client, or a couple of them, which is always wrapped in Arc.

[davidpdrsn]

I don't understand, what is your question? Please elaborate.

[arniu]

axum/axum/src/routing/mod.rs

Lines 63 to 65 in 4c9edb4

	/// The router type for composing handlers and services.
	pub struct Router<S = (), B = Body> {
	state: Arc<S>,

Change state from Arc<S> to S.

[davidpdrsn]

I disagree. I think this is the right thing for most users.

[davidpdrsn]

To elaborate:

It exposes the implementation details to end users, and the API, related to state, is doubled;

You mean having with_state and with_state_arc is "doubled"? I don't think thats an issue. Most people will use with_state and the docs for with_state_arc explains why it exists.

I guess we're leaking the fact that axum has an Arc on the inside but I don't see that as a problem. I doubt it'll change.

In most cases, the state is already wrapped in Arc. There is no need to do it again.

I'm not sure thats true. Database connections pools sure. But I still think users keep state that aren't necessarily Arc'ed, maybe API keys or access tokens.

I don't think two pointer indirections are anything worth worrying about. Your app already does tons of IO so how much does two pointers really matter?

[arniu]

What's the downside if the Arc was taken off?

[davidpdrsn]

Users might use state thats expensive to clone.

[arniu]

While it's not expensive to wrap the state with Arc manually.

[mlodato517]

Swinging over from #1374 I too am confused. I feel like there are a couple ways I would expect with_state to work as an end user (since I have no idea about the internals):

1. with_state wraps the passed state in an Arc and then handlers can extract State<Arc<S>> (the router cheaply clones the Arc<S> and hands those out to the handlers that need them)
2. with_state does nothing to the input and just Clones it and handlers extract State<S> and the user should wrap it in an Arc for cheaper cloning

It seems that currently an Arc<S> is stored internally for cheap cloning but then handlers have to extract State<S> which clones the underlying S out from under the Arc<S> that's stored. If I have that wrong then apologies for being confused yet again 😅 If I have that right then I think that's a surprising API. I'm just one person but I think some less surprising experiences could be either:

1. Having with_state(S) result in Router<Arc<S>> so that handlers can extract State<Arc<S>>. In this case with_state_arc(Arc<S>) also results in Router<Arc<S>> with handlers extracting State<Arc<S>>.
2. Having with_state(S) result in Router<S> (as is the case now) but there is no Arc and S is deep cloned when extracted as State<S> (which I think is what's suggested by the original post)

[arniu]

曝露内部细节相当于引入额外限制，让我们在设计时缚手缚脚。

而要探求 state 长什么样，让我们忘掉具体实现，从需求出发：

1. 保留类型信息，编译时即可发现接口是否匹配；
2. 支持路由嵌套；
3. 便于使用；
4. 易于复制；

这意味着：

• T1: From<S1>,
• T2: From<S1>,
• T1: From<S1 + S2>,
• T2: From<S1 + S2>,
• S1: Clone,
• S2: Clone,

未完待续

[davidpdrsn]

@arniu Please stick to English.

[ttys3]

Some frameworks define a Data type for state like:

pub struct Data<T: ?Sized>(Arc<T>);

impl<T> Data<T> {
    /// Create new `Data` instance.
    pub fn new(state: T) -> Data<T> {
        Data(Arc::new(state))
    }
}

and it impl

impl<T: ?Sized> Clone for Data<T> {
    fn clone(&self) -> Data<T> {
        Data(Arc::clone(&self.0))
    }
}

so that, when extract, it is like var: Data<T>

T is not cloned, but Arc is cloned.

[andersk]

This seems to have been resolved in 0.6.0-rc3 by #1460.