Allow redirect attribute to be parsed by the Routable macro

[Madoshakalaka]

Edit: This is originally titled "Remove attribute and integrate it into the Routable macro. Then as this #2187 (comment) points out, <Redirect /> might have its value. Thus I changed the title to the current "Allow redirect attribute to be parsed by the Routable macro"

<Redirect/> seems less relevant after the introduction of the history API. Currently, yew-router offers both <Redirect/> and history.push(), which does exactly the same things, in fact, the former uses the latter, with an extra unused empty HTML return (as the pushed history will overwrite the page)
https://github.com/yewstack/yew/blob/master/packages/yew-router/src/components/redirect.rs#L15-L31

<Redirect/> is a sort of a "side effect" component that doesn't render anything by itself. if it's is used anywhere inside a component, it can be replaced with history.push(target_route); (or the normal component counterpart of the history API). The only place it can be legitimately used is the switch function where hooks/ctx.link is not available. Since this is the only place <Redict/> might be used. We can integrate it to the Routable API.

Consider a general case where we have two Routers, a MainRoute and a SettingsRoute.

Here's the code with the current syntax:

use yew::prelude::*;
use yew_router::prelude::*;

#[derive(Clone, Routable, PartialEq)]
enum MainRoute {
    #[at("/")]
    Home,
    #[at("/news")]
    News,
    #[at("/contact")]
    Contact,
    #[at("/settings/:s")]
    Settings,
    #[not_found]
    #[at("/404")]
    NotFound,
}

#[derive(Clone, Routable, PartialEq)]
enum SettingsRoute {
    #[at("/settings/profile")]
    Profile,
    #[at("/settings/friends")]
    Friends,
    #[at("/settings/theme")]
    Theme,
    #[not_found]
    #[at("/settings/404")]
    NotFound,
}

fn switch_main(route: &MainRoute)-> Html{
    match route{
        MainRoute::Home => html!{<h1>{"Home"}</h1>},
        MainRoute::News => html!{<h1>{"News"}</h1>},
        MainRoute::Contact => html!{<h1>{"Contact"}</h1>},
        MainRoute::Settings => html!{
            <Switch<SettingsRoute> render={Switch::render(switch_settings)} />
        },
        MainRoute::NotFound => html!{<h1>{"Not Found"}</h1>},
    }
}

fn switch_settings(route: &SettingsRoute) -> Html{
    match route{
        SettingsRoute::Profile => html!{<h1>{"Profile"}</h1>},
        SettingsRoute::Friends => html!{<h1>{"Friends"}</h1>},
        SettingsRoute::Theme => html!{<h1>{"Theme"}</h1>},
        SettingsRoute::NotFound => html!{<h1>{"Settings Not Found"}</h1>}
    }
}

#[function_component(App)]
pub fn app() -> Html {
    html! {
        <BrowserRouter>
            <Switch<MainRoute> render={Switch::render(switch_main)} />
        </BrowserRouter>
    }
}

Now say we want to add redirect settings/ to MainRoute::Home, this is how we currently do it:

#[derive(Clone, Routable, PartialEq)]
enum SettingsRoute {
    // add here
    #[at("/settings/")]
    Home,

    #[at("/settings/profile")]
    Profile,
    #[at("/settings/friends")]
    Friends,
    #[at("/settings/theme")]
    Theme,
    #[not_found]
    #[at("/settings/404")]
    NotFound,
}
fn switch_settings(route: &SettingsRoute) -> Html{
    match route{
        // and here
        SettingsRoute::Home => html!{<Redirect<MainRoute> to={MainRoute::Home}/>},
        SettingsRoute::Profile => html!{<h1>{"Profile"}</h1>},
        SettingsRoute::Friends => html!{<h1>{"Friends"}</h1>},
        SettingsRoute::Theme => html!{<h1>{"Theme"}</h1>},
        SettingsRoute::NotFound => html!{<h1>{"Settings Not Found"}</h1>}
    }
}

Proposal

Instead of having a <Redirect/> in the switch function. We can accept #[redirect()] attributes on the SettingsRoute struct. Thus saving the need to have a variant and the need to include it in the switch function.

#[derive(Clone, Routable, PartialEq)]
#[redirect("/settings/", MainRoute::Home)]
enum SettingsRoute {
// not changed
}

And multiple redirect works alike:

#[derive(Clone, Routable, PartialEq)]
#[redirect("/settings/", MainRoute::Home)]
#[redirect("/settings/News", MainRoute::News)]
enum SettingsRoute {
// not changed
}

Self should be treated as a keyword in the proc macro to direct to a variant in the current Route:

#[derive(Clone, Routable, PartialEq)]
#[redirect("/settings/alias-name-my-profile", Self::Profile)]
enum SettingsRoute {
// not changed
}

Not Found route

A caveat is how not_found should be redirected as currently the not found route requires a variant. We can handle not_found as a special input to the redirect attribute. Say we want a unified Not Found route under MainRoute:

#[derive(Clone, Routable, PartialEq)]
#[redirect(not_found, MainRoute::NotFound)]
enum SettingsRoute {
// not changed except no need for a separate #[not_found] anymore
}

[futursolo]

This is not the only use of <Redirect /> component.

<Redirect /> is actually provided as an "ergonomic helper" to help reduce verboseness of code and encourages declarative application design which I think is a good thing.

For example, you can do something like:

#[function_component(SomePage)]
fn some_page() -> Html {
    let user = match use_user() {
        Some(m) => m,
        None => return html! { <AppRedirect to={AppRoute::Login} /> },
    };
   // ... actual page content.
}

Without <Redirect />, you need to do something awkward like:

#[function_component(SomePage)]
fn some_page() -> Html {
    let history = use_history().unwrap_or_default();

    let user = match use_user() {
        Some(m) => m,
        None => return {
            history.push(AppRoute::Login);
            html! { } 
        },
    };
   // ... actual page content.
}

react-router provides both useNavigate() hook and <Navigate /> component to navigate between pages.

I think they complement each other and both have legitimate use.

With that being said, I think it's good to add #[not_found] redirect on Routable.

[Madoshakalaka]

Ahh, that is a legitimate usage I guess, I'll remember to add a tip on how to choose between history and Redirect when I write the documentation for #2184. I think a general rule can be: use history for event handlers and Redirect in other cases.