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.
Related
I'm building a component that uses an <iframe> to display another component. This component connects to an NGXS state which needs to reflect changes made to the state. After a lot of failures and testing I discovered the component will always only load the default settings of the state. I created a <button> to toggle a boolean and added an *ngIf to the <iframe> so I can force it to reload manually after trying things like this.Frame.(contentDocument || contentWindow).location.reload(true); didn't make any difference.
I created a stablitz app to demonstrate this issue however I think stackblitz blocks the use of <iframe>s in their platform so you might need to copy it into a local project to tinker with it. It's a simple app that shows the state outside of the <iframe> as well as inside with a button that toggles the <iframe> on and off so you can see how only the default values load after you update the value I have available for demonstration purposes. I'm not getting any type of errors and the issue isn't a matter of something being wrong with the code so I don't know what more to show that isn't in the stackblitz.
Does anybody know why and how <iframe>s do this and if there's a way around it? The only thing I can think to try is make a NestJS app to see if putting the data outside the app and making an API request from the component inside the <iframe> will be allowed, however I don't know why this issue is occurring to in turn know if that too won't be rejected for that same reason. How this can be handled?
The document running in an iframe is isolated from its host. They do not share memory- Angular does not provide a way to synchronize state between a host and an iframe on the page out of the box. The example is actually booting two Angular apps (one inside the frame and one outside). If you are using an iframe for security and isolation purposes, you'll need to devise a way to pass state between the host and the child via postMessage (and be aware that you are running two copies of your application). If this isn't for security/isolation, simply do not use an iframe to contain the child component.
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.
A recurring problem with modern web design can be summed up as "too much sh** all over the place". There're two problems with this: one, it takes up memory and takes longer to load, and two, it visually clutters the webpage.
If I just wanted to solve the second problem, I wouldn't need help. JavaScript can delete DOM nodes and CSS can hide them, so there're already a few visible ways to simply hide parts of a webpage. What I want to do is solve the first problem - make a webpage load faster by not loading certain elements.
I'm pretty sure it's impossible to selectively download certain parts of an HTML file. But once the source is downloaded, the browser doesn't have to actually parse and display all of it, does it?
Of course, if this is done after it's already been parsed and displayed, it would be pointless. So I need a way to tell Chrome what to do before it begins parsing the HTML. Is this possible, and do you think it would significantly reduce load time/memory usage?
Yeah, unfortunately Ive never seen a way of changing the html before Chrome renders it.
But as far as blocking things that that page gets to display then Id recommend just using AdBlock https://chrome.google.com/webstore/detail/gighmmpiobklfepjocnamgkkbiglidom
AdBlock can be used to stop resources (js,images,css,xmlhttprequest) from ever being downloaded (it blocks them in the background using the webRequest api) and can also hide elements using css...its rather effective (just remember to select advanced options in its option page and then when you click the AdBlock button you get "Show the resource list"). Also installing Flashblock can help...or disable plugins in Chromes settings, doing this will make them not load but will still show on the page and then you can make them load.
Totally possible! Meet the newest Chrome API: webRequest, finalized in the current version of Chrome - 17.
Docs for webRequest: http://code.google.com/chrome/extensions/webRequest.html#event-onBeforeRequest
I'm trying to think of a solid way to do this... one suggestion I have is using the 'sub_frame' filter, and watching if it's a like/tweet/social button url
You could also block known analytics stuff... and the list goes on! Have fun! Do you have an email list I can sub to for when you launch? If not, get one and drop me a comment!
(From the comments, here is how a innerHTML hack could work)
//This modLoop constantly peers into and modifies the innerHTML in attempt to modify the html before it's fully processed.
var modLoop = function modLoop(){
var html = document.documentElement.innerHTML
//modify the page html before it's processed!
//like: html = html.replace('//google'sCDN.com/jquery/1.7.1/', chrome.extension.getURL('localjQuery.1.7.1.js'));
//I just pulled that ^ out of nowhere, you'll want to put careful thought into it.
//Then, mod the innerHTML:
document.documentElement.innerHTML = html;
setTimeout(modLoop, 1);
};
var starter = function starter(){
if (document.documentElement.innerHTML && document.documentElement.innerHTML.lengh > 0) {
modLoop();
} else {
setTimeout(starter, 1);
}
};
starter();
This is more of a best practices question rater than something technical.
I'm working on a mobile app using the Flex 4.5 SDK and I'm trying to figure out the best way to handle notification windows. In most cases these windows will be alerting the user to when something goes wrong. Ex: bad login, no data, cannot resolve server.
I'm using a singleton design pattern, I have a Requests class that handles server calls. Most popups will be originating from this class (IOErrorEvents from my loader being used to access the API). Since this class is a singleton and is used from all Views inside the app it is not aware of applications current view. I'm also not sure having this class keep track of the current view and having it push popups on top of it would be best practice.
I'm hoping that I can use PopUpManager to keep track of where to add popups and what popups are currently on the stage. Though all examples I've seen online about this show static Components being used in a views Declarations tag.
I'm really just looking for any examples or input on how you would solve this problem. Any help would be greatly appreciated!
I had the same problem, and sorted it by making an Alert popup component that you can call from anywhere in the code base, and it will pop up in the currently active window. It also has an always visible scrollbar text area which is handy
http://bbishop.org/blog/?p=502
It works for a view navigator application, but if your using a tabbed navigator application, you can add a call for that, or simply change the code to
mainTabbedNavigator = FlexGlobals.topLevelApplication.tabbedNavigator;
currentTab = mainTabbedNavigator.selectedNavigator as ViewNavigator;
Should links to external sites set target=_blank? E.g. I am on www.acme.net and have a link to www.otherplace.net, should that link be:
<a href='http://www.otherplace.net' target='_blank'>otherplace's website</a>
or:
<a href='http://www.otherplace.net'>otherplace's website</a>
I was under the impression that using _blank to sites outside your domain was best practice, but now I am being told otherwise.
Some web idealists will state that you should allow the user to make their own choices when it comes to navigation - I have a lot of sympathy with this view. As web developers, we shouldn't be forcing such decisions on our visitors.
However, I also know that businesses often want to 'retain control' and so insist on spawning a new tab/window for external sites. An I understand this too - It's a very practical approach, particularly when you consider that how many users don't know how to control their own UA.
I often tend to steer a middle course between the two, by adding an image (I'm sure you will have seen many in your time) that indicates which links are external, and a note to indicate that external links will open in a new tab/window.
Not quite as 'pure' as the first option, but at least it is clear to the user how the site will behave.
found this on the w3c site
Checkpoints in this section:
•10.1 Until user agents allow users to
turn off spawned windows, do not cause
pop-ups or other windows to appear and
do not change the current window
without informing the user. [Priority
2] Content developers should avoid
specifying a new window as the target
of a frame with target="_blank".
More info here
the question you need to ask your client is "To what priority level are you aiming to achieve?"
I think it totally depends on your use case.
If you are opening a site in another domain and need to keep your site open, and I think in most cases you do, then use target='_blank'.
As a user, I find it annoying when I click on a link to another domain and it moves me from the original domain. Of course, using ctrl+click in most browsers is a way to defend against this - but why make the user do more work?
It might also be worth to mention that using target attribute is not xhtml valid. I do usually open links in external window or tab because I see that most regular users (not the advanced ones) want it that way so that they can always get back to the site they were on - usually they would go deep into the other site and then it become unfriendly for them having to click back multiple times.
So in terms of usability I think that there's more users that don't use special techniques to manually open links in new window/tab.
With regards to the xhtml validation, you might want to decorate your links with rel="external" or some similar word then use this JS function to handle new window open. I did it like this 99% of time in the last few years.
function externalLinks() {
if (!document.getElementsByTagName) return;
var anchors = document.getElementsByTagName("a");
for (var i = 0; i < anchors.length; i++) {
var anchor = anchors[i];
if (anchor.getAttribute("href") &&
anchor.getAttribute("rel") == "external")
anchor.target = "_blank";
}
}
/**
DOCUMENT LOAD
**/
$(document).ready(function () {
/**
external links
**/
externalLinks();
....
Just don't do it. Using target attributes with links presents complications for assistive technology users who may not know another tab has opened. It becomes a bad experience for these users when the back button does not work in the new tab to take them back to the page they started on. This practice can also be disorienting to people with cognitive disorders. It is best to let users decide where links will open.
You need to predict what your users want. Use target="_blank" if you expect your users will want to stay on the site.
For example if a blog post has a link in the middle of the post, it makes sense to open that link in a new tab since you are expecting the reader to return to the page and continue reading.
Some people argue that the reader could simply click "Back" when they wanted to come back to the page,
But new webpages will have more links to webpages that have more links, what happens is that the reader has to "Back" a couple of times to get back to your blog post. Either that, or he ends up "lost" in the myriad of linked pages and couldn't come back to your blogpost (you can be sure that no one wants to open History and find your page again when they are "lost", unless there is a big incentive to coming back to your page).
As it is a governmental website, this is a tricky question. I regularly see disclaimers for external sites on these type of sites. I don't know if this is a standard or not.
I think the answer is probably down to your own opinion, which should probably be based on usability and integrity.
Just make two buttons for your users: One to open in new tab, and another to abandon the current page in favor of the linked page.
[ www.google.com ]
[Open Google in place of THIS page]