2012-04-11 16 views
14

"use strict"; parece increíble, y nos gustaría usarlo en nuestra tienda. Sin embargo, solo lo queremos para que nosotros (los desarrolladores) podamos encontrar cuestiones de rigor; NO queremos hacer que nuestro sitio se rompa para nuestros clientes reales cuando funcionaba bien antes.¿Es "uso estricto" seguro para sitios en vivo?

Ahora, podríamos utilizar un poco de lógica del lado del servidor para lograr esto:

{% if debug %}<script>"use strict";</script>{% endif %} 

... excepto que "use strict" opera sobre una base archivo por archivo, de modo que no lo hará realmente funcionan (bueno, a menos que comencemos el procesamiento en el servidor de todos nuestros archivos JS).

Por lo tanto, mi pregunta es: hacer todas las comprobaciones "use strict" para comprobar cuando se carga la página, o ¿es posible "use strict" para encontrar errores después de que la página se haya cargado? Si es el primero, podemos usar "use strict" y dejar de preocuparnos, porque cargaremos nuestro sitio en desarrollo antes de cargarlo en vivo. Sin embargo, si es el último, parece que no tenemos suerte, ya que no podemos probar todas las condiciones de tiempo de ejecución posibles (y de nuevo, no queremos cometer errores para nuestros usuarios cuando no había errores antes).

+1

También puede usar un buen JSLint durante las etapas finales de desarrollo para asegurarse de que su código sea seguro. – jfriend00

Respuesta

12

Es el último. Mientras está en strict mode, un intérprete de Javascript puede lanzar mensajes de error en el tiempo de ejecución, que no se lanzarán en modo no estricto.

Por otro lado, la mayoría de estos errores son "buenos errores", lo que significa que realmente ayudarán a no romper el código.

Por ejemplo

function foo() { 
    "use strict"; 
    bar = true; 
} 

foo(); 

Esto lanzará

"ReferenceError: assignment to undeclared variable bar" 

en modo estricto, que es una buena cosa. En modo no estricto, solo habríamos creado una variable global llamada bar, que probablemente no sea lo que queríamos. Hay muchas otras situaciones en las que strict mode impide que el programador haga algo estúpido/malo/no deseado y arroja mensajes de error. Pero de nuevo, quiere tener esos errores en lugar de algunos errores extraños.

tener una lectura más adelante MDN

+2

Primero, gracias por esa respuesta; explica totalmente las cosas (y parece que no tengo suerte).Sin embargo, un punto: seguiste diciendo que los errores estrictos son "* bueno *", pero "bueno" es muy subjetivo. Aunque estoy de acuerdo en que las variables globales son malas, la forma en que veo que tiene una página que funcionó bien de repente deja de funcionar para un cliente es MUCHO MÁS peor. Los errores de estricción son solo "buenos" si evitan los errores del cliente; si causan tales errores, son peores que ningún rigor en absoluto (suponiendo que su objetivo final sea un sitio de trabajo para sus clientes, y no solo un código abstractamente "perfecto"). – machineghost

+1

Bueno, como he mencionado. el modo estricto evitará que hagas cosas que finalmente terminarán en peores errores, incluso ocultos. Así que siempre preferiría obtener un error claro en lugar de errores. – jAndy

6

Si he entendido bien, sí, sin duda es posible que el modo estricto para detectar errores después de que la página se ha cargado. Por ejemplo:

'use strict'; 

setTimeout(function() { 
    undefined = 42; // Causes a TypeError 
}, 1000); 

// Click here for a demo.

Lo que puede hacer es bastante simple: usted debe estar minifying el JavaScript cuando se mueve a la producción de todos modos. Solo asegúrate de que el 'use strict' se elimine durante ese proceso de minificación.

De lo contrario, solo asegúrese de que su código esté estrictamente libre de errores. El modo estricto generalmente entra en juego con respecto a la semántica, no por algo extraño que el usuario ingrese o incluso por la sintaxis. No debería ser demasiado difícil atrapar todos los casos. (Pero minimizar y eliminar 'use strict' es una solución mucho mejor.)

Cuestiones relacionadas