We're writing a web app to act as a control panel for our back end, we're solely using JavaScript - All DOM elements are created dynamically, no static HTML at all.
We have a module/plugin type interface, a module is a collection of "views" - A view is essentially a function that contains an initialize method which accepts an arg of a div so it knows where to draw itself.
As a user browses between views, we maintain a history of where they've been and where they are etc. so we can provide back/forward navigation between views as well as saving the state of the views as they navigate.
We provide a breadcrumb trail as well as back and forward buttons. What I'd also like to do is hook the browser back/forward buttons so we can intercept clicks and override it so it browses through the history we're maintaining - When they get to the very first page of the history we're maintaining we would of course not override and let them navigate away from our site.
Is there a common way to do this? Or do browsers explicitly prevent this sort of thing?
Thanks
Use Ben Alman's great jQuery-bbq plugin: http://benalman.com/projects/jquery-bbq-plugin/ which provides a hashchange cross-browser that is used in conjunction with back/forward buttons.
Related
I'm creating a single page application by loading HTML pages inside div element on button click events.
For example :
function loadHome(){
document.getElementById("home-pane").innerHTML='<object type="text/html" data="pages/home.html"></object>';
$("#about-pane").hide();
$("#blog-pane").hide();
$("#forum-pane").hide();
$("#contact-pane").hide();
$("#home-pane").show();
};
Because of it, the URL of application will not change. I'm afraid I would not qualify for Google Ads in case of Single Page Application. Please suggest me an alternative solution so that I would be able to generate different URLs on different click events (Home, About, Contact, Blog etc.) and would able to access those pages via separate links.
I'm kind of new to all these stuff, but I would love to implement all your suggestions and make an extra source of income.
As suggested by #Rory in the comments, you can use the History API
What I would do is, in onclick, just pushState a new URL to the history
Then attach a listener that fires whenever the URL changes. That listener would look at the URL and decide based on it, which 'page' to render.
I am new to squarespace.
My client wants to track the page views for this, I have injected Base pixel code to header of all pages and it worked perfect,
But now she wants to track , if the user click on any buy button on this page
I have no idea how to inject facebook pixel code to a button in squarespace, any idea or reference would be highly appreciated .
Thanks
It sounds like what you want to do is add an "Event Code" either:
A) to the page that the user sees after clicking the button, or
B) to the button itself.
If you're going with the prior option (A), then you'd want to make sure that the page upon which the user lands does in fact indicate the event you're tracking and that users do not arrive to that page for any other purpose. That is why I would lean towards the latter option (B).
You can read more about adding an event code here, and here, but in summary:
Events are actions that happen on your website, either as a result of
Facebook ads (paid) or organic reach (unpaid). The event code lets you
track those actions and leverage them in advertising.
There are two types of events you can send:
Standard events. 9 events we're able to track and optimize your ads for without any additional actions...
Custom events. Actions that are important to your business, but that you can’t use for tracking and optimization without additional action...
...
If you were to consider these buttons to be an "Add to Cart" type-of-action, then you'd use the AddToCart event. To do so, you could use Javascript similar to the following:
<script>
window.Squarespace.onInitialize(Y, function() {
var btns = document.getElementsByClassName("sqs-block-button-element");
var i;
for (i=btns.length-1; i>=0; i--) {
btns[i].addEventListener("click", function() {
fbq("track", "AddToCart");
});
}
});
</script>
You could inject this code using per-page code injection or via site-wide code injection. I would recommend the prior, otherwise all buttons on your site will execute the fbq event code, which is probably undesirable.
Regardless of whether you use site-wide or per-page injection, you may want to better target the buttons using a more specific selector. For example, you could use querySelectorAll and target by href attribute. However, if you use per-page injection, the code I supplied should work; it will apply it to every button on that page.
I have a situation where I have to manually decorate a specific link across my entire website with the Google Analytics linkerParam.
This is to pass the GA client ID from my main site over to my ecommerce site in order to maintain the session.
Normally this would occur automatically through the auto linker settings but there is a server-side redirect page that sits between my site and the ecommerce site.
That redirect page would pass along the GA client ID but it's never given a chance because it's a page on my domain and not the external domain. Auto linker won't work in that situation which is why I need to manually do it myself.
The solution that I've been given basically adds a javascript addEventListener to each link to the redirect page.
That solution does work.
Is it better to use the addEventListener for when people actually click on the specific link to only then decorate that link with the linkerParam?
Or is it better to simply modify each link when the page initially loads?
Thanks
In my custom linkers I decorate the link only after is has been clicked. My reasons (which you may or may not find convincing) are:
if a user hovers over a link I do not want him to see an attached client id
since search engines now execute javascript they might index decorated links
I can decorate links only after they are actually on the page (but I can attach a callback function to links that are created after the fact), so if a user leaves before DOM ready the link is not decorated
On a page with lot's of links decorating all of them actually takes some time and performance for something that I do not really need (after all I only need the clicked link decorated)
As to Ithans comment above (where I think he referred to the DOM rather than the sinister sounding "doom"), since the user leaves the page in any case after clicking the link (you would not decorate in-page linking), so multiple DOM operations are not an issue.
You can change all the links when the page load
something like
var linksToChange = document.querySelectorAll('.theLinkClass');
for (var item of linksToChange ) {
item.href= "http://google.es";
};
I am working on an ember.js (version 1.2) based mobile application and I am trying to find the most idiomatic way of implementing the global menu toggle/back button pattern that is common in many mobile apps. Specifically, its a button that sits on the left side of a fixed-top toolbar, which toggles a hidden drawer main menu when the user is at the app's home/index view, however upon moving into a sub route, the button displays a back arrow, and when clicked, it takes the user back to the previously viewed route (or back to the index route if there is no previous history states, i.e. if the user came into a sub route directly upon loading the app).
Fyi, currently I have my app structured with the fixed-top toolbar and menu toggle/back button in the root application template. Ideally this functionality would work no matter how a routes are being transitioned to, whether via transitionTo(), or {{#link-to}} helpers, ect.
So essentially I want to know if Ember internally maintains any sort of accessible history/log of what routes were transitioned to over the course of the app's lifetime, and also what would be the best way to conditionally change the action that the toggle/back button performs and its display (aka its icon) depending on the current route. And/or is there a way to listen to ember's route change events so I could implement that history myself if need be?
I hate to be the bearer of bad news, but I also hate to leave you hanging.
Ember doesn't keep track of the history, there isn't a general use case for it (especially since the browser keeps track of it for you).
Fortunately you can monitor route changes in the application controller, something like this should get you started (Note I didn't spend time working out an awesome solution that works perfectly, just showed you the basics you need for it, I'll let you figure out the workflow that works well for you)
http://emberjs.jsbin.com/IZAZemEP/1/edit
App.ApplicationController = Em.Controller.extend({
history: [],
hasHistory: function(){
return this.get('history.length')>1;
}.property('history.length'),
watchHistory: function(){
this.get('history').pushObject(this.get('currentPath'));
}.observes('currentPath'),
actions: {
goBack: function(){
// implement your own history popping that actually works ;)
if(this.get('hasHistory')){
this.get('history').popObject();
window.history.back();
this.get('history').popObject(); // get rid of route change here, don't need it
}
}
}
});
I'm having trouble understanding conceptually what I should do while trying to make my first large Javascript web application.
Depending on which tab a user has selected, I show different content inside a container. The content is more than just text and uses different Javascript functions and events. I am using the Yahoo! UI Library's "TabView" implementation, but the way that this issue should be handled would probably apply to other Tab approaches.
What I was thinking of doing was basically the following:
Create separate modules for each tab (e.g. MYAPP.modules.tabCalendar and MYAPP.modules.tabJournal). When the user clicks on a different tab (or navigates with browser buttons to a previous tab state), I could call MYAPP.modules[oldModule].disable() and MYAPP.modules[newModules].enable(). These functions would subscribe or unsubscribe their custom events (for example, a general click handler attached to the container).
An alternate approach to dealing with events might be to have a single global click handler. If the click is inside the container, then determine which tab is currently selected and send the click event to MYAPP.modules[currentTab].onClick().
Or, the global click handler could fire a Custom Event to which the modules have subscribed since page load, and each module's onClick events will run and determine whether or not they should do anything.
There seem to be a lot of options, but I've been having trouble finding resources that talk about the best ways to do things like this. Am I on the right path? How should I handle this?
Use the events already built into TabView to queue your JS to do things.
http://developer.yahoo.com/yui/tabview/#handlingevents
For tab changes you'll be told the previous/next tabs selected and such which should be more than enough for your JS to figure out what it should do. If you want to write a translation layer that'll look at the events and do something based on it that's fine but it's not strictly necessary.
I'm a bit fuzzy on the problem.
Yes, you should modularize your code.
Have each module setup event handlers on the elements in their respective container.
That's it. YUI TabView handles the tab switching so you don't need to enable/disable anything.