funciona - javascript tutorial
¿Cuáles son los principales obstáculos de JavaScript? (13)
El concepto completo de creación de prototipos requiere cierto tiempo para comprenderlo completamente, pero aquí hay algunos inconvenientes comunes:
Olvidar reiniciar la propiedad del constructor después de asignar un objeto prototipo:
var Foo() = function ()
{
this.batz = ''...'';
};
Foo.prototype = new Bar();
Foo.prototype.constructor = Foo;
Si olvida la línea mínima, el new Foo()
ejecutará realmente Bar()
.
Otro inconveniente con el prototipado es iterar sobre objetos / matrices sin filtrar los miembros del prototipo:
for (var i in obj) {
if (obj.hasOwnProperty(i)) {
//stuff...
}
}
La condición adicional saltará cualquier miembro que se herede del prototipo de obj
.
Estoy planeando dar una charla introductoria sobre JavaScript y en el proceso de preparación me pregunté cuáles son los principales escollos en los que caen los novatos.
Sé que he tenido algunos problemas antes de comprender completamente el cierre, pero gran parte del extraño comportamiento en JavaScript no es algo en lo que piense más ...
Entonces, ¿qué peligros debería señalar a los novatos?
Es cierto que he sido culpable de algunos de estos en el pasado, para su diversión son los que están en negrita:
- No saber usos incorrectos (y muy pocos correctos) de
eval
eval("obj."+prop);
- Usando
with
declaraciones - Usando
parseInt(str, base)
sin especificar el argumentobase
. - Usando
this
en funciones de temporizador / devolución de llamada. - Usar expresiones tipo eval en temporizadores
setTimeout("someFunc(myScopedVarWhoops)");
- Pensando jQuery es el nombre del idioma que está codificando
- ¿
$(1).plus(1)
realizar tareas sencillas de JavaScript utilizando un marco de trabajo -$(1).plus(1)
anyone? ;-) - Usar
continue
sin incrementar o ajustar la variable condicional. - Inundando el espacio de nombres global con variables
- Olvidando
var
en o antesfor
declaraciones.for (i=0;i<10;i++)
- Usar un ofuscador y dejar que se ejecute salvaje en su código
- En realidad, no es un escollo, sino inútil:
return condition ? true : false;
return condition ? true : false;
en lugar de lareturn condition;
dereturn condition;
- Al no comentar su código , se aplica a todos los idiomas realmente.
- Usar declaraciones
try...catch...finally
para detectar errores en lugar de usar declaracionesif
para verificar variables. - Intento tontamente detener "ver fuente" bloqueando los clics del mouse derecho en sus páginas (¡era joven * sollozaba * !)
- Usando
{ 0: "Foo", 1:"Bar", 2:"Foobar" }
lugar de[ "Foo", "Bar", "Foobar" ]
- Usando
parseInt()
en la entrada del usuarioparseInt("1,000") // -> 1, wrong! +"1,000" // -> NaN, correct!
Algunos ya mencionados:
- No usar operadores de igualdad estricta (
===
) siempre que sea posible - Establecer controladores de eventos para el valor de retorno de una función en lugar de una referencia a dicha función
- No
;
terminando declaraciones correctamente - Utilizando
for...in
bucles en matrices
Podría pensar en algo más después de haber dormido :-)
Las cadenas de JavaScript no son cadenas de bytes, ni siquiera son cadenas Unicode. Son cadenas UTF-16.
Ejemplo:
> "♫".length
1
> "𐌈".length
2
> "𐌈".charAt(0)
"/uD800"
> "𐌈".charAt(1)
"/uDF08"
> "𐌈" === "/uD800/uDF08"
true
Si lo anterior se ve como basura, culpe a su navegador por tener errores en el manejo de Unicode (o posiblemente por su fuente, por no tener el carácter ''ANTIGUO CARTA ITALIANA'').
Las mayores dificultades que veo para el principiante son comprender el contexto de ejecución (es decir, qué significa "esto" cuando sea y dónde se encuentre) y el sistema prototipo de herencia.
No dejes accidentalmente una coma al final en un literal de definición de objeto o IE fallará y no lo notarás hasta mucho más tarde porque nunca usas IE para el desarrollo y para entonces podría apestar averiguar qué sucedió.
var foo = {
bar: "bar",
baz: "baz",
};
Observe el comentario de @JulianR: en las matrices, IE no falla directamente al arrojar algún error de sintaxis, pero fallará cuando intente usar la matriz porque la coma agregada hace que IE piense que hay un elemento más en la matriz, con un valor undefined
, que de hecho hay. Entonces, si alguna vez tiene un error porque, por alguna razón, el último elemento de una matriz undefined
está undefined
: es una coma.
No es un verdadero error de codificación, sino más bien un pensamiento general:
No confíes en las cosas que está haciendo tu JavaScript, podría haber sido apagado o incluso parcheado . Eso significa que nunca confíe en la validación del lado del cliente. NUNCA.
'''' == ''0'' //false
0 == '''' //true
0 == ''0'' //true
false == ''false'' //false
false == ''0'' //true
false == undefined //false
false == null //false
null == undefined //true
" /t/r/n" == 0 //true
Además de la diferencia entre null
e undefined
. Como se detalla en la tabla anterior, la comparación de null
y undefined
con ==
devuelve true, pero con ===
devuelve false. Este comportamiento tiene sentido una vez que comprende que undefined
es muy diferente de una variable que tiene un valor null
, y algo que contiene el valor undefined
es diferente de algo indefinido.
+
para concatenar cadenas:
var a = ''2'';
var b = 3;
a * b # 6
a - b # -1
a + b # 23
typeof null is object
>>> var i = 1 + undefined; i;
NaN
>>> var i = 1 + null; i;
1
- Crear sitios que no funcionan sin JavaScript
- Usar JavaScript para cosas que deberían hacerse en el servidor
- Usar marcos para tareas simples que no los requieren
- Olvidando declarar variables con
var
- Malentendido (o no comprensión) alcance variable y cierres
- Tratando de resolver desagradables problemas de compatibilidad que los equipos de framework ya han resuelto
- Usando
window.onload = init();
en lugar dewindow.onload = init;
- Equivalencias booleanas (como se mencionó anteriormente)
- Cierres dentro de un bucle.
- Utilizando
for in
variante de bucle para iterar sobre Arrays. - No usar
;
porque es "opcional". -
this
(solo ... en general :)) - No usando
var
- Sabiendo que
obj.ref === obj["ref"]
- Closures , también conocidos como funciones lambda, ten cuidado con las pérdidas de memoria.
- Las diferencias de navegador, las pruebas en Internet Explorer y al menos otro navegador son imprescindibles. En general, se deben evitar las funciones que solo funcionan en algunos navegadores o funcionan de manera diferente en diferentes navegadores. Si esto no es posible, la bifurcación específica del navegador se hace mejor detectando las características del navegador en lugar de las versiones del navegador. Esto aumenta la posibilidad de que el código funcione en navegadores y navegadores futuros que no se han probado.
- Ponerse demasiado atrapado en la abstracción del marco de jQuery o Ajax , y no conocer el JavaScript subyacente lo suficiente como para saber cómo solucionar los problemas del marco.
- Sin saber que JavaScript se puede usar hasta cierto punto para escribir código OOP. De hecho, puede proporcionarle un marco de OOP muy básico con objetos.
- Sensibilidad de mayúsculas y minúsculas (si eres desarrollador de VB.NET )
- Protección de IP: sabiendo que puedes ofuscar JavaScript, pero el código fuente que coloques allí será muy fácil de robar e invertir. Esto podría no ser un problema dependiendo de la complejidad de la aplicación del lado del cliente que está escribiendo.
No puedo pensar en nada más, pero espero que esto ayude.