Hooks? about navigo

[fourpixels]

As well as being a good idea, I hope it won't complicate things too much, as it will start looking like smoothStates (which I despite). Do you think it will be an easy and clean implementation?

[krasimir]

Hey, this seems like a nice idea. I see it like:

• Having a storage for the hooks
• Iterate over the hooks (if any) when a route matches

@huevoncito can you come with a few actual use cases. Do you need the hooks before checking the routes or just before navigating to another route, or maybe when a route matches?

[huevoncito]

@fourpixels I don't think it will be too complicated. It allows people to do the smoothState transition thing if they want to, but it also lets them do other things like clear timers or initiate libraries.

@krasimir I'm currently working on a project where I want to show page transitions and loading animations, reset scroll position when navigating back to a page, and things like that. I wrote the beforeRun hooks into the route handlers and hacked the resolve method to add the afterRun hooks. It can and should be cleaner than that.

The use case is something like this:

//global hook to run before leaving all pages
Router.beforeLeave(function () {
   //begin transition, show loader, etc..
});

//global hook to run after all routes are resolved and content is loaded
Router.afterRun(function () {
   //remove loader, begin reveal, etc
});

//hooks for specific page
Router.afterRun('home', function () {
    //init slider timer
}); 
Router.beforeLeave('home', function () {
    //clear slider timer
});

//normal route handler
Router.on({
    'home': function () {
         //make ajax request, etc...

        ///afterRun hook gets called once this is done
     }
});

In the library code, I see all the global before hooks being called inside the navigate method, like so:

• First we would run all the global beforeLeave hooks
• Then we run beforeLeave hooks for the specific route we're navigating away from.
• Then we run any global beforeRun hooks followed by any beforeRun hooks for the route we are going to navigate to.
• Then the normal route handler gets called.
• Once that's complete, we run any afterRun hooks

There are a few different ways this could be triggered. The easiest is how I've done it above. The most succinct would be to change the API a bit so that you could do:

Router.route('/home', {
   beforeRun: function (params) {},
   mainAction: function (params) {},
   afterRun: function (params) {},
   beforeLeave: function (params) {}
});

Internally, we could have a registerHook method that takes a route, the hook type, and the hook function itself, and then just make sure that they get called in the right place (either inside the navigate method or inside resolve, after successful match.)

Sound good to you guys?

[krasimir]

A nice brainstorm. A few points:

• navigate seems like a nice place for triggering hooks.
• I see that beforeLeave and beforeRun are really similar. They are fired just before we change the page. Coming from your context it makes sense to have two hooks. But if we see how the router works we don't have a teardown action so it's just "Now, change the page". I see how this could be implemented and it will be like

beforeLeave()
             <--------- nothing happens here
beforeRun()
actual page switch
afterRun()

• I'm keen keeping the .route API the same and creating a new method registerHook or maybe addHook with the following signature:

registerHook(type, nameOfRoute, callback) - for specific route
registerHook(type, callback) - global like beforeRun and afterRun

[huevoncito]

Makes sense to keep the API consistent. Would registerHook be a public method or a private one? I'm of two minds about this. On the one hand, it's simpler to just call it directly. On the other hand, it's more explicit to have Router.beforeLeave, Router.beforeRun, Router.on, and Router.afterRun. The code is easier to read that way. Either way will be fine, really. Just a thought.

@krasimir Would you like me to draft something or would you prefer to do it?

[fourpixels]

Few things in mind:

1. beforeRun (or however you call it) would make sense only if it can intercept or modify the flow. Therefore changes must be made somewhere in updatePageLinks so that a real flow-like actions are called instead of self.navigate(clean(location));
2. Think about the way hooks are added - doing it as a separate function makes writing the path of the route twice (which means hell, especially for regex :)). Or it forces the user to use the named paths. Both of those sound scary to me.

@krasimir what do you mean by "keeping the api the same"?
You're now doing this._add(args[0], args[1]);, so it won't hurt if you add more params (hooks as third argument) or hooks key in the object.

[krasimir]

Hooks just got released in 3.1.0.

[huevoncito]

Thanks, @krasimir. You’ve done a great job. Sorry again for the slow response times.  Please let me know if you ever need a hand maintaining the repo.

On Oct 23, 2016, at 10:21 AM, Krasimir Tsonev [email protected] wrote:

Hooks
just got released in 3.1.0
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
, or mute the thread
.