betterment / backbone.blazer Goto Github PK

it would be nice to be able to pre-filter routes before they're executed.

example api:

we could allow this to just be a function that returns true to continue and false to bail out early.

Backbone.Blazer.Route.extend({
  filters: [(routeData) => { // true continues, false bails early }]
});

but what do we do if we bail out early? we trigger error? sounds crummy.

another idea:

we could create a special object like Route

Backbone.Blazer.Filter = Marionette.Object.extend({
  test: function(routeData) { // true/false },
  failed: function(routeData) {
    // called if test returns false
    // allows this filter to handle what happens if it fails
    // e.g. an auth filter could have this do a redirect to the log-in view
  }
});

Backbone.Blazer.Route.extend({
  filters: [new AuthenticatedFilter()]
});

questions:

• should this support asynchronous filters? (leaning toward no).

- route.prepare(routeData).then(function() {
+ Promise.resolve(route.prepare(routeData)).then(function() {

This lets you support sync and async prepare methods.

Depends on #13. Competes with #12 (comment)

https://github.com/Betterment/backbone.blazer/blob/master/backbone.blazer.js#L19

It is not unreasonable to tell people to include a Promise polyfill these days, and jQuery promises expose a weird API.

consider replacing events that exist now with Backbone.Radio / Backbone.Wreqr request/response style pattern to make them more useful.

Add continuous integration

Now that testing is fixed, finish the test suite.

There's not really anything Marionette-specific in here. I'd just use a good ol' JavaScript function for your 'Route' object, then mix in the Backbone goodies like extend and Events.

If, in your own applications, you use Marionette features like triggerMethod, you could add them to your application by extending the Route class. The benefit to this change is that it makes the library usable by more of the Backbone community.

This issue competes with samccone@7faf9a7.

instead of registering routes like this:

routes: {
  'foo': new FooRoute()
}

we'd like to register like this:

routes: {
  'foo': FooRoute
}

so that we can construct a new instance of the route for each navigation to that route. this makes it so that the route handler objects are not singleton-esque since they encourage the process of attaching state to themselves.

another approach would be to re-work the inner pipeline in the router so that the router takes the fulfillment values of the prepare promise and pipes them into the execute method. then the routes would be able to exist as singleton-esque instances.

Upload to bower

decide if the error method on Route objects should be called given ALL types of errors that could arise when processing a route. i.e. should they be called when there is a view error? undefined method error? etc. is it a try/catch kind of thing?

this looks like a better version of what we have for our overriden route method. we could us something like this and build on top of it. just have to hope it doesn't go away otherwise our project would die :(

https://github.com/jmeas/backbone.base-router