This is an important feature, that I do want to support eventually, but because its use case isn't needed except for in larger, professional applications, I think my time is better spent elsewhere in the meantime.

If the lack of this feature bothers you or prevents you from using this library, or Yew itself, please leave a comment here so I can gauge interest.

Enough changes to how the state system works recently now makes this feature plausible to implement.

enum State {
    Id(i32)
    FormData(String, String),
    SelectedResource(Url)
}

#[derive(Switch, Clone)]
enum AppRoute {
    #[to="/home/{name}"]
    Variant{
        name: String,
        #[state]
        state: Option<State> // By default, holds nothing.
    }
}

Upon exploring this space, I have found some design deficiencies with respect to Routes with type parameters.

Because of the STATE type parameter on Route, there isn't a way for the macro to set/get the state field, because the __T has no relation to the annotated state: _ field in the variant/struct.

The way to overcome this problem is to simplify Route.

• Remove the type parameter STATE.
• Have the state field just be a String.
• Allow setting/getting the state field for any type by ser/de ing it to/from JSON.
• Remove <T> parameter from Switch, remove STATE from every other construct in the library.

This would have the add-on benefit of removing the Routes type parameter - which has "infected" nearly every other major construct in this library and is a point of developer error if you ever mis-match the type parameters.

With the router rewrite, Switch trait has been removed. The new router provides different APIs, which allows ergonomic usage of router state. I'm closing this as this is no longer needed.