Los siete pecados capitales de la implementación de JavaScript

 

 

 


Índice
  1. Pecados de nuestros padres: código específico del navegador
    1. Bibliotecas al rescate
  2. Pecado #1: No jugar bien con otros guiones
  3. Pecado #2: Creer en lugar de probar
  4. Pecado #3: Usar la tecnología incorrecta para el trabajo
  5. Pecado #4: Dependiendo de JavaScript y ciertos dispositivos de entrada
    1. Cuando la dependencia de JavaScript está bien (hasta cierto punto)
    2. Considere los casos de uso y el mantenimiento
  6. Pecado #5: Hacer el mantenimiento innecesariamente difícil

Usar JavaScript se ha vuelto cada vez más fácil en los últimos años. Mientras que en el pasado necesitábamos conocer las peculiaridades de cada navegador, ahora muchas bibliotecas como jQuery, YUI, Dojo y MooTools permiten a alguien que ni siquiera conoce JavaScript arreglar documentos HTML aburridos con efectos impresionantes y brillantes. Al aprovechar el motor de selección de CSS, nos hemos alejado de la complejidad y las inconsistencias del DOM y hemos hecho las cosas mucho más fáciles.

 

Sin embargo, si nos fijamos en parte del código que se ha publicado, parece que hemos dado un paso atrás. Al obtener un acceso más fácil, también nos volvimos un poco descuidados con nuestro código. Encontrar código jQuery claramente estructurado y fácil de mantener es bastante difícil, razón por la cual muchos complementos hacen lo mismo. Escribir uno usted mismo es más rápido que intentar comprender lo que han hecho otros desarrolladores.

Asegúrese de consultar los siguientes artículos:

  • Siete cosas de JavaScript que desearía saber mucho antes en mi carrera
  • Eventos de JavaScript y respuesta al usuario
  • Una mirada rápida a las matemáticas de las animaciones con JavaScript

Sin embargo, las reglas para un JavaScript sólido, fácil de mantener y seguro no han cambiado. Entonces, repasemos los siete pecados del desarrollo de JavaScript que le morderán el trasero cuando tenga que mantener el código más adelante o entregárselo a otra parte.

 

Todos hemos tenido que trabajar con código escrito por otras personas. Nos hemos desesperado por la falta de mantenibilidad y documentación, así como por una lógica extraña. Curiosamente, como desarrolladores, comenzamos a ver esto como algo normal y nos acostumbramos a ignorar el trabajo de otras personas y, en su lugar, a escribir código nuevo para los mismos problemas una y otra vez, como si inconscientemente estuviéramos tratando de asegurar nuestros trabajos dejando atrás código que no se puede mantener. código que sólo nosotros entendíamos, mientras nos quejábamos de que no existían buenas soluciones.

Pecados de nuestros padres: código específico del navegador

Uno de los principales obstáculos que nos impidió evolucionar como desarrolladores fue que JavaScript era en gran medida específico del navegador.

Esto se debió principalmente a que los navegadores no eran compatibles con los estándares (o se enviaron antes de que los órganos rectores acordaran los estándares) y a que tuvimos que entregar nuestro trabajo antes de la competencia y sin extender el plazo demasiado optimista establecido por nuestros gerentes de proyecto.

Esta es una de las razones por las que Internet Explorer 6 se niega a morir. Cientos de costosos paquetes de software que se utilizan en oficinas de todo el mundo se crearon cuando este navegador era lo último en tecnología. Esto, y la monocultura que propugnaba el uso de un solo proveedor de software para todo, desde el sistema operativo hasta los documentos, las hojas de cálculo y el navegador, es la razón por la que las empresas ahora no pueden simplemente descontinuar su soporte. También significa que las versiones más nuevas de IE siempre tendrán que soportar los errores de renderizado de IE6 de una forma u otra. IE6 es el Frankenstein de Internet, que persigue a sus creadores, terriblemente incomprendido por la gente del pueblo, que preferiría matarlo, quemarlo y bailar a su alrededor antes que encontrarle algún sentido.

