RT，看了代码，也用API.html测试了一下，这个参数没有文档里讲的 { Example stateman.nav("/app/contact/1?name=leeluolee", {data: 1}); 最终传入到enter, leave与update的option参数会是{param: {id: "1", name:"leeluolee"}, data: 1}. } 这个作用。

有三个状态"app"，“app.list”，"app.list.info"，都采用ajax加载内容进行更新。

如上图的前端模式，请求#/app的时候将红色区域的html用ajax请求渲染到1中，请求#/app/list的时候将"app.list.info"用ajax请求渲染到3中。

如果按照顺序先访问#/app，然后访问#/app/list 完全没有问题

如果直接请求#app/list的时候会先请求#/app，然后请求#/app/list，这个时候由于同时执行2个ajax请求，如果第2个ajax先执行完毕就会导致无法渲染到3中，因为这个时候第一个ajax还没有执行完，也就是页面上还没有渲染1中的内容。

这个问题应该怎么处理?

I found quite a few issues with code when was closely debugging some issues. I was thinking about cleaning up code and fixing these issues, and adding ESLint config to prevent these from cropping-in in future. But this will make any merges almost impossible.. Do you think you get to the point where you are "done" with changes for enough time for me to make few passes on improving quality of the code? So we do not work on the code base at the same time.

I don't think that this library needs to call it "Histery." The only conflict would be window.history, but the lib is not attaching an instance of Histery to the global scope.

I'd prefer it to be called History, 'cause it's more in line with what people would expect. Backbone, for instance, calls it Backbone.History.

If you are :+1: @leeluolee I will make a PR.

stateman.encode('state-that-doesnt-exist')

Uncaught TypeError: Cannot read property 'encode' of undefined

This is a matter of preference, but I would probably return undefined.

I'll PR this if you want to change it @leeluolee.

I think that the API around async methods is limited by the fact that this library assumes that Promises don't exist.

@leeluolee, I understand that you have two priorities:

1. Support old IEs
2. Don't include a Promise library

These are priorities that I, too, share. But I still build my libraries assuming Promises, because they are a familiar tool for devs, and they make for a much nicer API.

What I do is require that the developer set Library.Promise before they can use the library, if they're in a legacy environment. Other popular libraries have adopted this pattern, too. Here's a good example.

I would wager that a surprising number of developers use a Promise implementation in their source, so it's not creating too much extra effort for them, I think.

This would allow you to get rid of the var done = this.async() pattern, and instead switch to: return myPromise;, which I find way nicer!

Little summary of pros/cons...

Pros:

• Devs get to continue using Promises, which they're likely familiar with.
• Devs don't need to learn this less-familiar, more-verbose pattern

Cons:

• Slightly more work setting up the library if you need to support older IEs

你好，我尝试在项目中使用你的stateman，可是发现路由绑定的函数不允许连续触发两次的，就是不能连续点击同一个url，你网上的demo也是这样。。http://leeluolee.github.io/stateman/example/api.html#/app，是不是要配置什么参数才能支持连续点击，我在文档上找不到具体的。。

1. emitting a notfound event when navigate to a unexists state when using a statename.
2. check whether the link target is the same domain and avoid navigating.

I have complete the work with version 0.2.0. you can find it at branch:develop.

ChangeLog

• add askForPermission phase in Lifecyle. which is useful for control navigation.
• support Promise in enter， leave and canEnter, canLeave( introduced in v0.2.0) to help us implement some asynchronous navigation. #7
• add namespace support for builtin emitter #16
• remove [state.async], you can use option.async for asynchronous navigation. but I suggest you to use promise instead. The only change that isn't backward-compatible.
• remove $notfound #11
• coverage is almost 100% now .
• take watch as the default task #13
• unify the routing option.

I need some time to update the doc, you can preview the incomplete version HERE

Although stateman 's version is only 0.2.x, but I think it is ready to release the stable version. So, I will do my best to make it good enough during the v0.2.x. The next version will be 1.0.0.

