Identify that no state is going to change

[yohanleafheart]

Hey mate,

I'm not sure if this is the right place to ask since it is not an issue, but a question. ON my application, I have an onclick event triggering a function which will process the state data and add a new state. I do an AJAX call to get some stuff from the server after the statechange. So far great. But sometimes an user might one to click the same link again, to see if there is new data on the server, but since it is exact the same state data, the 'statechange' is not triggered.

So my question is how can I check if the state I want to push is the same as the current state, so I can sent it to another function?

Thanks for a fantastic plugin

Sol

[balupton]

Yeah it's a good point. I solved this with jQuery Ajaxy which I'm working on updating for History.js. So for now you're out of luck, but I will improve this soon enough :)

[yohanleafheart]

Got it. But if there is a way I can identify if the state I want to push is the same as the current state, I can code around it. But I don't know if that comparison is possible.

[balupton]

It's quite hackish but you it should be something like History.normalizeState(...).id === History.getState().id

I'm on my iPhone before bed so can't confirm. But that should be right, check tests.js we do something like that in there.

Otherwise waiting is the best bet. Patience patience patience eh? ;P

[yohanleafheart]

hehe. Yeah. But you said you are fixing it with jQuery ajax, and I'm using Mootools, so I can't wait for that. I will try it and post to see if it worked.

[balupton]

Okay. I've thought about how I will do this. I'll make it so the statechange event still fires and provide a History.getState().same flag.

It is a better solution than adding an additional statesame event, as issue #42 is also dependent on this.

[balupton]

Perhaps I should add the option: History.options.preventSameStateFromFiringStateChange so extra configuration is not needed in the statechange handler. Thoughts? /cc @yohanleafheart @markjaquith @deleteme

[yohanleafheart]

I like the idea of the configuration because most application will work better (or at least more consistent) if it is not fired. Besides that, allowing the statechange to fire is fantastic.

[deleteme]

I do not have a good enough understanding of the problem at hand, or the solution proposed, to have an opinion on it. Also, This is the first time I saw that you tagged me in the thread. I don't know how github intends on notifying people.

[balupton]

I won't do the option, I'll improve the documentation - it will be up for the individual to be aware.

[yohanleafheart]

Hey mate, any ETA on this so I can program myself to get the latest?

[balupton]

Hey mate, my MacBook died a week ago and I'll only receive my new machine towards the end of the month. In the meantime I'm on an old laptop so have enough power to code, but not enough power to test. So around the start June is when the new release will be out.

[danspam]

Hi, is there any progress on a solution to this issue?

[balupton]

It's inside the v1.8 branch, though that branch isn't stable yet. Not sure when I'll be able to line up more work to pay for history.js development, so feel free to submit pull requests for the 1.8 branch. I'll happily provide any assistance for people who are looking to contribute to history.js development.