jQuery se basa en DOM y AngularJS se basa en datos. Aquí hay un artículo que lo explica muy bien. Se recomienda leerlo.
Este artículo proviene de Cómo hacerlo. "Pienso en AngularJS" si estoy en StackOverFlow. La respuesta más votada a la pregunta "¿tiene experiencia en jQuery?" Esta respuesta ha recibido más de 3000 votos. El que respondió, Josh David Miller, es un desarrollador activo en la comunidad de código abierto y cofundador de Emergenesia. Esta respuesta fue traducida originalmente y publicada en su blog por el arquitecto de la nube de datos Han Zheng. Después de obtener el consentimiento de Josh, el propio Han Zheng la recomendó a InfoQ para compartirla y se publicó aquí después de ser revisada por el editor de la comunidad de InfoQ, Cui Kang.
1. No diseñes la página primero y luego uses operaciones DOM para cambiar su presentación.
En jQuery, normalmente diseñas una página y luego le das efectos dinámicos. Esto se debe a que jQuery está diseñado para expandir el DOM y crece locamente con esta simple premisa.
Pero en AngularJS, tienes que pensar en la arquitectura en tu cabeza desde el principio. Debe comenzar con la función que desea completar, luego diseñar la aplicación y finalmente diseñar la vista, en lugar de "Tengo un fragmento DOM de este tipo y quiero que logre efectos XXX".
2. No uses AngularJS para mejorar jQuery
Del mismo modo, no empieces con el siguiente pensamiento: usa jQuery para hacer X, Y y Z, y luego simplemente combina AngularJS. A esto se suman los modelos con controladores. Esto puede parecer muy tentador al principio, por lo que siempre recomiendo a los recién llegados a AngularJS que eviten usar jQuery en absoluto, al menos no hasta que se acostumbren a desarrollar en el "Modo Angular".
Veo muchos desarrolladores en la lista de correo creando estas soluciones complejas usando complementos jQuery que tienen 150 o 200 líneas de código, y luego pegándolos en AngularJS usando un montón de funciones de devolución de llamada y $apply. Parecía complicado y difícil de entender; ¡pero finalmente lo lograron! El caso es que, en la mayoría de los casos, estos complementos de jQuery se pueden reescribir con muy poco código AngularJS y todo es simple y directo de entender.
La conclusión aquí es: cuando elija una solución, primero "piense en AngularJS" si no puede pensar en una solución, busque ayuda en la comunidad; , entonces considere usar jQuery. Pero no dejes que jQuery sea tu muleta y nunca dominarás realmente AngularJS.
3. Piense siempre desde una perspectiva arquitectónica
En primer lugar, debe saber que una aplicación de una sola página es una aplicación, no una página web. Entonces, además de pensar como un desarrollador de clientes, también debemos pensar como un desarrollador de servidores. Debemos pensar en cómo dividir nuestras aplicaciones en componentes independientes, escalables y comprobables.
Entonces, ¿cómo hacerlo? ¿Cómo "pensar en AngularJS"? Aquí hay algunos principios básicos, en comparación con jQuery.
En jQuery, cambiamos la vista mediante programación.
- Inicio
- Menú 1
- Menú 2
En jQuery, habilitaremos este menú desplegable en la lógica de la aplicación de esta manera:
$('.main-menu').dropdownMenu();
Cuando nos centramos sólo en la vista, ninguna funcionalidad (comercial) es inmediatamente obvia. Para aplicaciones pequeñas, esto no tiene nada de malo. Pero en aplicaciones más grandes, las cosas se vuelven difíciles de entender y mantener.
En AngularJS, las vistas se basan en funciones de vista. La declaración ul se verá así:
Estos dos métodos hacen lo mismo. pero en la versión AngularJS cualquiera que mire esta plantilla puede saber lo que va a pasar. Cada vez que un nuevo miembro se une al equipo de desarrollo, verá esto y sabrá que hay una directiva llamada dropdownMenu que actúa sobre esta etiqueta. No necesita confiar en la intuición para adivinar la función del código ni mirar ningún código; La vista misma nos dice lo que sucede. Mucho más claro.
Los desarrolladores que entran en contacto con AngularJS por primera vez suelen hacer esta pregunta: Cómo encontrar todos los elementos de un determinado tipo y agregarles una directiva. Pero cuando le decimos: No lo hagas, siempre se muestra muy sorprendido. La razón para no hacer esto es que se trata de un enfoque mitad jQuery y mitad AngularJS, lo cual no es bueno. El problema aquí es que los desarrolladores intentan "hacer jQuery" en el contexto de AngularJS. Siempre hay algunos problemas al hacer esto. Las opiniones son registros oficiales (Nota del traductor: es posible que el autor desee expresar que las opiniones son ciudadanos de primera clase). Nunca cambie el DOM fuera de una directiva. Todas las directivas se aplican a la vista y la intención es muy clara.
Recuerda: No diseñes, luego escribe etiquetas. Necesitas arquitectura y luego diseño.
Enlace de datos
Esta es, con diferencia, la característica más interesante de AngularJS. Esta característica hace que muchas de las operaciones DOM mencionadas anteriormente sean innecesarias.
AngularJS actualiza automáticamente la vista, ¡para que no tengas que hacerlo tú mismo! En jQuery, respondemos a eventos y actualizamos contenido, así:
$.ajax({
url: '/myEndpoint.json',
éxito : función (datos, estado) {
$('ul#log').append('
- ¡Datos recibidos!
'); p>});
Vista correspondiente:
En Además de tener múltiples aspectos a considerar, también nos encontramos con los problemas de la vista anterior. Pero lo más importante es que es necesario hacer referencia a un nodo DOM y actualizarlo manualmente. Si queremos eliminar una entrada de registro, también debemos codificarla para el DOM. Entonces, ¿cómo probar esta lógica sin DOM? ¿Qué pasa si quieres cambiar el formato de presentación?
Esto es un poco complicado y trivial. Pero en AngularJS, se puede implementar así:
$pile('Hello')($scope);
$ubicación.path('/not-matching');
expect(elm.hasClass('active')).toBeFalsey();
$ubicación.path ( '/hola');
expect(elm.hasClass('active')).toBeTruthy();
}));
Ejecuta esto prueba para confirmar que falló. Entonces podemos empezar a escribir esta directiva:
.directive('whenActive', function ($location) {
return {
alcance: verdadero,
p>
enlace: función (alcance, elemento, atributos) {
alcance.$on('$routeChangeSuccess', función () {
if ($ubicación. ruta () == element.attr('href')) {
element.addClass('active');
} else {
elemento removeClass. ('activo');
}
});
}
};
} ) ;
La prueba ahora pasa y nuestro menú se ejecuta según lo solicitado. El proceso de desarrollo es a la vez iterativo y basado en pruebas. Qué genial.
5. Conceptualmente, las directivas no están empaquetadas en jQuery.
A menudo se escucha "solo hacer operaciones DOM en directivas". Esto es necesario.
¡Por favor dale el respeto que se merece!
Pero profundicemos un poco más...
Algunas directivas simplemente decoran cosas que ya están en la vista (piense en ngClass) y, por lo tanto, a veces simplemente hacen la manipulación DOM directamente y luego es hecho. Pero si una directiva es como un "widget" y tiene un modelo, entonces también necesita lograr la separación de preocupaciones. Dicho esto, la plantilla en sí también debería permanecer en gran medida independiente de sus implementaciones de enlace y controlador.
AngularJS tiene un conjunto de herramientas para hacer este proceso muy simple; con ngClass podemos actualizar clases dinámicamente; ngBind nos permite realizar enlace de datos bidireccional. ngShow y ngHide muestran y ocultan mediante programación un elemento y más, incluidos los que escribimos nosotros mismos. En otras palabras, podemos lograr cualquier característica que puedan lograr las operaciones DOM. Cuantas menos manipulaciones DOM, más fácil será probar directivas, más fácil será diseñarlas, más fácil será aceptar cambios en el futuro y más reutilizables y liberables serán.
He visto a muchos principiantes en AngularJS incluir un montón de jQuery en la directiva. En otras palabras, piensan "porque no se pueden realizar operaciones DOM en el controlador, simplemente coloque esos códigos en la directiva". Aunque esto es realmente mejor, sigue siendo incorrecto.
Recuerde el registrador que escribimos en la Sección 3. Aunque tengamos que incluirlo en una directiva, queremos hacerlo "al estilo angular". ¡Todavía no tiene ninguna manipulación DOM! Hay muchas ocasiones en las que la manipulación DOM es necesaria, ¡pero en realidad es mucho menos común de lo que piensas! Antes de realizar manipulación DOM en cualquier parte de su aplicación, pregúntese si realmente necesita hacerlo. Probablemente haya una mejor manera.
Aquí hay un ejemplo de un patrón que veo con más frecuencia. Queremos hacer un botón de alternancia. (Nota: este ejemplo es un poco inverosímil y detallado. Esto es para expresar situaciones más complejas donde el problema se resuelve de la misma manera).
.directive('myDirective', function () {
return {
plantilla: '¡Alternarme!',
enlace: función (alcance, elemento , atributos) {
var on = false;
$(elemento).click(función () {
if (on) {
$ (element).removeClass('active');
} else {
$(element).addClass('active');
}
on = !on;
});
}
};
}) ;
Algo anda mal aquí. En primer lugar, no es necesario que jQeury exista en absoluto. ¡Nada de lo que hacemos aquí requiere jQuery en absoluto! En segundo lugar, incluso si jQuery ya se usa en la página, no hay razón para usarlo aquí.
En tercer lugar, incluso suponiendo que esta directiva dependa de jQuery para funcionar, jqLite (angular.element) siempre usará jQuery después de cargarlo. Por lo tanto, no necesitamos usar $, solo use angular.element. Cuarto, y estrechamente relacionado con el tercer punto, los elementos jqLite no necesitan estar $encapsulados: ¡el elemento pasado al enlace ya será un elemento jQuery! Quinto, como dijimos en el párrafo anterior, ¿por qué deberíamos mezclar plantillas con lógica?
Esta directiva se puede (¡incluso en el caso más complejo!) escribirse de manera más simple:
.directive('myDirective', function () {
return {
alcance: verdadero,
plantilla: 'Alternar yo!',
enlace: función (alcance, elemento, atributos) {
alcance.on = false;
alcance =. función () {
alcance.on = !$scope.on;
};
}
};
});
Una vez más, la plantilla está dentro de la plantilla y, cuando se necesita estilo, usted (o sus usuarios) pueden intercambiarla fácilmente sin tener que alterar la lógica. Reutilizabilidad: ¡boom!
Por supuesto, hay otros beneficios, como realizar pruebas: ¡es fácil! No importa lo que haya en la plantilla, la API interna de la directiva nunca se modifica, por lo que la refactorización es sencilla. Puede cambiar la plantilla arbitrariamente sin tocar la directiva. No importa cómo lo cambies, la prueba siempre pasa.
Entonces, si las directivas son más que un simple conjunto de funciones tipo jQuery, ¿qué son? La directiva es en realidad una extensión de HTML. Si HTML no hace lo que usted necesita, escribe una directiva para hacerlo y luego lo usa como HTML.
En otras palabras, si hay algo que la biblioteca AngularJS no hace, piensa en cómo lo lograría el equipo de desarrollo para trabajar con ngClick, ngClass, etc.
Resumen
No utilices jQuery. Ni siquiera incluyas incluir. Te detendrá en seco. Si encuentra un problema que cree que ya sabe cómo resolver usando jQuery, antes de usar $, intente pensar en cómo resolverlo dentro de las limitaciones de AngularJS. Si no lo sabes, ¡pregunta! 19 de cada 20 veces, la mejor manera no requiere jQuery. Intentar utilizar jQuery aumentará su carga de trabajo.
Esta es mi respuesta más larga hasta el momento. De hecho, esta respuesta es tan larga que tengo que completar un Captcha. Pero como suelo decir: poder hablar mucho y decir poco es realmente una pereza.