kendo.Router change event should be more clever in the url the event returns

[Jack]

In the following scenario the url passed in the change event (e.url) is wrong.

If you have an index.html page with several routes like in the samples, for example /, /view1, /view2, ..., normally e.url in the change event returns /, /view1, /view2, ...

Let's say now that this page is is tracked by AddThis (or any service which works by adding tracking codes as hash values), when you call index.html#.Ut-VwxDFJ9N, the route returned by the router's change event is .Ut-VwxDFJ9N instead of /, which is wrong.

The router keeps a list of routes which it could use to check the route returned in the url property change event (e.url).

[Petyo]

Hi Jackques,

if I understand you correctly, you suggest that the router should not pass an unrecognized URL in the change event, but rather the default one. Can you please explain the reasoning and the potential benefits of such change?

Some background: when we designed the component, we exposed two means of handling URL changes:

- The first one is through named routes and callbacks - the route method.
- The second one is through a catch-all event - change.

If you expect that another component (say, a tracking service) will use the fragment URL, then I may suggest that you switch to pushState mode in order to avoid conflicts and broken links. 


Regards,
Petyo
Telerik

[Jack]

On a public web site, you cannot predict the URL a user will call to request a web page especially with tracking services like AddThis adding hash values to the links they track.  The problem is the router is tricked by such unpredictable hash values and does not parse/return consistent routes for the same view whether the url includes such additions or not.

Currently the e.url property of the change event of the router is valued:

• / when calling index.html (a valid route for the SPA page)
• .UuIx1RDFKUk when calling index.html#.UuIx1RDFKUk (an invaid route for the same SPA page called with the AddThis tracking code). Note that it does not return /#.UuIx1RDFKUk which would be consistent.
  

I need to check, but I would not be surprised if this would also disrupt the route parsing in routes like /items(/:id), the trailing tracking code being added to the id parameter.

Many developers will be caught with unexpected bugs if the router does not parse hashes taking this into account, considering the router knows the valid routes. In other words, you need to find a way for the route parsed or returned by the router not to be disrupted with irrelevant hash values that other services may add. This is what I call "being clever".

I would also recommend considering a crawlable route scheme including an exclamation mark as explained here: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Then parsing routes becomes simple:
- routes in the form: #!route are kendo routes up to the following hash,
- hash values in any other forms can be discarded and considered to be irrelevant additions from third party services.

As far as your remark is concerned, the change event could return e.url (without clever parsing as currently is) and e.route being a properly parsed, consistent and valid kendo route which can be tested with if/then statements without adding more parsing to care for unforeseen additions.

I will dig this further and get back to this thread as I will follow Google and other services guidelines to develop my project.

[Petyo]

Hello Jackques,

Thank you for your feedback. Is it possible for you to refer to a resource which specifies which parts of the hash should be considered irrelevant? I am not aware of such convention or specification. 

Some more thoughts on the subject: 

If I understand your requirement, you are willing to ignore certain parts of the URL and call a route anyway. This can be achieved by using optional route formats, or even a regexp route spec. 

The hashbang notation (#! for routes) is included in our roadmap - we are looking in it as an optional configuration for the router. 

Once again - if you expect a third party service to modify the fragment part of the URL and you are concerned about google indexing your project, you should look into using the pushstate mode. 

Regards,
Petyo
Telerik

[Jack]

I am not sure what you call the default URL.

I have explored pushState but it only works properly after you have loaded the page (internal link). Accessing a route directly (external link) does not work. Let's say my views and routes are implemented in index.html at the root of www.mydomain.com:

• Liking /view1 from the home page goes to www.mydomain.com/view1 and displays the corresponding view;
• Putting www.mydomain.com/view1 in the address bar of the browser without loading www.mydomain.com first returns error 404. 

The web server actually does not know what to return when you request www.mydomain.com/view1: am I missing something?

[Petyo]

Hello Jacques,

This is correct; utilizing pushState requires some additional server-side configuration. The simplest approach in that case would be to return the same HTML output  regardless of the URL path. This will effectively delegate the path handling to the client-side. 

Regards,
Petyo
Telerik