There are two ways to add notfound functionality, a $notfound state, and the notfound event. Not too big a deal, I guess, but I don't think both are necessary. Fwiw $notfound is not documented, and can only be found in the src and examples.

I met a problem when using stateman in my webapp, there is a link relativing to a page with a different domain but its url contains a hash. when clicked, new tab should be opened ,but the stateman checks the target , and a hash found in the href, so it try to routing . btw i didn't init the stateman with a 'prefix' option.

I think it should check the domain first, and do nothing without the same domain .

the code may appear here. https://github.com/leeluolee/stateman/blob/master/src/histery.js#L151

browser.on( document.body, "click", function(ev){

          var target = ev.target || ev.srcElement;
          if( target.tagName.toLowerCase() !== "a" ) return;
          var tmp = (browser.getHref(target)||"").match(self.rPrefix);
              .....some checking here?
          var hash = tmp && tmp[1]? tmp[1]: "";

          if(!hash) return;

          ev.preventDefault && ev.preventDefault();
          self.nav( hash )
          return (ev.returnValue = false);
        } )

https://github.com/leeluolee/stateman/blob/e195ed177ab1fd5e34353fde2bd31f63c5769ad5/src/manager/client.js#L7

https://github.com/leeluolee/stateman/blob/e195ed177ab1fd5e34353fde2bd31f63c5769ad5/src/manager/client.js#L20

这个 baseTitle 作为 document.title 的赋值，即使后续 document.title 变化了，baseTitle 是不变的，希望 document.title = cur.getTitle( options ) || ocument.title || baseTitle

背景：ie8中使用core.js polyfill了assign方法到Object.prototype上 使用manager.go时如果带上url参数(e.g. manager.go('error', { param: { t:'type'} }))，state.js中encode方法142行的for in语法遍历到param的'assign'属性，该属性是个function，带到参数中会导致报错 建议：加上hasOwnProperty判断过滤

We have used stateman in a dozen projects already and find that we always do similiar work in enter and update , so most of the states like below

stateman.state({
    'app.blog': {
        enter: function( option ){
             this.udpate(option)
         }
        update: function(option){
            // logic here
        }
    }
})

At that rate, why not call update after enter?

Plan to change the logic in 0.3.0.

Just get it over with instead of keep suffering.

Hi!, nice work, small and they have all I need. So, I have some problem (not very big) with the lifecycle. I take your html example and I add, canLeave and canEnter callback function. I print the :

"this.name", "event.current.name" and "event.previous.name".

I navigate by the link on "home" after "contact" and I uptain :

canEnter: home. Current : home. Previous : 
enter: home. Current : home. Previous : 
canLeave: home. Current : contact. Previous : home
canEnter: contact. Current : contact. Previous : home
leave: home. Current : contact. Previous : home
enter: contact. Current : contact. Previous : home

1. If you look only "this.name" when you navigate from "home" to "contact", you are :

canLeave home, canEnter contact, leave home, enter contact.

In "my" logic, the canEnter contact and leave home must be inverse and we must have :

canLeave home, leave home, canEnter contact, enter contact.

It is look right? (sure in sync way)

2. If you look current state and previous state :

Clic on "home", in the canEnter event, the current state must be empty cause we don't are in the state home, but just ask for enter to it.

Clic on "contact" :

• on canLeave home event, the current state must be home and previous empty, we don't leave yet, just ask.
• on canEnter contact event, the current state must be empty we leave home but we don't enter to contact yet.
• on leave home (they must be before canEnetr see point 1), we are two choice, first, the current state must be empty and previous must be home or the second, current state must be home and previous empty. But I prefer the first choice for make a difference from enter to the state where the current is home and previous is empty.

This is look right to you? So if not, explain your logic for current, previous and this in the event. If yes, do you need some help, I can change the code and you validate it after.

Nacrylyc.