I am building an HTML5 single-page web app that employs the concept of "views" or "screens"; essentially just different DOM elements rendered to be visible at any given time. As the user navigates between "views", I'm really just hiding/enabling DOM elements.
I'd like to be able to make use of the browser's history functionality, including the back/forward buttons, but I'm not sure how that plays into the concepts of history.pushState and window.onpopstate.
Ideally, I'd like to register "click handlers" with the browser's back/forward history buttons (obviously in a cross-browser-compatible way) so that when the user clicks either button, it engages my own custom Historian object (in JavaScript) that figures out which "view" to render for the user.
How can I do this?
Firstly, you need some sort of routing solution. You can use Crossroads to register and manage your routes. Each route should have a handler, which enables the appropriate div in your single page.
var route1 = crossroads.addRoute('/page1/', function(id){
//enable div for page1 route
});
Then, you can use Hasher to manage browser history.
Another way is to rebuild your application with Durandal, which has a router and manages browser history out of the box.
Related
I have just read some concept about window.location property and method.
And I know that
1. window.location.href = "http://google.com"
2. window.location.assign("http://google.com")
3. window.location.replace("http://google.com")
are all can redirect our page to the target url, the only difference is that window.location.replace doesn't record the history, so we cannot get back to the previous page directly.
Now I just wondering, what's is the difference between window.location.href and Google, the <a> tag also records the history.
And for what situation do we use them respectively?
I think the main difference is what's happening behind the scene but on the surface they are pretty much giving the same effect.
window.location.href is only triggerable by JavaScript, or in JS context. Whereas a <a> tag defines hyperlink in HTML. It really depends on how you want to trigger this new page. You can either have a hyperlink a user can click/tap on, or you can trigger the page load by some JS functions that are triggered by certain actions.
To be more specific, a tag is common in webpages because browsers understand it and can apply CSS style to it to look nicer. As for window.location.href, there's no UI aspect for it, it simply is a line of JS code that you can trigger to either (1) get the current webpage URL or (2) set a value to it to redirect the user to some other URLs.
The difference is in how they are likely to be used (duh, bear with me.)
Setting window.location.href is a way to programmatically set the URL. For instance, window.location.href = 'https://www.google.com' will navigate the user to Google's search page. There is no way for your user to make use of this knowledge, unless they open the developer console.
Using an anchor tag of Google will show a hyperlink that the user can click, navigating them to Google's search page. This tag is also more likely to be interpreted by a screen reader more appropriately than a button with an onclick that navigates them to Google by setting window.location.href manually in Javascript.
This is a pretty common UX design pattern for apps, and I'm trying to figure out how best to implement this in React Native:
Users can switch between navigator scenes without losing their scroll position...
By default, the React Navigator component wants to re-render each scene when the user switches tabs. This has two drawbacks:
For complex scenes, there is a needless delay while the scene re-renders itself.
When the user returns to a scene (e.g. home page), she loses her scroll position and any interim UX state on that scene (e.g. expanded cells, etc)
Question: is there a way to persist scenes between navigator changes that avoids re-rendering them?
I'm using the following component layout for my navigator pattern:
p.s. I know React's flux/routing pattern prefers to re-render the scene because it prefers UX state to be captured entirely in one route state object, but in this case I really want to avoid the disadvantages of re-rendering a panel since it creates a crappier user interface....Instagram is an example of an app which does this seamlessly.
If you are pushing and popping scenes it will re-render them.
To avoid this you can start with all your scenes specified in the Navigator's initialRouteStack property then use the jumpTo(route) method of the navigator to transition between them without unmounting and re-rendering. This should preserve the current state of all the scenes.
By default, the React Navigator component wants to re-render each scene when the user switches tabs.
Where is this from? I'm using Navigator in similar patten, and the secenes is "Persist". I don't know what's wrong because there's no code here (maybe you re-render the Navigator?), but seams react-native-scrollable-tab-view would be helpful in your example case.
On Behance.net I’ve seen a very smart way of using lightboxes, where an entire page open in a lightbox (like a video or a presentation), but also makes the URL change. If a user shares this URL, the new visitor will see the content, but now in another page (as the new visitor can’t view it in a lightbox, as we wouldn’t know which page would lay behind). Andof cause if the user closes the lightbox the URL will go back to the former page.
You can see it yourself here: https://www.behance.net
We’re building a project using BackboneJS and also uses HTML5 Pushstate, but we haven’t figured out yet, how to do this.
Does anyone of you know?
From MDN
var stateObj = { foo: "bar" };
history.pushState(stateObj, "page 2", "bar.html");
stateObj is any data you want to pass to the popState event.
How to handle History stacks while working with SPA based web applications? I can have my custom stack to track the pages visited, but since I'm just hiding/showing divs , and manipulating the 'history' object requires to push in URLs, I'm unable to understand how to go about handling the situation?
The URL will always remaining something like this : http://mywebapplication/#
I can't push any URLs into the history stack because for all divs being shown, the URL remains the same. Even if I'm somehow able to achieve the same, I don't think overriding the back button of browser should be considered a good practice?
Please suggest how to handle this situation.
In order to track your browsed divs you need some sort of routing solution. You can use Crossroads to register and manage your routes. Each route should have a handler, which enables the appropriate div in your single page.
var route1 = crossroads.addRoute('/page1/', function(id){
//enable div for page1 route
});
Then, you can use Hasher to manage browser history.
Is it possible to show and hide the browser action icon from the options page?
I know how to do it with the page actions using the show and hide methods, but I don't see any similarities in browser actions.
From https://developer.chrome.com/extensions/browserAction:
If you want to create an icon that isn't always visible, use a page action instead of a browser action.
In other words: no, this isn't possible. Browser actions are permanent by design.
Google defined Browser Action as static buttons, and Page Action as dynamic ones.
Google is very careful with Chrome's interface, and don't want people use buttons in a different way they are "supposed" to do.
They do so because they think users have tu put an effort to learn to use Chrome, and Google want to present a consistent, coherent and minimalist user interface.
You don't have much freedom with regard to Chrome user interface.