Estrategias para JavaScript console.log/trace, etc

Question

Estoy escribiendo un software bastante grande de JavaScript. Necesito rastrear llamadas, registrar eventos, depurar acciones, a la vez que mantener el rendimiento y la portabilidad en todos los navegadores.

Webkit y Firebug ofrecen objeto de consola con métodos como trace(), log(), error(), warning(), etc. Son geniales, pero ¿qué hago cuando el navegador es IE u Opera?

Imagine que tiene una gran aplicación, seguramente quiere ver todas las inicializaciones que está haciendo, los eventos que está realizando, etc., por lo que lo hago registrar esos. Sin embargo, si solo los registro, el registro no funcionará en los navegadores que no tienen la consola registrada en el DOM. Podría crear un objeto envoltorio:

MyNamespace.Console = {}; 
MyNamespace.Console.log = function(value) { 
if (console!==undefined) { 
    console.log(value); 
} 
else { 
    // What should I do to log events on other browsers? 
} 
} 

Lo anterior hace que por lo que no se producen problemas en IE/Opera, pero ¿cómo conectarse con el IE (uno realmente necesita iniciar sesión con IE!).

Además, si siembro registros en cualquier lugar de mi aplicación, ¿me ralentiza cuando se ejecuta en un entorno de producción? ¿Debería activar/desactivar un DEPURADOR y una simple comprobación antes de iniciar sesión si DEBUG === verdadero, entonces log?

¿Qué pasa con sistemas como Closure Compiler, puede hacerlos para eliminar el registro?

¿Qué ocurre si se produce un error al ejecutar en un entorno de producción y no se ha realizado el registro, cómo se soluciona el problema? Y, de hecho, ¿alguna vez le envía registros de errores de JavaScript (desarrollador) para asegurarse de que sus clientes no tengan problemas? ¿Cómo funciona eso?

Agradezco cualquier comentario/comentario sobre la depuración/registro con JavaScript, esta es la primera vez que escribo una gran aplicación de JavaScript, y francamente, no estoy seguro de qué hacer sobre esto ... la depuración y el inicio de sesión de JavaScript parece un poco sin terminar.

Answer 1

No recomendaría que los datos del registro de informe de la aplicación vuelvan al desarrollador — al menos no sin antes revelar esto a usuarios/clientes.

Sería una práctica más segura registrar errores/eventos/datos de depuración en una matriz inicialmente como sugiere Anurag, y luego enviar periódicamente los datos de registro al servidor web donde se pueden almacenar localmente y hacer un ciclo.Luego, si el cliente tiene problemas, pueden extraer los registros ellos mismos para la depuración y, o bien, se lo envían a usted manualmente o explícitamente le dicen a la aplicación que transfiera los registros a usted, el desarrollador.

El registro en la consola generalmente se usa durante el desarrollo de todos modos. Y se debe usar un indicador de depuración para que no se active todo el tiempo.

Answer 2

Puede simplemente agregar todos los mensajes de registro a una matriz u objeto. Un objeto podría parecer:

var logMessages = { 
    'log': [], 
    'debug': [], 
    'error': [], 
    ... 
}; 

donde la matriz representa mensajes registrados para ese nivel, ordenados cronológicamente o utilizando algún otro criterio.

Simplemente puede definir interfaces idénticas para navegadores que carecen de un console a los que sí lo tienen. Por ejemplo,

if(!window.console) { 
    var console = {}; 

    console.log = function(msg) { 
     .. 
    }; 

    console.debug = function(msg) { 
     .. 
    }; 

    .. 
} 

La lista de mensajes podría ser sincronizado con un servidor, que supongo que seguirán solamente puede ser necesario, los errores, y, posiblemente, las advertencias. Para la captura de todos los errores en la página, configurar una devolución de llamada en window:

window.onerror = function() { 
    .. 
}; 

y el interior de la devolución de llamada, informe al servidor. Esto puede no jugar muy bien con Opera. Ver javascript-global-error-handling

Answer 3

Realice una búsqueda en Google de la consola accord redbird.

Redbird permite el registro remoto directamente desde cualquier navegador compatible con estándares utilizando JavaScript puro. No afecta su servicio web y debería funcionar en Safari, Firefox, Chrome, Opera, MSIE, teléfonos inteligentes, etc.

Redbird es útil para depurar código que funciona bien en un navegador pero que hace algo diferente en otro. Una forma común de registrar y agregar mensajes en diferentes navegadores ayuda a identificar las diferencias.

Usar una bandera DEBUG como sugirió es una buena idea. Muchos mensajes de depuración pueden desacelerar las cosas en un entorno de producción. Otra opción para el entorno de producción es reemplazar la función de registro con una función nula, es decir, una función que no hace nada. Esto evita tener muchas declaraciones de DEPURACIÓN en el código.