router improvements: HTML 5 history & "pretty" links about apprun HOT 5 CLOSED

The core AppRun philosophy is to convert/link DOM events to AppRun events. Our intention is not to have the routing functions altogether, because applications should convert/link the popstate event to AppRun events to match the applications' routing schema, such as #, #/, #:, /#/, or without the hash.

By default, we have implemented the routing schema of using # to make it work out-of-the-box with the HREF of the A element in the bootstrap template. E.g.,

<a href='#About'>About</a>

Applications should publish events for other routing. E.g.,

<a href='#' onclick={()=>app.run('About')}>About</a>

Applications can handle pretty links:

const menus = document.querySelectorAll('.navbar-nav li a');
  for (let i = 0; i < menus.length; ++i) {
    const menu = menus[i] as HTMLAnchorElement;
    menu.onclick = event => {
      event.preventDefault();
      history.pushState(null, '', menu.href);
      app.run('route', menu.pathname);
    }
};

window.addEventListener('popstate', () => {
  setTimeout(() => {
    app.run('route', location.pathname)
  });
});

The built-in _route event uses the default app.route function, which publish handles # and publishes the extra // and /// events. We don't include app.route in the apprun.d.ts.

If applications implement own routing schema and overwrite app['route'], _app.run('route', should invoke the function defined in app['route'].

Does it make sense?

from apprun.

a68aaf3 allows removing and overriding the default route function.

from apprun.

Hi @yysun,
understanding the philosophy is the key here. It makes sense to do this in the application and I have no problem with that.

Having the ability to overwrite the default router is a requirement and it's nice to have support for that functionality. Looking at your change (a68aaf3) I can see at least one problem: The DOMContentLoaded listener can't be removed which means that an application app.route, as opposed to the default app.route, will be called with url=location.hash which might not be what is desired. It could also have the effect of overwriting the application's binding to onpopstate directly in the code. Some possible solutions:

• Provide a method to bind a new router that cleans up the default router including this listener.

• Require the application to provide this functionality.

• Make a separate, albeit small, package with the default router functionality. This would force an application to choose between writing their own router or using the basic hash one.

  Thoughts?

from apprun.

The default router function in your 3rd point is the route function from router.ts. By default, it is stored in the global app instance as app['route']. The router event calls the function stored in app['route'].

1. Applications can remove the function in app['route'].

app['route'] = null;

In this case DOMContentLoaded wont do anything because the app['route'] is not the default one.

2. Application can also override the default router by assigning a new function to app['route']:

app['route'] = url => { /* handle url, fire events */};

• The new router function in app['route'] will still be called by the router event.

app.run('route', url);

• However, the new router function in app['route'] will not be called from the window.onpopstate event. Applications need to listen to the window.onpopstate event to handle location.hash or location.pathname.

app.run('route', menu.pathname);
app.run('route', location.pathname)

The change is 69b3623.

I think it is cleaner. What do you think?

from apprun.

That solves the problem just fine. Thanks for the changes! The only thing that would be "cleaner" would be to have a router in a separate package but I see value having something that works out of the box. Adding a new router on top is minimal size overhead anyways.

from apprun.