Closed bminer closed 12 years ago
Sounds interesting, what would the use case for this be?
I'm currently trying to work towards a 1.0 release and that would be a good time to add extra functionality like this.
The only problem that I see with this is that the request object gets stored as the state data, e.g.
pushState(req, '/foo', 'foo')
From memory only plain objects can be serialized into the history state, which would mean that the DOM element would not be available when navigating the history stack with the back and forward buttons.
I'll certainly keep it mind but I'm not sure it is currently possible.
Sounds interesting, what would the use case for this be?
I don't remember. :P I know that I wanted different behavior depending on which link was clicked.
From memory only plain objects can be serialized into the history state, which would mean that the DOM element would not be available when navigating the history stack with the back and forward buttons.
True... hmmm... maybe this wasn't such a good idea after all. The behavior should probably not be tied to the DOM element that triggered the action; rather, it should be tied to the actual URL/route.
Nice lib, by the way! Your work is much appreciated!
This would be pretty cool.
For example, if the user clicks a link or submits a form, maybe a "target" property of the Request Object would be that DOM element (i.e. the
<form>
or the<a href>
element that triggered the route.