Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Router does not allow for compatible history handling #12

Open
pstjvn opened this issue Sep 4, 2012 · 5 comments
Open

Router does not allow for compatible history handling #12

pstjvn opened this issue Sep 4, 2012 · 5 comments

Comments

@pstjvn
Copy link

pstjvn commented Sep 4, 2012

If the router is used directly (as it is by design) and the browser does not support html5 history API it will break pre-rendered pages, because goog.History is using document.write if no input html element is provided and there is no way to provide such in the mvc.Router constructor.
This is a case where the page is rendered on the server (or statically designed) and is then decorated when it is already loaded.

@rhysbrettbowen
Copy link
Owner

@pstjvn do you think it would be better to be able to pass in the opt_input and opt_iframe for goog.History or to have mvcRouter create these elements for you using a goog.dom.append on an optional window target?

@pstjvn
Copy link
Author

pstjvn commented Sep 5, 2012

Honestly - I don't know. For example Relief framework expects the user to supply those directly.

If you want to provide better abstraction on top of closure library (and because those might not be needed anyway if html5history is used), create them on runtime and spare the developer.

@rhysbrettbowen
Copy link
Owner

I've added in the ability to pass in an input and iframe that will go to goog.History:
c693c12
let me know if that won't work for you

@pstjvn
Copy link
Author

pstjvn commented Sep 5, 2012

Yes, this solves the issue at hand. Thank you.

I am also still wondering what was the idea behind the html5history using popstate and hashchange at the same time (i.e. if you want to use fragments just for the sake of having the same working across browsers and links working from simple a tags (ex: rendered on the server)) - the change event is fired twice and thus the router uses it twice, is this intended by design?

@rhysbrettbowen
Copy link
Owner

To tell the truth I don't use simple hash changes from links. I advocate always telling the router to handle state (http://modernjavascript.blogspot.com/2012/06/routing-and-state.html). It looks like listening to both popstate and hashchange is part of the HTML5History module in the closure library so I'd have to override that. I'm unsure how changing it would effect things for other people so I'll have to take a bigger look in to it and make sure tests are there first.
Thanks for the heads up

@rhysbrettbowen rhysbrettbowen reopened this Sep 5, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants