Decide on a better mechanism for the "when" property

[webJose]

This is a consequence of when: Since when doesn't really contribute to the calculation of whether a route matches, but for all practical purposes it is one more constraint, weird things happen and fallback content is not shown.

Proposal 1

This is the simpler one: Add the ignoreForFallback property to the <Route> component and associated route data. Then modify the route matching algorithm to not use a route's matching result if this new property is true.

Advantages:

• Small change
• Simple change

Disadvantages:

• One more thing for the user to know and understand
• Doesn't really "fix" the weirdness around this whole thing

Proposal 2

Modify the route matching algorithm to evaluate any provided when predicates for the purposes of calculating the noMatches value.

Advantages:

• No new addition so the user doesn't have one more thing to know and understand
• Seems more logical: For the purposes of fallback content, when results are accounted for

Disadvantages:

• Only noMatches gets to use when predicates; actual matching of routes still don't use it
• Doesn't really "fix" the weirdness around this whole thing
• Bye-bye loop optimization; this would have to repeat the loop over every route instead of the current calculate-noMatches-on-the-go algorithm

[webJose]

After careful consideration, I believe when must disappear.

Proposal 2

It exchanges one confusion for another. Now fallback content might appear when there are matching routes according to the diagnostics in RouterTrace or by examination of the route status data. All because of an internal calculation oddity.

Proposal 1

The ignoreForFallback prop is not a bad idea. I would go for it, but I think when is now unnecessary because the children snippet of routers and routes provide the route status information as a parameter. This enables users to write {#if} blocks to conditionally include stuff, which is essentially what when does today.