Quanto è pericoloso e.preventDefault(); e può essere sostituito dal monitoraggio keydown/mouse?

Question

Sto lavorando a uno script di monitoraggio per un CRM abbastanza sofisticato per il monitoraggio delle azioni del modulo in Google Analytics. Sto cercando di bilanciare il desiderio di tracciare accuratamente le azioni del modulo con il necessario per per evitare che un modulo non funzioni.

Ora, so che fare qualcosa del genere non funziona.

$('form').submit(function(){ 
_gaq.push(['_trackEvent', 'Form', 'Submit', $(this).attr('action')]); 
}); 

Il DOM scarica prima che questo abbia la possibilità di elaborare.

Così, un sacco di codice di esempio suggerisce qualcosa di simile:

$('form').submit(function(e){ 
e.preventDefault(); 
var form = this; 
_gaq.push(['_trackEvent', 'Form', 'Submit', $(this).attr('action')]); 
//...do some other tracking stuff... 
setTimeout(function(){ 
form.submit(); 
}, 400); 
}); 

Questo è affidabile in most cases, ma mi rende nervoso. Cosa succede se succede qualcosa tra e.preventDefault(); e quando riesco ad attivare l'invio basato su DOM? Ho completamente rotto il modulo.

ho rovistando alcune altre implementazioni di analisi, e ho notato something like this:

$('form').mousedown(function(){ 
_gaq.push(['_trackEvent', 'Form', 'Submit', $(this).attr('action')]); 
}); 
$('form').keydown(function(e){ 
    if(e.which===13) //if the keydown is the enter key 
    _gaq.push(['_trackEvent', 'Form', 'Submit', $(this).attr('action')]); 
}); 

In sostanza, invece di interrompere l'invio di modulo, si preempting assumendo che se qualcuno sta passando con il mouse verso il basso o la digitazione giù su Invio, di quel modulo è presentato. Ovviamente, questo si tradurrà in una certa quantità di falsi positivi, ma elimina completamente l'uso di e.preventDefault();, che nella mia mente elimina il rischio che io possa mai impedire a un modulo di inviare correttamente.

Quindi, la mia domanda:

• E 'possibile prendere lo standard documento di accompagnamento frammento e impedire che da mai impedendo completamente la forma di presentare?
• L'alternativa mousedown/keydown è valida?
• Esistono casi di presentazione che potrebbero non essere disponibili? In particolare, ci sono altri modi per finire di inviare oltre al mouse e alla tastiera entrare? E il browser avrà sempre tempo per elaborare javascript prima di iniziare a scaricare la pagina?

Answer 1

Quelli là fuori che lì Googleplex sono orribili e si sono inventati un giorno che qualcosa del genere doveva accadere e ora, abbastanza sicuro, è successo. Perché non dare a questo un buon tentativo:

$('form').submit(function(e){ 
    e.preventDefault(); 
    var form = this; 
    _gaq.push(['_trackEvent', 'Form', 'Submit', $(this).attr('action')]); 
    //...do some other tracking stuff... 
    _gaq.push(function(){ 
    form.submit(); 
    }); 
    }); 

Che _gaq.push thigamajigger esegue i suoi elementi in sequenza, quindi si dovrebbe andare bene per scherzo.

E no, non so perché ho improvvisamente iniziato a parlare in questo modo.

Answer 2

Un altro approccio:

var pageTracker; 
_gaq.push(function() { 
    pageTracker = _gat._getTrackerByName(); 
}); 

$('form').submit(function(e){ 
    pageTracker._trackEvent('Form', 'Submit', $(this).attr('action')); 
}; 

direi questo modo _trackEvent sarebbe sincrono ma non ho provato.

Answer 3

Uso un approccio diverso e genera lo script di tracciamento eventi nella pagina risultante dall'invio. Puoi chiamarlo rintracciamento dell'evento rinviato.

Ho scritto un blog post con tutti i dettagli sul mio approccio al tracciamento degli eventi nelle azioni di back-end. È prevenuto nei confronti di Java-Struts, ma puoi ottenere l'idea generale.

La logica è che voglio tenere traccia di alcune cose dopo che sono accadute sul lato server. In questo tipo di caso, dopo che il modulo è stato inviato ed elaborato dal server.

Quello che (molto riassunto):

• eventi Conservare in un oggetto legato alla sessione (un elenco/coda)
• Flush questi eventi sulla pagina successiva rendono (generare il javascript e vuota la coda)

Answer 4

C'è un motivo per cui non puoi semplicemente chiamare la chiamata a Google Analytics dal lato server in base al POST che riceve?

Non so in che cosa sia integrato il tuo sistema, ma per esempio, questo progetto PHP emetterebbe una chiamata a GA, rimuovendo così il problema dello scaricamento del DOM, la necessità di rompere il modulo e così via.

http://code.google.com/p/serversidegoogleanalytics/

mi rendo conto che potrebbe essere necessario acquisire un cookie - si potrebbe scrivere il valore in un campo nascosto in forma prima che sia presentata?

Answer 5

e.preventDefault() non deve essere corretto all'inizio della chiamata di funzione. Perché non avere solo una dichiarazione if per verificare se tutto funziona correttamente, e solo chiamare e.preventDefault() se lo fa. Se una qualsiasi funzione nella catena non restituisce il risultato previsto, impostare una variabile submitted su false e non impedire l'impostazione predefinita.

Questo potrebbe essere un po 'più difficile da gestire quando si tratta di qualcosa di asincrono (come il tuo setTimeout, ma ci saranno modi per essere abbastanza sicuri, a seconda di come appare il tuo codice. Quindi puoi verificare se esistono metodi con if (_gaq.push) (ad esempio). Non è possibile garantire il 100% senza testare ogni singola combinazione in ogni browser, ma ritengo che si possa ottenere un risultato abbastanza soddisfacente.

Answer 6

Se è necessario che i moduli funzionino sempre ma tracciamento può essere sacrificato se assolutamente necessario, si potrebbe semplicemente provare/prenderlo

$('form').submit(function(e){ 
    try{ 
     e.preventDefault(); 
     var form = this; 
     _gaq.push('_trackEvent', 'Form', 'Submit', $(this).attr('action')); 
     //...do some other tracking stuff... 
     setTimeout(function(){ 
      form.submit(); 
     }, 400); 
    } catch (e) { 
     form.submit(); 
    } 
}); 

Answer 7

Per espandere la risposta @ Malvolio: Una volta che gaq invia l'evento, verrà elaborato l'elemento successivo nella coda. Ciò significa che la richiesta HTTP dell'evento può interrompersi dal lato client, ma GA riceverà la richiesta. Non preoccuparti di bloccare l'esecuzione dello script fino al termine della risposta. È uno scenario di fuoco e dimentica.