Support route removal and insert-at

[ianmstew]

An API for more flexible dynamically-constructed routers would be quite powerful. This would enable subclasses to implement a modular router paradigm while keeping order intact when it counts, such as the soft-404 handler. The implementation would essentially boil down to splicing on the undocumented Backbone.history.handlers array. Or, like you mention in #22, the alternative may be a rewrite of Backbone.history.

Possible use case:

• Allow for dynamic registering/deregistering routes without conflicting with a catch-all terminal route, such as a soft-404 handler

Possible API

• Backbone.history.insertBefore(route, referenceRoute)
• Backbone.history.insertAfter(route, referenceRoute)
• Backbone.history.insertAt(route, index)
• Backbone.history.remove(route or index)

Note that route removal and insert-at could be rendered unnecessary if this library departs from Backbone.History "callback order" entirely. Perhaps that is the question that should be answered first, whether or not this library will become "an effort to rewrite Backbone.history" after all.

[jamesplease]

Hey @ianmstew!

I agree with you that Backbone's route sorting mechanism causes problems. Sorting routes into an array and comparing them one-by-one without any notion of sorting is a very limited approach to routing.

With that said, I don't think the solution is to continue to operate in that restricted environment, which is what is happening with the proposed insertX API. I'd much rather rewrite the match routing algorithm.

I've been looking at Ember's implementation, which is pretty smart, I think, and would remove the need for that insert API. I might write an adapter for it to be used by Backbone.History, then link it up to the base router somehow.

What's your use-case for route removal?

[megawac]

The issue would come from ranking regexps I'd think

[ianmstew]

@jmeas, nice! Preferring static -> dynamic -> star routes, as you pointed out Ember does, would allow a catch-all "star" route to be matched last without managing order.

Taking a step back, what if a collection of matched routes is returned, in the order they were registered? This is even more abstract, does even less than Backbone, Ember, or Express do for you, but leaves the route selection algorithm up to the developer. One could re-engineer any of the above routers or, more interesting, create a possible combination of them.

To answer your question, my only reasoning for route unregistering is logical completeness. If a module registers its own routes on instantiation, then unregistering those routes on destruction seems like a parallel. I cannot, however, think of a use case that would benefit from short-lived modules, and if there is any internal reliance upon ordering then this could get messy.

[Anachron]

I've been thinking to use dependency based object storing, maybe in a linked list or something.

You could first load your app and then insert your module routes without having to worry where it will stored into.

[jamesplease]

@Anachron, can you elaborate?

[Anachron]

@jmeas sure!

If you use a linked list or graph you can store your dependencies. Then when you load or unload modules you read the dependencies to insert the routes before or after the dependencies, depending on the definition. When you unload you will remove the node that has been linked to the unloading module.

All of this should be optional, of course.

[jamesplease]

Interesting @Anachron. I'm going to close this issue because I think it's beyond the scope of the router to fix Backbone's route resolution mechanism. I think such a change would get into overriding History. I'm also still not that big a fan of skirting around the issue by removing / inserting routes into the handlers array.

I'm planning a new system for routing that solves all of these problems, and more. Base Router is a good library to use in the meantime tho'.