[Proposal] router switch conditionals

Router Switch Conditionals

What is

Sometimes we may wish to have a better way of controlling if a route is going to be rendered or not, without a redirect (as the wiki proposes). With this we can pass a conditional to a route as a prop so the switch may see if the route can render.

To this day work-around

While we don't have this resource, what I usually do, is pass a function to the path parameter of the route (inside a switch), an example as follows:

var user = null;

function isGuest(route) {
   return user === null? route:"impossible route";
}

export default function App (props) {
   return (
       <Switch>
              <Route path={isGuest("actual/route")} component={Component} />
       </Switch>
   );
}

What I'm doing is rendering an impossible route if the condition inside the function is not met, with this I can generate tons of functions to describe those conditions, such as: isGuest, isLogged, isAdmin. Of course, that this method is not ideal.

Sample

How the router switch conditionals would work:

var user = null;

export default function App (props) {
   return (
       <Switch>
              <Route path="actual/route" condition={user === null} component={Component} />
       </Switch>
   );
}

Returning true would allow the switch to consider this route when choosing which one to use.

Changes

The changes in the source code would be near to minimal

Switch class

class Switch extends React.Component {
  render() {
    return (
      <RouterContext.Consumer>
        {context => {
          invariant(context, "You should not use <Switch> outside a <Router>");

          const location = this.props.location || context.location;

          let element, match;

          // We use React.Children.forEach instead of React.Children.toArray().find()
          // here because toArray adds keys to all child elements and we do not want
          // to trigger an unmount/remount for two <Route>s that render the same
          // component at different URLs.
          React.Children.forEach(this.props.children, child => {
            if (match == null && React.isValidElement(child)) {
              element = child;

              const path = child.props.path || child.props.from;
              const cond = child.props.condition || true;

              match = (path || cond)
                ? matchPath(location.pathname, { ...child.props, path })
                : context.match;
            }
          });

          return match
            ? React.cloneElement(element, { location, computedMatch: match })
            : null;
        }}
      </RouterContext.Consumer>
    );
  }
}

The only thing that we are doing is adding a const that reads the condition and passing it for the match test altogether with the route comparison.

[MeiKatz]

This reminds me of the following two issues: #6745 and #6683. But there is more about this:

1. if there should be such a feature we should name it when instead of condition to be consistent with <Prompt />
2. it also could be solved via prop when we support function for prop. But this seems a little awkward to me.
3. This could also be solved via <Route children={} /> (or <Match /> in the future).

Anyway. I think this could be a good extension for React Router.

[timdorr]

You should do this as a condition of rendering the Route:

<Switch>
  {user === null && <Route path="actual/route" component={Component} />}
</Switch>

That would skip the render entirely, which is better for performance.

So your argument would apply to prompt's when too.

But anyway, I think this is horrible for the code's visual.

[MeiKatz]

I think it is a fundamental question about which design line we prefer for React Router. Either we go with when for <React /> and <Prompt /> or we drop it for both. (Yes, I know that <Prompt /> will be dropped in some upcoming versions.)

[StringEpsilon]

Personally, I dislike inline-conditionals in my JSX and avoid them whenever possible (by moving the decision to the component in question). It makes for a lot of visual clutter.

A when prop on Redirect and Prompt is preferable to that the clutter. And since this such a minor impact on RR code, I vote for adoption.

[MeiKatz]

There is one thing I dislike about this idea: when there is a when condition I don't expect that there is also a path prop. Either or, but not both. Maybe this is also a case for your new <Match /> component, @StringEpsilon?

<Switch>
  <Match when={(location) => location === "actual/route" && isGuest()}>

  </Match>
</Switch>```

<When> actually would work as a safeguard for the route, it's a optional with default value of true. Maybe Match would do the trick, but this would be used as a content filter depending on what user is or if it is logged.

Example

<Switch>
    <Input path="/projects/{id}" when={ownsProject()} component={ProjectOwner} />
    <Input path="/projects/{id}" when={isProjectMember()} component={ProjectMember} />
    <Input path="/projects/{id}" when={isProjectPublic()} component={ProjectPublic} />
</Switch>

[MeiKatz]

I get your point but I dislike it after all. Looks redundant to me.

[StringEpsilon]

I don't think it's redundant. Even less so with the Match component:

<Match path="/projects/{id}" when={isProjectMember()}>
   <ProjectMember/>
</Match>

It's basically a sentence. Keeping code readable and intuitive to understand is IMHO more important than concerns about finesse. Simple beats clever, even if simple is more blunt.

The function has more flexibility, but I don't think the added complexity justifies that small gain. And it might spawn some really wonky hacks that we shouldn't encourage.

Edit:

Having to omit then path prop when using the when prop also makes adding or removing the when-condition inconvenient.

[timdorr]

I really don't agree with this. It makes sense in the case of <Prompt>, where you're mapping an imperative action to React's declarative form. But you shouldn't be rendering a <Route> at all if you intend it not to display due to a conditional.

It's the same reason we don't have an <If> element in JSX. You have to bail out to regular JS to handle this stuff. Maybe JSX 2 will eventually address this, but for now, you should be wrapping the entire element's existence in a conditional. That's just idiomatic JSX and React.

[StringEpsilon]

The "don't render if it doesn't do anything" applies just as much to Prompt.

I accept an argument for performance, but with RR related components, that's pretty negligible in almost all applications.

To me, this is more an issue of preference. I'll accept the majority opinion, but I don't agree that this is a straightforward case of "that's just how JSX works". It's a flaw in JSX we can provide a nice and easy workaround for to make development easier for RR users. And it only costs giving up the purism ;-)

(That and what I wrote prior is all the productive stuff I have to contribute. I'll submit a PR if consensus can be reached in favor.)

In my sincere thought, this is a long due addiction. But as "newbie" in programming, I always abstained from any discussion. Is it necessary? Of course not, nor react, you could build everything from the ground up, nasty as it looks, it will work. But this is something that makes react-router modular in a way that could help both new comers and experienced professionals, it also looks good and is readable. From my look, <Match> would disarm this feature, but one or another should be end up into the API.

[MeiKatz]

@timdorr If we move the part where we check the condition in when to the <Switch /> component then there would be no unnecessary render of any <Route /> component. Actually, this is exactly what we are doing right now for the path and from prop.

const path = child.props.path || child.props.from;

(Source: https://github.com/ReactTraining/react-router/blob/master/packages/react-router/modules/Switch.js#L31)

[allankikkas]

it does feel redundant as it's only "if" part ot the sentence. What about "else" part? Sooner or later somebody will start asking for it.

We are talking about a router here, not just some random component toggle. Route "unavailability" should be always handled and just falling through to 404 is just bad design / user experience as you are not providing real feedback for the situation. To some extent it would make sense to have a static routing in place. But to extend the original switching issue - please allow <React.Fragment> wrapping support for conditional routing grouping.

@allankikkas, else is already included because of the switch

<Switch>
    <Route path="hi" when={false} />
    <Route path="hi" when={false} /> //This works as else if
    <Route path="hi" /> //This works as else 
</Switch>