WinJS Navigation and Browser History?

[staxmanade]

Hey All,

Has there been any thought/discussion around how WinJS.Navigation interacts with the native browser history?

Is there a way I could bring my own history management library. Say react-router, History.js, or Director and still leverage the WinJS library as a whole.

If the BackButton and any other controls that depend on WinJS.Navigation could be adapted to work with other history management API's that would be great. Or if WinJS could provide a routing solution that would allow me to enter http://mywebsite.com/my/deep/route/with/data and be able to handle it within a client side app that uses the WinJS controls that would be helpful.

Thoughts?

Thanks,
Jason

[staxmanade]

FYI: I created a prototype that is working so far for my needs and posted about it here: http://staxmanade.com/2015/10/integrate-winjs-navigation-with-the-browser-s-history/

Would still like to hear any thoughts the team has considered...

[toddpi314]

Jason,

Just check out the Window History API built into the browser.
Here is an example of just pushing the navigation state to the address bar for "hash" style urls: https://github.com/DeepElement/winjsrocks/blob/master/src/service/navigation.js#L72-L75

[staxmanade]

Thanks @toddpi314

I noticed it's a bit more nuanced than just pushing state from what I found out... I updated my blog post http://staxmanade.com/2015/10/integrate-winjs-navigation-with-the-browser-s-history/ and refactored the tracking into class WinJSBrowserHistory{...} which is probably not full-proof, but it does help track navigation and keep the browser URL in sync with the WinJS.Navigation a little better.

From what I was seeing a back navigation using the browser's back button - was not tracking well with WinJS so by using the popstate event I force a WinJS.Navigate back. NOTE: this was only tested in Chrome recently, I'll have to make sure it's working in I.E. as well here soon :)

[toddpi314]

I think the point of it being "nuanced" is the reason it isn't a default feature in WinJS and most likely not a subject for the framework team.

The WinJS.Navigation implementation is pretty much headless (no DOM element or rendering of any type) by default in the core framework. It tracks its own history stack (non-accelerated) and leaves the actual coupling to use-case to the client implementation. This includes which input patterns actually create a 'forward' and 'backwards' navigation and any knowlege of a Window.History object.

In your case, if you press the "Back" button in a browser and see collisions with your own call of popstate(), that sounds like a by-product of the browser automatically calling popstate when you are clicking the native button rather than something being fishy in the Framework.

MS has done a great job with shipping a 'navigator' implementation with the VS templates that really shows how to utilize the existing WinJS.Navigation event patterns without any specific use-cases sneaking into WInJS proper. To your credit, there isn't that many good web examples.

+1 for Window History API calls not to be included in WinJS

[staxmanade]

I agree that it probably shouldn't be directly included in WinJS.Navigation - but was still curious if the WinJS team had any thoughts on the subject.

I got tired of iterating on a blog post - so I threw up a better version of the component here https://github.com/staxmanade/WinJSBrowserHistory

I'll take a dependency on this in my side project and iterate on it as I go.