private npm is here.

publish unlimited private modules for just $7/month

Hasher is a set of JavaScript functions to control browser history for rich-media websites and applications

If you are a robot, enter text here

Hasher is a set of JavaScript functions to control browser history for rich-media websites and applications.
It works as an abstraction of browsers native methods plus some extra helper methods, it also has the advantage of dispatching Events when the history state change across multiple browsers (since this feature isn't supported by all of them).

One of the greatest benefits of Hasher over other solutions is that it uses JS-Signals for the event dispatch, which provides many advanced features. This can be useful when you are setting the hash value and your changed handler doesn't need to be called (e.g. updating hash value during scroll). Use it with care.

Hasher also contains the method replaceHash(). It works very similarly to the
setHash() method (will also dispatch a changed signal), the main difference
it that it won't keep the previous hash on the history record (similar to
location.replace()). It's useful for redirections and any other change that
shouldn't be on the browser history.

functiononHasherInit(curHash){

if(curHash ==''){

// redirect to "home" hash without keeping the empty hash on the history

Hasher is only focused on providing a reliable and clear API for setting hash values and
listening to hash state change event. If you need an advanced routing system
check crossroads.js. Both
were designed to work together easily:

Hasher will listen for the browser onhashchange event if it is supported (FF3.6+, IE8+, Chrome 5+, Safari 5+, Opera 10.6+)
or it will fallback to pooling the window.location on an interval to check if
hash value changed. On IE 6-7 it also uses an hidden iframe to trigger
the history state changes (since updating the hash value won't do the trick).
This is the same method used by most of the other available solutions like swfaddress,
jQuery Address, YUI History, jqBBQ, Really Simple History, etc...

The main difference from the other solutions are the API, code structure and
the fact that it doesn't require jQuery/YUI/dojo/moootools/etc to work. It also
uses JS-Signals for the events which
provides a sane way of handling events and some really useful advanced features.

Degrade gracefully if for some reason location.hash isn't available, will
dispatch the changed signal at each hasher.setHash() and application
can still work, it just won't generate a new history record.

Doesn't rely on callbacks so you can add as many listeners as you want and
since it uses JS-Signals
for the event system it also provides many advanced featured that wouldn't
be available through a simple callback system, like disabling the dispatch
of an event (so you can change the hash value without affecting your app
state), removing all the listeners at once, dispose objects, etc...

Option to start/stop pooling/listening for changes on the hash whenever you
want giving more control over how you app is supposed to work.

Available as an AMD module which can be easily integrated into other
projects without polluting the global scope or affecting you aplication
structure.

Isn't a plugin for a large JS library/framework (so you can use it with
any library).

Sometimes regular URLs doesn't make any sense, specially when you can't
provide a fallback to all of them or when you just want to save the state of
the application and that change wouldn't make sense on a full page reload
(scrolling through the same page, interactive slideshow, etc..), also some
content may not need to be indexed by search engines (although you can use
hashbangs to make Ajax content crawlable...).
Each scenario requires a different approach, be pragmatic.

Hasher was designed on a way that it will still dispatch the
changed signal even if it can't update the browser location.hash, so
application should keep working even if back/prev buttons doesn't work as
expected.

Consider using the new HTML5 history API
if normal URLs would make sense on the kind of site/application you are building and
you have static fallbacks for all of them (in some cases that may not be
possible or even a good option). History.js
is probably the most used polyfill for the History API, check it out.