La buena noticia es que hoy en día no encontrarás muchos guiones que comiencen if(document.all){}y continúen con else if(document.layers){}. Si encuentra uno, envíe a su creador un breve correo electrónico animándolo a seguir adelante o, mejor aún, a redirigir su sitio web a un script mejor que realmente se esté manteniendo.

Bibliotecas al rescate

El trabajo de las bibliotecas de JavaScript como jQuery, YUI, MooTools, Dojo y Glow es hacer que el desarrollo de JavaScript sea predecible y aliviar a los desarrolladores del infierno que llamamos soporte del navegador. En otras palabras, corrigen errores aleatorios en los navegadores y nos liberan para adoptar estándares sin preocuparnos de que ciertos navegadores no los reconozcan.

Por ejemplo, el método DOM getElementById(id)debería ser sencillo: busque el elemento con el ID idy devuélvalo. Pero debido a que algunas versiones de IE y Opera también devuelven elementos que tienen el nameatributo de id, jQuery resuelve el problema de esta manera :

 

var elem;elem = document.getElementById( match[2] );if ( elem ) {// Handle the case where IE and Opera return items// by name instead of IDif ( elem.id !== match[2] ) {return rootjQuery.find( selector );}// Otherwise, we inject the element directly into the jQuery objectthis.length = 1;this[0] = elem;}

Aquí es donde las bibliotecas son tremendamente útiles y es por eso que las bibliotecas de JavaScript llegaron para quedarse. Los navegadores siempre harán las cosas mal y los usuarios finales no actualizarán los navegadores antiguos, ya sea debido a las regulaciones de la empresa antes mencionadas o porque a la gente simplemente no le importa mantenerse al día.

Entonces, si bien la práctica de crear software para ciertos navegadores está en declive (al menos para JavaScript; con CSS, tenemos otro dolor de cabeza por delante), todavía tenemos que ser conscientes de ciertos pecados.

Pecado #1: No jugar bien con otros guiones

Aquí está el primero, que todavía vemos mucho en la Web. Lamentablemente, es muy común en el código de demostración para API y servicios web: variables globales, funciones y controladores de eventos DOM-1.

¿Qué quiero decir con estos? Considera lo siguiente:

  • Cada script en el documento HTML tiene los mismos derechos que los demás y puede, si es necesario, sobrescribir lo que otros scripts han hecho antes.
  • Si define un nombre de variable o función y alguna otra inclusión usa el mismo nombre, se sobrescribirá el inicial.
  • Lo mismo se aplica a los controladores de eventos si los adjunta a la antigua usanza onEvent.

Digamos que tienes el script script_one.js :

x = 5;function init(){ alert('script one init'); document.getElementsByTagName('h1')[0].onclick = function(){ this.style.background = 'blue'; }}alert('x is '+x);window.onload = init;

E inmediatamente después de este, incluye otro script, script_two.js :

x = 10; function init(){ alert('script two init'); document.getElementsByTagName('h1')[0].onclick = function(){ this.style.color = 'white'; } } alert('x is '+x); window.onload = init;

Si abre este documento en un navegador, encontrará que x pasa de 5 a 10 y que init()nunca se llama al primero. No script two init alert()aparece ni aparece h1un fondo azul cuando haces clic en él. Sólo el texto se vuelve blanco, lo que lo hace invisible.

La solución no es usar onEventcontroladores, sino los controladores de eventos DOM nivel 2 adecuados (no funcionan en IE, pero no nos preocupemos por eso por el momento; recuerde, para eso están las bibliotecas). Además, incluya sus funciones en otra con un nombre más exclusivo para evitar que se anulen entre sí.

var scriptOne = function(){ var x = 5; function init(){ alert('script one init'); document.getElementsByTagName('h1')[0].addEventListener( 'click', function(e){ var t = e.target; t.style.background = 'blue'; }, false ); } alert('x inside is '+x); return {init:init};}();window.addEventListener('load',scriptOne.init,false);alert('x outside is '+x);var scriptTwo = function(){ var x = 10; function init(){ alert('script two init'); document.getElementsByTagName('h1')[0].addEventListener( 'click', function(e){ var t = e.target; t.style.color = 'white'; }, false ); } alert('x inside is '+x); return {init:init};}();window.addEventListener('load',scriptTwo.init,false);alert('x outside is '+x);

Si ejecuta esto en un navegador (no en Internet Explorer 6), todo aparecerá como espera: x es primero 5, luego 10 en el interior y el encabezado se vuelve azul y blanco cuando hace clic en él. init()También se llaman ambas funciones.

 

También obtienes un error. Debido xa que no está definido fuera de las funciones, alert(‘x outside is ‘+x);nunca funciona.

La razón es que al mover las xfunciones scriptOney scriptTwoy agregar la varpalabra clave delante de ellas, las hemos convertido en parte de esas funciones pero las hemos ocultado del mundo exterior. Esto se llama cierre y se explica en detalle aquí . Probablemente sea la característica más poderosa de JavaScript.

Al utilizar cierres y varpalabras clave, no tendrá el problema de que variables con nombres similares se anulen entre sí. Esto también se aplica en jQuery: debes asignar espacios a tus funciones .

Esto puede resultar difícil de entender, así que veamos un ejemplo más sencillo:

var x = 4;var f = 3;var me = 'Chris';function init(){}function load(){}

Todas estas son variables y funciones globales ahora. Cualquier otro script que tenga las mismas variables las anulará.

Puedes anidarlos en un objeto para evitar esto:

var longerAndMoreDistinct = { x : 4, f : 3, me : 'Chris', init : function(){}, load : function(){}}

De esa manera, sólo el longerAndMoreDistinctes global. Si desea ejecutar esta función, ahora debe llamar longerAndMoreDistinct.init()en lugar de init(). Puedes llegar mea ella longerAndMoreDistinct.mey así sucesivamente.

No me gusta esto porque tengo que cambiar de una notación a otra. Entonces, podemos hacer lo siguiente:

var longerAndMoreDistinct = function(){ var x = 4; var f = 3; var me = 'Chris'; function init(){} function load(){} }();

Se define longerAndMoreDistinctcomo el resultado de una función sin nombre que se ejecuta inmediatamente (esto está ()en la última línea). Esto ahora significa que todas las variables y funciones internas existen solo en este mundo y no se puede acceder a ellas desde afuera en absoluto. Si desea que sean accesibles desde el exterior, debe devolverlos al mundo exterior:

var longerAndMoreDistinct = function(){ var x = 4; var f = 3; var me = 'Chris'; function load(){} return { init:function(){} } }();

Ahora init()está disponible longerAndMoreDistinct.init()nuevamente. Esta construcción de envolver cosas en una función anónima y devolver algunas de ellas se llama patrón de módulo y mantiene sus variables seguras. Personalmente, todavía odio el cambio en la sintaxis, así que se me ocurrió el patrón de módulo revelador . En lugar de devolver la función real, todo lo que hago es devolverle un puntero:

 

var longerAndMoreDistinct = function(){ var x = 4; var f = 3; var me = 'Chris'; function load(){} function init(){} return { init:init } }();

De esta manera, puedo hacer que las cosas estén disponibles o no simplemente agregándolas al objeto que se devuelve.

Si no necesita darle nada al mundo y solo desea ejecutar algún código y mantener seguras todas sus variables y nombres de funciones, puede prescindir del nombre de la función:

(function(){ var x = 4; var f = 3; var me = 'Chris'; function load(){} function init(){}})();

Usar vary empaquetar código en esta construcción la hace inaccesible para el mundo exterior, pero aún así hace que se ejecute.

Puede que esto le parezca complejo, pero existe una buena forma de comprobar su código. JSLint es un validador para JavaScript, muy parecido a los validadores HTML o CSS, y le indica todos los aspectos que pueden estar mal en su código.

Pecado #2: Creer en lugar de probar

El próximo gran pecado relacionado con la implementación de JavaScript es esperar que todo salga bien: que cada parámetro esté en el formato correcto, que cada elemento HTML que intente mejorar esté realmente disponible y que cada usuario final ingrese información en el formato correcto. Este nunca será el caso, y esa última suposición es especialmente mala porque permite a usuarios malintencionados inyectar código peligroso.

Cuando escribes JavaScript y lo entregas al mundo o lo integras en un producto que será mantenido por un tercero, un poco de paranoia es algo bueno.

typeofes tu amigo. Las expresiones regulares son tus amigas. indexOf()y splitson lengthtus amigos. En otras palabras, haga todo lo posible para asegurarse de que los datos entrantes tengan el formato correcto.

Obtendrá muchos errores con JavaScript nativo; Si haces algo mal, sabrás lo que pasó. Lo molesto de la mayoría de las bibliotecas de JavaScript es que cuando no logran ejecutar alguna funcionalidad, lo hacen en silencio. El mantenedor se queda adivinando y tiene que ejecutar todo el código y comenzar a depurar con puntos de parada (o, ¡estremecimiento!) alerts()para aplicar ingeniería inversa donde ingresó el código inestable. Para evitar esto, simplemente incluya todo lo que pueda en un caso de prueba en lugar de intentar acceder a él.

Pecado #3: Usar la tecnología incorrecta para el trabajo

El mayor problema con JavaScript ocurre cuando utilizas la herramienta incorrecta para el trabajo. Hace que el mantenimiento sea una pesadilla y deteriora la calidad del código. Utilice herramientas para los trabajos para los que fueron diseñadas. Esto significa: Guia y trucos de Tiktok

  • El contenido y el marcado absolutamente esenciales deben estar en HTML, independientemente del entorno en el que se mostrarán.
  • Cualquier elemento de "apariencia" debe poder mantenerse a través de CSS. No debería tener que buscar en JavaScript para cambiar un color.
  • Cualquier interacción con el usuario que vaya más allá de los efectos de desplazamiento (que, por definición, son una invitación a interactuar y no la interacción en sí, porque son inaccesibles para los usuarios del teclado) debe realizarse con JavaScript.

La razón principal por la que este sigue siendo un enfoque de desarrollo válido, pragmático y sensato es que a medida que las tecnologías web se confunden (por ejemplo, puedes crear contenido con CSS y JavaScript, animar y transformar en CSS y, si realmente quieres, pintar con HTML), las habilidades y los intereses de las personas en estas diferentes tecnologías varían bastante.

 

Los aficionados al marcado semántico no están muy interesados ​​en aplicar cierres en JavaScript. Los desarrolladores de JavaScript no están muy interesados ​​en el orden de los elementos en CSS. Y los fanáticos de CSS no están interesados ​​en aprender cómo hacer que una animación JavaScript se ejecute sin parpadeos.

Esto da como resultado que los mismos problemas se resuelvan una y otra vez, sólo que con diferentes tecnologías. Este es un problema que afecta a todo el mercado: muchos de los trucos más modernos de Canvas se realizaron en Flash hace años, se debatió su impacto y se solucionaron sus problemas.

Mi ejemplo favorito de esto es cuando la gente escribe bucles para ocultar muchos elementos en la página y que estén disponibles más adelante.

Di que este es tu HTML:

h2Section 1/h2div pSection 1 content/p/divh2Section 2/h2div pSection 2 content/p/divh2Section 3/h2div pSection 3 content/p/divh2Section 4/h2div pSection 4 content/p/div

La solución jQuery normal para esto sería:

$(document).ready(function(){ $('.section').hide(); $('h2').click(function(e){ $(this).next().toggle(); })});

Y luego te das cuenta de que sería genial hacer que el estilo de la sección actual se desvíe del de las otras secciones.

$(document).ready(function(){ $('.section').hide(); $('h2').click(function(e){ $(this).next().toggle(); $(this).next().css('background','#ccc'); $(this).next().css('border','1px solid #999'); $(this).next().css('padding','5px'); })});

Algunas cosas están mal en esto. Para empezar, ha dificultado el mantenimiento de esto al controlar la apariencia en JavaScript, no en CSS (más sobre esto más adelante). En segundo lugar, el rendimiento: si bien jQuery es sorprendentemente rápido, todavía hay mucho código oculto bajo el capó en $(‘.section’).hide(). El último y muy doloroso problema de rendimiento son las líneas copiadas y pegadas que configuran el CSS. No le pidas a jQuery que busque al siguiente hermano cuatro veces y le haga algo. Puede almacenar el next()en una variable, pero ni siquiera eso es necesario si lo encadena. Si realmente necesitas configurar mucho CSS en jQuery, usa un mapa:

$(document).ready(function(){ $('.section').hide(); $('h2').click(function(e){ $(this).next().toggle().css({ 'background':'#ffc', 'border':'1px solid #999', 'padding':'5px' }); })});

¿Qué sucede si luego desea permitir que solo uno de ellos esté abierto en cualquier momento? Los desarrolladores sin experiencia harían algo como esto:

$(document).ready(function(){ $('.section').hide(); $('h2').click(function(e){ $('.section').hide(); $(this).next().toggle().css({ 'background':'#ffc', 'border':'1px solid #999', 'padding':'5px' }); })});

Esto funciona, pero estás recorriendo el documento y accediendo mucho al DOM, lo cual es lento. Puedes aliviar esto manteniendo la sección abierta actual en una variable:

 

$(document).ready(function(){ var current = false; $('.section').hide(); $('h2').click(function(e){ if(current){ current.hide(); } current = $(this).next(); current.toggle().css({ 'background':'#ffc', 'border':'1px solid #999', 'padding':'5px' }); })});

Predefina la sección actual como falsey configúrela cuando haga clic en el primer encabezado. Luego se ocultará currentsolo si es verdadero, eliminando así la necesidad de realizar otro bucle a través de todos los elementos que tengan la clase section.

Pero aquí está lo interesante: si lo único que quieres es mostrar y ocultar secciones, ¡no necesitas ningún bucle! CSS ya revisa el documento cuando representa y aplica clases. Sólo necesita darle al motor CSS algo a lo que aferrarse, como una clase para body:

$(document).ready(function(){ $('body').addClass('js'); var current = null; $('h2').click(function(e){ if(current){ current.removeClass('current'); } current = $(this).next().addClass('current'); })});

Al agregar la clase jsal cuerpo del documento y alternar la clase currentpara la sección actual, mantienes el control de la apariencia en CSS:

style type="text/css" media="screen" .section{ border:1px solid #999; background:#ccc; } .js .section{ display:none; } .js .current{ display:block; border:1px solid #999; background:#ffc; }/style

Lo bueno de esto es que el diseñador y mantenedor de CSS podrá reutilizar el identificador. Cualquier cosa sin el .jsselector sería la versión no habilitada para secuencias de comandos de una parte del documento, y cualquier cosa con el .jsselector se aplica solo cuando JavaScript está disponible. Y sí, deberías pensar en el caso cuando no sea así.

Pecado #4: Dependiendo de JavaScript y ciertos dispositivos de entrada

Existe una gran discusión sobre la necesidad de considerar entornos que no sean JavaScript hoy en día, pero aquí hay un hecho: JavaScript se puede desactivar y cualquier JavaScript podría interrumpir la página de los otros scripts que se incluyen. Dada la fragilidad del código que puede estar ejecutándose junto con el suyo y la inestabilidad de las conexiones inalámbricas y móviles, yo, por mi parte, quiero crear una cosa: un código que funcione .

Por lo tanto, asegurarse de que el uso más básico de su producto no dependa de JavaScript no solo es bueno, sino también esencial si espera que la gente realmente use el producto.

No hay absolutamente nada de malo en utilizar JavaScript en gran medida. Por el contrario, hace que la Web sea mucho más fluida y nos ahorra mucho tiempo si se hace correctamente. Pero nunca debes prometer una funcionalidad que no funciona. Y si confías en JavaScript, esto es exactamente lo que estás haciendo. Ya cubrí en detalle los efectos del JavaScript incorrecto en los artículos de seguridad , pruebas de JavaScript y AJAX aquí en Smashing Magazine, pero una vez más, aquí hay algunos pasos simples que puede seguir para asegurarse de no romper su promesa a los usuarios finales. :

 

  • Cualquier cosa vital para la funcionalidad de su producto no debería requerir JavaScript. Los formularios, los enlaces y los scripts de redireccionamiento y validación del lado del servidor son tus amigos.
  • Si algo depende de JavaScript, constrúyalo con JavaScript y agréguelo al documento usando el DOM o el método equivalente en la biblioteca de su elección.
  • Si agrega la funcionalidad JavaScript, asegúrese de que funcione con el teclado y el mouse. Los controladores de clic y envío son a prueba de balas, mientras que los eventos de tecla y mouse son inestables y no funcionan en dispositivos móviles.
  • Al escribir un código de back-end inteligente que reconozca cuándo JavaScript requiere datos en lugar de crear API que representen HTML, se evita tener que realizar un doble mantenimiento, que es un argumento que muchos de los fanáticos de “Todos habilitan JavaScript” plantean con frecuencia. . Como prueba de esto, consulte la presentación sobre creación de aplicaciones web usando YQL y YUI que hice hace unas semanas (video en inglés y alemán).

Cuando la dependencia de JavaScript está bien (hasta cierto punto)

Muchos malentendidos sobre la dependencia de JavaScript surgen de personas que hacen declaraciones generales basadas en los entornos en los que trabajan.

Si usted es un ingeniero de Google que trabaja en Gmail, le resultará difícil pensar por qué se molestaría en trabajar sin JavaScript. Lo mismo ocurre con los desarrolladores de widgets que trabajan en widgets OpenSocial, aplicaciones móviles, widgets de Apple y Adobe Air. En otras palabras, si su entorno ya depende de JavaScript, entonces no se moleste en recurrir a una alternativa.

Pero no tome estos entornos cerrados y aplicaciones extremas como el estándar por el cual deberíamos medir JavaScript. El mayor poder y el mayor problema de JavaScript es su versatilidad. Decir que todos los sitios web pueden soportar JavaScript porque Gmail lo necesita es como decir que todos los autos deberían tener un botón de inicio porque funcionan muy bien en los híbridos, o que los autos híbridos deberían tener tanques enormes y recogedores de vacas porque funcionan muy bien en los Hummers. El conjunto de características técnicas de un producto depende de su implementación y del mercado objetivo. Las diferentes aplicaciones tienen diferentes funcionalidades básicas que deben cumplirse para llegar a la mayor audiencia y no bloquear a las personas.

Considere los casos de uso y el mantenimiento

Un aspecto fascinante del código dependiente de JavaScript es que, en muchos casos, la gente simplemente no ha considerado todos los casos de uso (aquí hay un gran ejemplo). Tome el siguiente HTML:

form action="#" div label for="search"Search/label input type="text" value="kittens" input type="submit" value="go" /div/formdiv/div

Sin JavaScript, esto no hace nada en absoluto. No hay ningún actionatributo sensible y el campo de texto no tiene ningún nameatributo. Entonces, incluso cuando envíe el formulario, el servidor no obtendrá la información que el usuario ingresó.

 

Usando jQuery y una fuente de datos JSON como YQL , puedes hacer una búsqueda pura de JavaScript con esto:

$('#s').click(function(event){ event.preventDefault(); $('ul/').appendTo('#results'); var url = $.getJSON('https://query.yahooapis.com/v1/public/yql?'+ 'q=select%20abstract%2Cclickurl%2Cdispurl%2Ctitle%20'+ 'from%20search.web%20where%20query%3D%22'+ $('#search').val() + '%22format=json'+ 'callback=?', function(data){ $.each(data.query.results.result, function(i,item){ $('lih3a href="'+item.clickurl+'"'+ item.title+' ('+item.dispurl+')/a/h3p'+ (item.abstract || ’) +'/p/li'). appendTo("#results ul"); }); });});

Esto funciona... a menos, por supuesto, que seas como yo y prefieras enviar formularios presionando "Entrar" en lugar de hacer clic en el botón "Enviar". A menos que recorra todo el formulario y me concentre en el botón "Enviar", no obtengo nada.

Entonces, eso es lo primero que hay que arreglar. Si crea formularios, nunca utilice un controlador de clic en el botón. En su lugar, utilice el evento de envío del formulario. Esto detecta tanto los casos de hacer clic en "Enviar" como de presionar "Entrar". Con un cambio, ahora admites a todos los usuarios de teclados, y todo el cambio está contenido en la primera línea:

$('#f').submit(function(event){ event.preventDefault(); $('ul/').appendTo('#results'); var url = $.getJSON('https://query.yahooapis.com/v1/public/yql?'+ 'q=select%20abstract%2Cclickurl%2Cdispurl%2Ctitle%20'+ 'from%20search.web%20where%20query%3D%22'+ $('#search').val() + '%22format=json'+ 'callback=?', function(data){ $.each(data.query.results.result, function(i,item){ $('lih3a href="'+item.clickurl+'"'+ item.title+' ('+item.dispurl+')/a/h3p'+ (item.abstract || ’) +'/p/li'). appendTo("#results ul"); }); });});

Ahora hemos cubierto el primer caso. Pero sin JavaScript, el formulario todavía no hace nada. Y otro problema nos lleva al siguiente pecado de escribir JavaScript.

Pecado #5: Hacer el mantenimiento innecesariamente difícil

Una cosa que mantiene el código excelente fuera de la Web es que nuestro entorno de trabajo, plazos y prácticas de contratación condicionan a los desarrolladores a crear código para una publicación rápida, sin considerar lo difícil que será mantener ese código más adelante. Una vez llamé a JavaScript la bicicleta del pueblo del diseño web ( diapositivas aquí ): cualquiera puede dar un paseo. Debido a que el código está disponible abiertamente, los futuros mantenedores podrán trastear con él y ampliarlo como quieran.

Lo triste es que cuanto más difícil sea mantener el código, más errores se le agregarán, lo que hará que parezca más una sopa de letras que un script organizado.

Tomemos el ejemplo anterior. Aquellos de ustedes que no han trabajado con YQL y JSON-P para AJAX entre dominios sin duda tuvieron un "¿Qué?" momento mirando el código. Además, mantener una gran cantidad de HTML en JavaScript fácil de seguir es difícil, y ¿adivinen qué es lo primero que se cambia cuando aparece un nuevo diseño para la página? Exacto: el HTML y el CSS. Entonces, para que sea más fácil de mantener, yo trasladaría todo el trabajo al back-end, haciendo así que el formulario funcione sin JavaScript y manteniendo el mantenimiento de todo el HTML en el mismo documento:

?phpif(isset($_GET['search'])){ $search = filter_input(INPUT_GET, 'search', FILTER_SANITIZE_ENCODED); $data = getdata($search); if($data-query-results){ $out = 'ul'; foreach($data-query-results-result as $r){ $out .= "li h3 a href="{$r-clickurl}"{$r-title} span({$r-dispurl})/span /a /h3 p{$r-abstract}/p /li"; } $out .= '/ul'; } else { $out = 'h3Error: could not find any results/h3'; }}if($_SERVER['HTTP_X_REQUESTED_WITH']!=’){ echo $out; die();}?!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "https://www.w3.org/TR/html4/strict.dtd"htmlhead meta http-equiv="Content-Type" content="text/html; charset=UTF-8" titleAjax Search with PHP API/title link rel="stylesheet" href="styles.css" type="text/css"/headbody form action="independent.php" div label for="search"Search/label input type="text" value="kittens" name="search" input type="submit" value="Go" /div /form div?php if($out!=’){echo $out;}?/div script src="jquery.js"/script script src="ajaxform.js"/script/body/html?phpfunction getdata($search){ $url = 'https://query.yahooapis.com/v1/public/yql?'. 'q=select%20abstract%2Cclickurl%2Cdispurl%2Ctitl 




Tal vez te puede interesar:

  1. ¿Deberían abrirse los enlaces en ventanas nuevas?
  2. 24 excelentes tutoriales de AJAX
  3. 70 técnicas nuevas y útiles de AJAX y JavaScript
  4. Más de 45 excelentes recursos y repositorios de fragmentos de código

Los siete pecados capitales de la implementación de JavaScript

Los siete pecados capitales de la implementación de JavaScript

Índice Pecados de nuestros padres: código específico del navegador

programar

es

https://pseint.es/static/images/programar-los-siete-pecados-capitales-de-la-implementacion-de-javascript-769-0.jpg

2024-04-04

 

Los siete pecados capitales de la implementación de JavaScript
Los siete pecados capitales de la implementación de JavaScript

Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

 

 

Top 20