javascript - librerias - "Thinking in AngularJS" si tengo un fondo de jQuery?

librerias angularjs

Question

Supongamos que estoy familiarizado con el desarrollo de aplicaciones del lado del cliente en jQuery , pero ahora me gustaría comenzar a usar AngularJS . ¿Puedes describir el cambio de paradigma que es necesario? Aquí hay algunas preguntas que pueden ayudarlo a formular una respuesta:

• ¿Cómo puedo diseñar y diseñar aplicaciones web del lado del cliente de manera diferente? ¿Cuál es la mayor diferencia?
• ¿Qué debo dejar de hacer? ¿Qué debo empezar a hacer / usar en su lugar?
• ¿Hay consideraciones / restricciones del lado del servidor?

No estoy buscando una comparación detallada entre jQuery y AngularJS .

Answer 1

¿Puedes describir el cambio de paradigma que es necesario?

Imperativo vs declarativo

Con jQuery le dices al DOM lo que debe pasar, paso a paso. Con AngularJS , describe los resultados que desea pero no cómo hacerlo. Más sobre esto here . También, revisa la respuesta de Mark Rajcok.

¿Cómo puedo diseñar y diseñar aplicaciones web del lado del cliente de manera diferente?

AngularJS es un marco completo del lado del cliente que utiliza el patrón MVC (verifique su representación gráfica ). Se enfoca grandemente en la separación de preocupaciones.

¿Cuál es la mayor diferencia? ¿Qué debo dejar de hacer? ¿Qué debo empezar a hacer / usar en su lugar?

jQuery es una biblioteca

AngularJS es un hermoso marco del lado del cliente, altamente comprobable, que combina toneladas de cosas interesantes como MVC, inyección de dependencia , enlace de datos y mucho más.

Se enfoca en la separación de inquietudes y pruebas (pruebas unitarias y pruebas de extremo a extremo), lo que facilita el desarrollo basado en pruebas.

La mejor manera de comenzar es a través de su impresionante tutorial . Puedes seguir los pasos en un par de horas; sin embargo, en caso de que quiera dominar los conceptos detrás de escena, estos incluyen una gran cantidad de referencias para lecturas adicionales.

¿Hay consideraciones / restricciones del lado del servidor?

Puede usarlo en aplicaciones existentes en las que ya está utilizando jQuery puro. Sin embargo, si desea aprovechar al máximo las características de AngularJS, puede considerar codificar el lado del servidor utilizando un enfoque RESTful .

Hacerlo le permitirá aprovechar su fábrica de recursos , lo que crea una abstracción de la API RESTful del lado del servidor y hace que las llamadas del lado del servidor (obtener, guardar, eliminar, etc.) sean increíblemente fáciles.

Answer 2

1. No diseñe su página, y luego cámbiela con manipulaciones DOM

En jQuery, diseñas una página y luego la haces dinámica. Esto se debe a que jQuery fue diseñado para el aumento y ha crecido increíblemente desde esa simple premisa.

Pero en AngularJS, debe comenzar desde cero con su arquitectura en mente. En lugar de comenzar pensando "Tengo esta parte del DOM y quiero que haga X", debe comenzar con lo que quiere lograr, luego diseñar su aplicación y finalmente diseñar su vista.

2. No aumentes jQuery con AngularJS

Del mismo modo, no empiece con la idea de que jQuery hace X, Y y Z, así que solo agregaré AngularJS para modelos y controladores. Esto es realmente tentador cuando recién comienza, por lo que siempre recomiendo que los nuevos desarrolladores de AngularJS no utilicen jQuery, al menos hasta que se acostumbren a hacer las cosas de la "manera angular".

He visto a muchos desarrolladores aquí y en la lista de correo crear estas soluciones elaboradas con jQuery complementos de 150 o 200 líneas de código que luego pegan en AngularJS con una colección de devoluciones de llamada y $apply s que son confusos y complicados; ¡Pero eventualmente lo hacen funcionar! El problema es que, en la mayoría de los casos, el complemento jQuery se puede reescribir en AngularJS en una fracción del código, donde de repente todo se vuelve comprensible y sencillo.

La conclusión es esta: cuando se soluciona, primero "piense en AngularJS"; Si no puede pensar en una solución, pregunte a la comunidad; Si después de todo eso no hay una solución fácil, siéntase libre de buscar la jQuery. Pero no dejes que jQuery se convierta en una muleta o nunca dominarás AngularJS.

3. Piensa siempre en términos de arquitectura.

Primero se sabe que las aplicaciones de una sola página son aplicaciones . No son páginas web. Así que debemos pensar como un desarrollador del lado del servidor, además de pensar como un desarrollador del lado del servidor. Tenemos que pensar en cómo dividir nuestra aplicación en componentes individuales, extensibles y comprobables.

Entonces, ¿cómo haces eso? ¿Cómo "piensas en AngularJS"? Aquí hay algunos principios generales, contrastados con jQuery.

La vista es el "registro oficial".

En jQuery, cambiamos programáticamente la vista. Podríamos tener un menú desplegable definido como una ul así:

<ul class="main-menu">
<li class="active">
<a href="#/home">Home</a>
</li>
<li>
<a href="#/menu1">Menu 1</a>
<ul>
<li><a href="#/sm1">Submenu 1</a></li>
<li><a href="#/sm2">Submenu 2</a></li>
<li><a href="#/sm3">Submenu 3</a></li>
</ul>
</li>
<li>
<a href="#/home">Menu 2</a>
</li>
</ul>

En jQuery, en nuestra lógica de aplicación, lo activaríamos con algo como:

$(''.main-menu'').dropdownMenu();

Cuando solo miramos la vista, no es inmediatamente obvio que haya alguna funcionalidad aquí. Para aplicaciones pequeñas, eso está bien. Pero para aplicaciones no triviales, las cosas se vuelven confusas y difíciles de mantener.

Sin embargo, en AngularJS, la vista es el registro oficial de la funcionalidad basada en la vista. Nuestra declaración ul se vería así en su lugar:

<ul class="main-menu" dropdown-menu>
...
</ul>

Estos dos hacen lo mismo, pero en la versión de AngularJS, cualquiera que mire la plantilla sabe lo que se supone que sucede. Cada vez que un nuevo miembro del equipo de desarrollo se incorpora, ella puede ver esto y luego saber que existe una directiva llamada dropdownMenu ; ella no necesita intuir la respuesta correcta ni tamizar ningún código. La vista nos dijo que se suponía que iba a pasar. Mucho más limpio.

Los desarrolladores nuevos en AngularJS a menudo hacen una pregunta como: ¿cómo encuentro todos los enlaces de un tipo específico y les agrego una directiva? El desarrollador siempre está asombrado cuando respondemos: usted no. Pero la razón por la que no haces eso es que es como half-jQuery, half-AngularJS, y nada bueno. El problema aquí es que el desarrollador está tratando de "hacer jQuery" en el contexto de AngularJS. Eso nunca va a funcionar bien. La vista es el registro oficial. Fuera de una directiva (más sobre esto más adelante), nunca, nunca, nunca cambia el DOM. Y las directivas se aplican en la vista , por lo que la intención es clara.

Recuerde: no diseñe, y luego marque. Debes de arquitecto, y luego diseñar.

El enlace de datos

Esta es, con mucho, una de las características más impresionantes de AngularJS y elimina la necesidad de realizar las manipulaciones de DOM que mencioné en la sección anterior. ¡AngularJS actualizará automáticamente su vista para que no tenga que hacerlo! En jQuery, respondemos a los eventos y luego actualizamos el contenido. Algo como:

$.ajax({
url: ''/myEndpoint.json'',
success: function ( data, status ) {
$(''ul#log'').append(''<li>Data Received!</li>'');
}
});

Para una vista que se ve así:

<ul class="messages" id="log">
</ul>

Además de mezclar preocupaciones, también tenemos los mismos problemas de significar intención que mencioné antes. Pero lo que es más importante, tuvimos que hacer referencia manualmente y actualizar un nodo DOM. Y si queremos eliminar una entrada de registro, también tenemos que codificar contra el DOM para eso. ¿Cómo probamos la lógica aparte del DOM? ¿Y si queremos cambiar la presentación?

Esto un poco desordenado y un poco frágil. Pero en AngularJS, podemos hacer esto:

$http( ''/myEndpoint.json'' ).then( function ( response ) {
$scope.log.push( { msg: ''Data Received!'' } );
});

Y nuestra vista puede verse así:

<ul class="messages">
<li ng-repeat="entry in log">{{ entry.msg }}</li>
</ul>

Pero para el caso, nuestra visión podría verse así:

<div class="messages">
<div class="alert" ng-repeat="entry in log">
{{ entry.msg }}
</div>
</div>

Y ahora, en lugar de usar una lista desordenada, estamos usando los cuadros de alerta Bootstrap. ¡Y nunca tuvimos que cambiar el código del controlador! Pero lo que es más importante, no importa dónde o cómo se actualice el registro, la vista también cambiará. Automáticamente. ¡Ordenado!

Aunque no lo mostré aquí, el enlace de datos es bidireccional. Por lo tanto, esos mensajes de registro también se pueden editar en la vista con solo hacer esto: <input ng-model="entry.msg" /> . Y hubo mucho regocijo.

Capa de modelo distinta

En jQuery, el DOM es algo así como el modelo. Pero en AngularJS, tenemos una capa de modelo separada que podemos administrar de la manera que queramos, completamente independiente de la vista. Esto ayuda para el enlace de datos anterior, mantiene la separación de preocupaciones e introduce una comprobabilidad mucho mayor. Otras respuestas mencionaron este punto, así que lo dejaré así.

Separación de intereses

Y todo lo anterior se relaciona con este tema general: mantenga sus preocupaciones separadas. Su opinión actúa como el registro oficial de lo que se supone que sucede (en su mayor parte); su modelo representa sus datos; tiene una capa de servicio para realizar tareas reutilizables; usted hace la manipulación de DOM y aumenta su vista con directivas; Y lo pegas todo junto con los controladores. Esto también se mencionó en otras respuestas, y lo único que agregaría se refiere a la capacidad de prueba, que comento en otra sección a continuación.

Inyección de dependencia

Para ayudarnos con la separación de las preocupaciones es la inyección de dependencia (DI). Si viene de un lenguaje del lado del servidor (de Java a PHP ) probablemente ya esté familiarizado con este concepto, pero si es un tipo del lado del cliente que viene de jQuery, este concepto puede parecer desde tonto hasta superfluo a inconformista. . Pero no lo es. :-)

Desde una perspectiva amplia, DI significa que puede declarar los componentes con mucha libertad y luego desde cualquier otro componente, solo solicite una instancia y se otorgará. No tienes que saber sobre el orden de carga, las ubicaciones de los archivos, ni nada de eso. Es posible que el poder no sea visible de inmediato, pero proporcionaré solo un ejemplo (común): la prueba.

Digamos que en nuestra aplicación, requerimos un servicio que implemente almacenamiento del lado del servidor a través de una API REST y, dependiendo del estado de la aplicación, también del almacenamiento local. Al ejecutar pruebas en nuestros controladores, no queremos tener que comunicarnos con el servidor; después de todo, estamos probando el controlador . Simplemente podemos agregar un servicio simulado del mismo nombre que nuestro componente original, y el inyector se asegurará de que nuestro controlador obtenga el falso automáticamente; nuestro controlador no lo hace y no necesita saber la diferencia.

Hablando de pruebas ...

4. Desarrollo guiado por pruebas - siempre

Esto es realmente parte de la sección 3 sobre arquitectura, pero es tan importante que lo pongo como su propia sección de nivel superior.

De todos los muchos complementos de jQuery que has visto, usado o escrito, ¿cuántos de ellos tenían un conjunto de pruebas de acompañamiento? No muchos porque jQuery no es muy susceptible a eso. Pero AngularJS es.

En jQuery, la única forma de probar a menudo es crear el componente de forma independiente con una página de muestra / demostración en la que nuestras pruebas puedan realizar la manipulación de DOM. Entonces, tenemos que desarrollar un componente por separado y luego integrarlo en nuestra aplicación. ¡Qué inconveniente! Gran parte del tiempo, al desarrollar con jQuery, optamos por el desarrollo iterativo en lugar del basado en pruebas. ¿Y quién nos puede culpar?

Pero como tenemos una separación de inquietudes, ¡podemos hacer el desarrollo guiado por pruebas de forma iterativa en AngularJS! Por ejemplo, digamos que queremos una directiva súper simple para indicar en nuestro menú cuál es nuestra ruta actual. Podemos declarar lo que queremos en la vista de nuestra aplicación:

<a href="/hello" when-active>Hello</a>

Bien, ahora podemos escribir una prueba para la directiva inexistente when-active :

it( ''should add "active" when the route changes'', inject(function() {
var elm = $compile( ''<a href="/hello" when-active>Hello</a>'' )( $scope );
$location.path(''/not-matching'');
expect( elm.hasClass(''active'') ).toBeFalsey();
$location.path( ''/hello'' );
expect( elm.hasClass(''active'') ).toBeTruthy();
}));

Y cuando ejecutamos nuestra prueba, podemos confirmar que falla. Solo ahora deberíamos crear nuestra directiva:

.directive( ''whenActive'', function ( $location ) {
return {
scope: true,
link: function ( scope, element, attrs ) {
scope.$on( ''$routeChangeSuccess'', function () {
if ( $location.path() == element.attr( ''href'' ) ) {
element.addClass( ''active'' );
}
else {
element.removeClass( ''active'' );
}
});
}
};
});

Nuestra prueba ahora pasa y nuestro menú se realiza según lo solicitado. Nuestro desarrollo es iterativo y está basado en pruebas. Malvado-cool

5. Conceptualmente, las directivas no están empaquetadas jQuery.

A menudo escuchará "solo hacer manipulación de DOM en una directiva". Esto es una necesidad. ¡Trátenlo con la debida deferencia!

Pero vamos a bucear un poco más profundo ...

Algunas directivas simplemente decoran lo que ya está en la vista (piense en ngClass ) y, por lo tanto, a veces hacen la manipulación de DOM de inmediato y luego se hacen básicamente. Pero si una directiva es como un "widget" y tiene una plantilla, también debe respetar la separación de preocupaciones. Es decir, la plantilla también debe permanecer en gran medida independiente de su implementación en las funciones de enlace y controlador.

AngularJS viene con un conjunto completo de herramientas para hacer esto muy fácil; con ngClass podemos actualizar dinámicamente la clase; ngModel permite el enlace de datos de dos vías; ngShow y ngHide muestran u ocultan ngHide programación un elemento; y muchas más, incluso las que nosotros mismos escribimos. En otras palabras, podemos hacer todo tipo de maravillas sin la manipulación de DOM. Cuanto menor es la manipulación de DOM, más fáciles son las directivas de prueba, más fácil de diseñar, más fácil de cambiar en el futuro, y más reutilizables y distribuibles son.

Veo muchos desarrolladores nuevos en AngularJS que usan directivas como el lugar para lanzar un montón de jQuery. En otras palabras, piensan que "ya que no puedo realizar la manipulación de DOM en el controlador, tomaré ese código y lo pondré en una directiva". Si bien eso es mucho mejor, a menudo sigue siendo incorrecto .

Piense en el registrador que programamos en la sección 3. Incluso si lo incluimos en una directiva, todavía queremos hacerlo de la "forma angular". ¡ Todavía no lleva ninguna manipulación DOM! Hay muchas veces en que la manipulación de DOM es necesaria, ¡pero es mucho más rara de lo que piensas! Antes de realizar la manipulación de DOM en cualquier lugar de su aplicación, pregúntese si realmente necesita hacerlo. Puede haber una mejor manera

Aquí hay un ejemplo rápido que muestra el patrón que veo con más frecuencia. Queremos un botón conmutable. (Nota: este ejemplo es un poco artificial y un resumen detallado para representar casos más complicados que se resuelven exactamente de la misma manera.)

.directive( ''myDirective'', function () {
return {
template: ''<a class="btn">Toggle me!</a>'',
link: function ( scope, element, attrs ) {
var on = false;
$(element).click( function () {
on = !on;
$(element).toggleClass(''active'', on);
});
}
};
});

Hay algunas cosas mal con esto:

1. Primero, jQuery nunca fue necesario. ¡No hay nada que hiciéramos aquí que necesitara jQuery en absoluto!
2. Segundo, incluso si ya tenemos jQuery en nuestra página, no hay razón para usarlo aquí; simplemente podemos usar angular.element y nuestro componente aún funcionará cuando se angular.element en un proyecto que no tenga jQuery.
3. Tercero, incluso suponiendo que jQuery fuera necesario para que esta directiva funcionara, jqLite (elemento angular.element ) siempre usará jQuery si estaba cargado. Así que no necesitamos usar el $ - solo podemos usar el elemento angular.element .
4. Cuarto, estrechamente relacionado con el tercero, es que los elementos jqLite no tienen que estar envueltos en $ , ¡el element que se pasa a la función de link ya sería un elemento jQuery!
5. Y quinto, que hemos mencionado en secciones anteriores, ¿por qué estamos mezclando elementos de plantillas en nuestra lógica?

Esta directiva puede ser reescrita (incluso para casos muy complicados) mucho más simplemente así:

.directive( ''myDirective'', function () {
return {
scope: true,
template: ''<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>'',
link: function ( scope, element, attrs ) {
scope.on = false;
scope.toggle = function () {
scope.on = !scope.on;
};
}
};
});

Nuevamente, la plantilla está en la plantilla, por lo que usted (o sus usuarios) pueden intercambiarla fácilmente por uno que cumpla con el estilo necesario, y la lógica nunca tuvo que ser tocada. Reutilización - boom!

Y todavía hay todos esos otros beneficios, como las pruebas, ¡es fácil! No importa lo que haya en la plantilla, la API interna de la directiva nunca se toca, por lo que la refactorización es fácil. Puede cambiar la plantilla tanto como desee sin tocar la directiva. Y no importa lo que cambies, tus pruebas aún pasan.

w00t!

Entonces, si las directivas no son solo colecciones de funciones similares a jQuery, ¿qué son? Las directivas son en realidad extensiones de HTML . Si HTML no hace lo que necesita, escriba una directiva para que lo haga por usted y luego lo use como si fuera parte de HTML.

Dicho de otra manera, si AngularJS no hace algo fuera de la caja, piense cómo lo lograría el equipo para encajar perfectamente con ngClick , ngClass , et al.

Resumen

Ni siquiera uses jQuery. Ni siquiera lo incluyas. Te detendrá. Y cuando llegue a un problema que cree que ya sabe cómo resolver en jQuery, antes de buscar el $ , intente pensar cómo hacerlo dentro de los límites del AngularJS. Si no lo sabes, pregunta! 19 de cada 20 veces, la mejor manera de hacerlo no necesita jQuery y tratar de resolverlo con jQuery da como resultado más trabajo para usted.

Answer 3

AngularJS vs. jQuery

AngularJS y jQuery adoptan ideologías muy diferentes. Si vienes de jQuery es posible que algunas de las diferencias sean sorprendentes. Angular puede hacerte enojar.

Esto es normal, debe empujar a través. Angular vale la pena.

La gran diferencia (TLDR)

jQuery le proporciona un kit de herramientas para seleccionar bits arbitrarios del DOM y hacer cambios ad-hoc para ellos. Puedes hacer prácticamente todo lo que quieras pieza por pieza.

AngularJS en cambio te da un compilador .

Lo que esto significa es que AngularJS lee todo tu DOM de arriba a abajo y lo trata como un código, literalmente como instrucciones para el compilador. A medida que atraviesa el DOM, busca directivas específicas ( directivas de compilación) que le dicen al compilador de AngularJS cómo comportarse y qué hacer. Las directivas son pequeños objetos llenos de JavaScript que pueden coincidir con atributos, etiquetas, clases o incluso comentarios.

Cuando el compilador Angular determina que una parte del DOM coincide con una directiva particular, llama a la función directiva, pasándole el elemento DOM, cualquier atributo, el alcance $ actual (que es un almacén de variables local) y algunos otros bits útiles. Estos atributos pueden contener expresiones que pueden ser interpretadas por la Directiva, y que le dicen cómo renderizar, y cuándo debe volver a dibujarse.

Luego, las directivas pueden, a su vez, incorporar componentes angulares adicionales, como controladores, servicios, etc. Lo que sale de la parte inferior del compilador es una aplicación web totalmente formada, conectada y lista para funcionar.

Esto significa que Angular es impulsado por plantillas . Su plantilla impulsa el JavaScript, no al revés. Esto es una inversión radical de roles, y todo lo contrario del discreto JavaScript que hemos estado escribiendo durante los últimos 10 años aproximadamente. Esto puede tomar algún tiempo para acostumbrarse.

Si esto suena como si pudiera ser demasiado prescriptivo y limitante, nada podría estar más lejos de la verdad. Debido a que AngularJS trata su código HTML como código, obtiene granularidad de nivel HTML en su aplicación web . Todo es posible, y la mayoría de las cosas son sorprendentemente fáciles una vez que haces algunos saltos conceptuales.

Vayamos al grano.

Primero, Angular no reemplaza a jQuery.

Angular y jQuery hacen cosas diferentes. AngularJS le ofrece un conjunto de herramientas para producir aplicaciones web. jQuery principalmente te da herramientas para modificar el DOM. Si jQuery está presente en su página, AngularJS lo usará automáticamente. Si no lo es, AngularJS se entrega con jQuery Lite, que es una versión recortada, pero aún así perfectamente utilizable de jQuery.

A Misko le gusta jQuery y no se opone a que lo uses. Sin embargo, a medida que avance, descubrirá que puede realizar prácticamente todo su trabajo utilizando una combinación de alcances, plantillas y directivas, y debería preferir este flujo de trabajo siempre que sea posible, ya que su código será más discreto, más configurable y más. Angular.

Si usas jQuery, no debes rociarlo por todos lados. El lugar correcto para la manipulación de DOM en AngularJS está en una directiva. Más sobre estos más tarde.

JavaScript discreto con selectores y plantillas declarativas

jQuery se aplica típicamente discretamente. Su código JavaScript está vinculado en el encabezado (o pie de página), y este es el único lugar donde se menciona. Usamos selectores para seleccionar partes de la página y escribir complementos para modificar esas partes.

El JavaScript está en control. El HTML tiene una existencia completamente independiente. Tu HTML permanece semántico incluso sin JavaScript. Los atributos onclick son muy malas prácticas.

Una de las primeras cosas que notará sobre AngularJS es que los atributos personalizados están en todas partes . Su HTML estará lleno de atributos ng, que son esencialmente atributos onClick en esteroides. Estas son directivas (directivas de compilación) y son una de las principales formas en que la plantilla se engancha al modelo.

Cuando veas esto por primera vez, podrías tener la tentación de descartar a AngularJS como JavaScript intrusivo de la vieja escuela (como lo hice al principio). De hecho, AngularJS no juega por esas reglas. En AngularJS, su HTML5 es una plantilla. Está compilado por AngularJS para producir su página web.

Esta es la primera gran diferencia. Para jQuery, su página web es un DOM a manipular. Para AngularJS, su código HTML es un código que debe compilarse. AngularJS lee en toda su página web y, literalmente, la compila en una nueva página web utilizando su compilador incorporado.

Su plantilla debe ser declarativa; su significado debe ser claro simplemente leyéndolo. Usamos atributos personalizados con nombres significativos. Creamos nuevos elementos HTML, de nuevo con nombres significativos. Un diseñador con conocimientos mínimos de HTML y sin capacidad de codificación puede leer su plantilla de AngularJS y entender lo que está haciendo. Él o ella puede hacer modificaciones. Esta es la forma angular.

La plantilla está en el asiento del conductor.

Una de las primeras preguntas que me hice al iniciar AngularJS y ejecutar los tutoriales es "¿Dónde está mi código?" . No he escrito JavaScript, y sin embargo tengo todo este comportamiento. La respuesta es obvia. Debido a que AngularJS compila el DOM, AngularJS trata su código HTML como código. Para muchos casos simples, a menudo es suficiente simplemente escribir una plantilla y dejar que AngularJS la compile en una aplicación para usted.

Su plantilla impulsa su aplicación. Se trata como un DSL . Usted escribe los componentes de AngularJS, y AngularJS se encargará de jalarlos y de ponerlos a su disposición en el momento adecuado según la estructura de su plantilla. Esto es muy diferente a un patrón MVC estándar, donde la plantilla es solo para salida.

Es más similar a XSLT que a Ruby on Rails, por ejemplo.

Esta es una inversión radical de control a la que lleva un tiempo acostumbrarse.

Deja de intentar manejar tu aplicación desde tu JavaScript. Deje que la plantilla conduzca la aplicación y deje que AngularJS se encargue de cablear los componentes juntos. Esta también es la vía angular.

HTML semántico vs. modelos semánticos

Con jQuery, su página HTML debe contener contenido semántico significativo. Si el JavaScript está desactivado (por un usuario o motor de búsqueda) su contenido permanece accesible.

Porque AngularJS trata su página HTML como una plantilla. No se supone que la plantilla sea semántica, ya que su contenido normalmente se almacena en su modelo, que en última instancia proviene de su API. AngularJS compila su DOM con el modelo para producir una página web semántica.

Su fuente HTML ya no es semántica, en cambio, su API y DOM compilados son semánticos.

En AngularJS, lo que significa que vive en el modelo, el HTML es solo una plantilla, solo para mostrar.

En este punto, es probable que tenga todo tipo de preguntas sobre SEO y accesibilidad, y con razón. Hay temas abiertos aquí. La mayoría de los lectores de pantalla ahora analizarán JavaScript. Los motores de búsqueda también pueden indexar el contenido de AJAXed . Sin embargo, querrá asegurarse de que está utilizando las URL de pushstate y que tiene un sitemap decente. Vea aquí para una discusión del problema: https://.com/a/23245379/687677

Separación de inquietudes (SOC) vs. MVC

La separación de inquietudes (SOC) es un patrón que creció durante muchos años de desarrollo web por una variedad de razones que incluyen SEO, accesibilidad y incompatibilidad de navegador. Se parece a esto:

1. HTML - Significado semántico. El HTML debe estar solo.
2. CSS - Estilo, sin el CSS la página todavía se puede leer.
3. JavaScript - Comportamiento, sin el script el contenido permanece.

Nuevamente, AngularJS no juega según sus reglas. En un golpe, AngularJS elimina una década de sabiduría recibida y en su lugar implementa un patrón MVC en el que la plantilla ya no es semántica, ni siquiera un poco.

Se parece a esto:

1. Modelo - sus modelos contienen sus datos semánticos. Los modelos suelen ser objetos JSON . Los modelos existen como atributos de un objeto llamado $ scope. También puede almacenar funciones útiles de utilidades en $ alcance a las que luego pueden acceder sus plantillas.
2. Vista - Sus vistas están escritas en HTML. La vista generalmente no es semántica porque sus datos viven en el modelo.
3. Controlador: su controlador es una función de JavaScript que enlaza la vista al modelo. Su función es inicializar $ alcance. Dependiendo de su aplicación, puede que necesite o no crear un controlador. Puedes tener muchos controladores en una página.

MVC y SOC no están en extremos opuestos de la misma escala, están en ejes completamente diferentes. SOC no tiene sentido en un contexto AngularJS. Tienes que olvidarlo y seguir adelante.

Si, como yo, viviste las guerras de los navegadores, podrías encontrar esta idea bastante ofensiva. Supéralo, valdrá la pena, lo prometo.

Complementos vs. Directivas

Los complementos extienden jQuery. Las directivas AngularJS amplían las capacidades de su navegador.

En jQuery definimos complementos agregando funciones al jQuery.prototype. Luego, enganchamos esto en el DOM seleccionando elementos y llamando al complemento sobre el resultado. La idea es ampliar las capacidades de jQuery.

Por ejemplo, si desea un carrusel en su página, puede definir una lista desordenada de figuras, tal vez envuelta en un elemento de navegación. Luego, puede escribir algunos jQuery para seleccionar la lista en la página y volver a dibujarla como una galería con tiempos de espera para hacer la animación deslizante.

En AngularJS, definimos directivas. Una directiva es una función que devuelve un objeto JSON. Este objeto le dice a AngularJS qué elementos DOM debe buscar y qué cambios debe hacerles. Las directivas están conectadas a la plantilla utilizando atributos o elementos, que usted inventa. La idea es ampliar las capacidades de HTML con nuevos atributos y elementos.

La forma de AngularJS es ampliar las capacidades de HTML de aspecto nativo. Debe escribir HTML que se vea como HTML, extendido con atributos y elementos personalizados.

Si desea un carrusel, solo use un <carousel />elemento, luego defina una directiva para introducir una plantilla y haga que esa ventosa funcione.

Un montón de pequeñas directivas frente a grandes complementos con interruptores de configuración

La tendencia con jQuery es escribir grandes complementos grandes como lightbox, que luego configuramos pasando numerosos valores y opciones.

Este es un error en AngularJS.

Tomemos el ejemplo de un menú desplegable. Al escribir un complemento desplegable, podría tener la tentación de codificar en los controladores de clics, tal vez una función para agregar un chevron que esté arriba o abajo, tal vez cambiar la clase del elemento desplegado, mostrar ocultar el menú, todo lo útil.

Hasta que quieras hacer un pequeño cambio.

Digamos que tienes un menú que deseas desplegar en el hover. Bueno, ahora tenemos un problema. Nuestro complemento está conectado a nuestro controlador de clics para nosotros, vamos a necesitar agregar una opción de configuración para que se comporte de manera diferente en este caso específico.

En AngularJS escribimos directivas más pequeñas. Nuestra directiva desplegable sería ridículamente pequeña. Puede mantener el estado plegado y proporcionar métodos para plegar (), desplegar () o alternar (). Estos métodos simplemente actualizarían $ scope.menu.visible, que es un booleano que mantiene el estado.

Ahora en nuestra plantilla podemos conectar esto:

<a ng-click="toggle()">Menu</a>
<ul ng-show="menu.visible">
...
</ul>

¿Necesitas actualizar en mouseover?

<a ng-mouseenter="unfold()" ng-mouseleave="fold()">Menu</a>
<ul ng-show="menu.visible">
...
</ul>

La plantilla impulsa la aplicación para que obtengamos granularidad de nivel HTML. Si queremos hacer excepciones caso por caso, la plantilla lo hace fácil.

Cierre vs. $ alcance

Los complementos de JQuery se crean en un cierre. La privacidad se mantiene dentro de ese cierre. Depende de usted mantener su cadena de alcance dentro de ese cierre. Solo tiene acceso al conjunto de nodos DOM que jQuery ha pasado al complemento, además de las variables locales definidas en el cierre y las variables globales que haya definido. Esto significa que los complementos son bastante autónomos. Esto es bueno, pero puede ser restrictivo al crear una aplicación completa. Tratar de pasar datos entre secciones de una página dinámica se convierte en una tarea.

AngularJS tiene $ objetos de alcance. Estos son objetos especiales creados y mantenidos por AngularJS en los que almacena su modelo. Ciertas directivas generarán un nuevo $ scope, que de forma predeterminada se hereda de su envoltorio $ scope utilizando la herencia prototípica de JavaScript. El objeto $ scope es accesible en el controlador y en la vista.

Esta es la parte inteligente. Debido a que la estructura de la herencia de $ scope sigue aproximadamente la estructura del DOM, los elementos tienen acceso a su propio alcance y a cualquier ámbito que lo contenga, hasta el alcance global de $ (que no es el mismo que el alcance global).

Esto hace que sea mucho más fácil pasar datos y almacenarlos a un nivel apropiado. Si se despliega un menú desplegable, solo el alcance de $ desplegable necesita saberlo. Si el usuario actualiza sus preferencias, es posible que desee actualizar el alcance global de $, y se alertará automáticamente a cualquier ámbito anidado que escuche las preferencias del usuario.

Esto puede parecer complicado, de hecho, una vez que te relajas, es como volar. No es necesario crear el objeto $ scope, AngularJS crea una instancia y lo configura para usted, de manera correcta y adecuada según la jerarquía de su plantilla. AngularJS luego lo pone a disposición de su componente utilizando la magia de la inyección de dependencia (más sobre esto más adelante).

Cambios manuales de DOM vs. enlace de datos

En jQuery haces todos tus cambios de DOM a mano. Construyes nuevos elementos DOM programáticamente. Si tiene una matriz JSON y desea asignarla al DOM, debe escribir una función para generar el HTML e insertarlo.

En AngularJS también puede hacer esto, pero se recomienda utilizar el enlace de datos. Cambie su modelo y, dado que el DOM está vinculado a él a través de una plantilla, su DOM se actualizará automáticamente, no se requiere intervención.

Debido a que el enlace de datos se realiza desde la plantilla, utilizando un atributo o la sintaxis de llaves, es muy fácil de hacer. Hay poca sobrecarga cognitiva asociada con él, por lo que te encontrarás haciendo todo el tiempo.

<input ng-model="user.name" />

Enlaza el elemento de entrada a $scope.user.name. Actualizar la entrada actualizará el valor en su alcance actual, y viceversa.

Igualmente:

<p>
{{user.name}}
</p>

dará salida al nombre de usuario en un párrafo. Es un enlace en vivo, por lo que si el $scope.user.namevalor se actualiza, la plantilla también se actualizará.

Ajax todo el tiempo

En jQuery, hacer una llamada Ajax es bastante simple, pero aún así es algo en lo que podría pensar dos veces. Hay que agregar la complejidad adicional y mantener una buena parte del script.

En AngularJS, Ajax es tu solución de acceso predeterminada y sucede todo el tiempo, casi sin que te des cuenta. Puede incluir plantillas con ng-include. Puede aplicar una plantilla con la directiva personalizada más simple. Puedes envolver una llamada Ajax en un servicio y crearte un servicio GitHub , o un servicio Flickr , al que puedes acceder con asombrosa facilidad.

Objetos de servicio vs funciones de ayuda

En jQuery, si queremos realizar una pequeña tarea no relacionada con dom como extraer una fuente de una API, podríamos escribir una pequeña función para hacer eso en nuestro cierre. Esa es una solución válida, pero ¿y si queremos acceder a ese feed a menudo? ¿Qué pasa si queremos reutilizar ese código en otra aplicación?

AngularJS nos da objetos de servicio.

Los servicios son objetos simples que contienen funciones y datos. Siempre son singletes, lo que significa que nunca puede haber más de uno. Supongamos que queremos acceder a la API de desbordamiento de pila, podríamos escribir una Serviceque defina métodos para hacerlo.

Digamos que tenemos un carrito de compras. Podríamos definir un ShoppingCartService que mantenga nuestro carrito y contenga métodos para agregar y eliminar artículos. Debido a que el servicio es un singleton y es compartido por todos los otros componentes, cualquier objeto que necesite puede escribir en el carrito de la compra y extraer datos de él. Siempre es el mismo carro.

Los objetos de servicio son componentes autónomos de AngularJS que podemos usar y reutilizar según lo creamos. Son simples objetos JSON que contienen funciones y datos. Siempre son individuales, por lo tanto, si almacena datos en un servicio en un lugar, puede obtenerlos en otro lugar simplemente solicitando el mismo servicio.

Inyección de dependencia (DI) frente a la administración - también conocida como desespetización

AngularJS gestiona sus dependencias por usted. Si desea un objeto, simplemente consúltelo y AngularJS lo obtendrá por usted.

Hasta que no empieces a usar esto, es difícil explicar qué tan masivo es este tiempo. Nada como AngularJS DI existe dentro de jQuery.

DI significa que, en lugar de escribir su aplicación y conectarla, debe definir una biblioteca de componentes, cada uno identificado por una cadena.

Digamos que tengo un componente llamado ''FlickrService'' que define métodos para extraer fuentes JSON de Flickr. Ahora, si quiero escribir un controlador que pueda acceder a Flickr, solo necesito referirme al ''Servicio de Flickr'' por nombre cuando declare el controlador. AngularJS se encargará de crear una instancia del componente y ponerlo a disposición de mi controlador.

Por ejemplo, aquí defino un servicio:

myApp.service(''FlickrService'', function() {
return {
getFeed: function() { // do something here }
}
});

Ahora, cuando quiero usar ese servicio, me refiero a él con un nombre como este:

myApp.controller(''myController'', [''FlickrService'', function(FlickrService) {
FlickrService.getFeed()
}]);

AngularJS reconocerá que se necesita un objeto FlickrService para crear una instancia del controlador, y nos proporcionará uno.

Esto hace que el cableado sea muy fácil y elimina prácticamente cualquier tendencia a la espagificación. Tenemos una lista plana de componentes, y AngularJS nos los entrega uno por uno a medida que los necesitamos.

Arquitectura modular de servicios.

jQuery dice muy poco sobre cómo debes organizar tu código. AngularJS tiene opiniones.

AngularJS te da módulos en los que puedes colocar tu código. Si está escribiendo un script que habla con Flickr, por ejemplo, es posible que desee crear un módulo de Flickr para incluir todas sus funciones relacionadas con Flickr. Los módulos pueden incluir otros módulos (DI). Su aplicación principal suele ser un módulo, y esto debería incluir todos los demás módulos de los que dependerá su aplicación.

Obtiene una reutilización simple del código; si desea escribir otra aplicación basada en Flickr, puede incluir el módulo de Flickr y, de esta forma, tendrá acceso a todas las funciones relacionadas con Flickr en su nueva aplicación.

Los módulos contienen componentes AngularJS. Cuando incluimos un módulo, todos los componentes de ese módulo están disponibles para nosotros como una lista simple identificada por sus cadenas únicas . Luego podemos inyectar esos componentes entre sí utilizando el mecanismo de inyección de dependencia de AngularJS.

Para resumir

AngularJS y jQuery no son enemigos. Es posible usar jQuery dentro de AngularJS muy bien. Si está utilizando bien AngularJS (plantillas, enlace de datos, $ scope, directivas, etc.) encontrará que necesita mucho menos jQuery de lo que podría necesitar.

Lo principal a tener en cuenta es que su plantilla impulsa su aplicación. Deja de intentar escribir grandes plugins que lo hagan todo. En su lugar, escriba pequeñas directivas que hagan una cosa, luego escriba una plantilla simple para conectarlas.

Piense menos acerca de JavaScript discreto, y en lugar de eso piense en términos de extensiones HTML.

Mi librito

Estaba tan entusiasmado con AngularJS, escribí un libro corto en el mismo que eres muy bienvenido a leer en línea http://nicholasjohnson.com/angular-book/ . Espero que sea de ayuda.

Answer 4

jQuery

jQuery hace comandos de JavaScript ridículamente largos, como los getElementByHerpDerpmás cortos y los navegadores cruzados.

AngularJS

AngularJS le permite crear sus propias etiquetas / atributos HTML que hacen cosas que funcionan bien con aplicaciones web dinámicas (ya que HTML fue diseñado para páginas estáticas).

Editar:

Diciendo "Tengo un fondo de jQuery, ¿cómo pienso en AngularJS?" es como decir "Tengo un fondo HTML, ¿cómo pienso en JavaScript?" El hecho de que esté haciendo la pregunta demuestra que lo más probable es que no entienda los propósitos fundamentales de estos dos recursos. Esta es la razón por la que elegí responder a la pregunta simplemente señalando la diferencia fundamental en lugar de ir a través de la lista que dice "AngularJS utiliza directivas, mientras que jQuery utiliza los selectores de CSS para crear un objeto jQuery que hace esto y aquello, etc." . Esta pregunta no requiere una respuesta larga.

jQuery es una forma de facilitar la programación de JavaScript en el navegador. Comandos más cortos, cross-browser, etc.

AngularJS amplía HTML, por lo que no tiene que poner <div>todo el lugar solo para hacer una aplicación. Hace que HTML realmente funcione para aplicaciones en lugar de para lo que fue diseñado, que es páginas web estáticas y educativas. Lo logra de forma indirecta utilizando JavaScript, pero fundamentalmente es una extensión de HTML, no de JavaScript.

Answer 5

Imperativo → declarativo

En jQuery, los selectores se usan para encontrar elementos DOM y luego vincular / registrar los controladores de eventos en ellos. Cuando se activa un evento, ese código (imperativo) se ejecuta para actualizar / cambiar el DOM.

En AngularJS, desea pensar en vistas en lugar de elementos DOM. Las vistas son (declarativas) HTML que contienen directivas AngularJS. Las directivas configuran los controladores de eventos entre bambalinas para nosotros y nos ofrecen un enlace de datos dinámico. Los selectores rara vez se utilizan, por lo que la necesidad de ID (y algunos tipos de clases) disminuye considerablemente. Las vistas están vinculadas a los modelos (a través de ámbitos). Las vistas son una proyección del modelo. Los eventos cambian los modelos (es decir, los datos, las propiedades del ámbito) y las vistas que proyectan esos modelos se actualizan "automáticamente".

En AngularJS, piense en modelos, en lugar de elementos DOM seleccionados por jQuery que contienen sus datos. Piense en las vistas como proyecciones de esos modelos, en lugar de registrar devoluciones de llamada para manipular lo que el usuario ve.

Separación de intereses

jQuery emplea JavaScript discreto : el comportamiento (JavaScript) está separado de la estructura (HTML).

AngularJS usa controladores y directivas (cada uno de los cuales puede tener su propio controlador y / o funciones de compilación y enlace) para eliminar el comportamiento de la vista / estructura (HTML). Angular también tiene servicios y filtros para ayudar a separar / organizar su aplicación.

Consulte también https://.com/a/14346528/215945

Diseño de la aplicación

Un enfoque para diseñar una aplicación AngularJS:

1. Piensa en tus modelos. Crea servicios o tus propios objetos de JavaScript para esos modelos.
2. Piensa en cómo quieres presentar tus modelos: tus vistas. Cree plantillas HTML para cada vista, utilizando las directivas necesarias para obtener el enlace de datos dinámico.
3. Adjunte un controlador a cada vista (usando ng-view y routing, o ng-controller). Haga que el controlador encuentre / obtenga solo los datos del modelo que la vista necesita para hacer su trabajo. Haga los controladores lo más finos posible.

Herencia prototípica

Puede hacer mucho con jQuery sin saber cómo funciona la herencia prototípica de JavaScript. Al desarrollar aplicaciones de AngularJS, evitará algunos escollos comunes si tiene un buen conocimiento de la herencia de JavaScript. Lectura recomendada: ¿Cuáles son los matices del alcance prototípico / herencia prototípica en AngularJS?

Answer 6

AngularJS y jQuery:

AngularJs y JQuery son completamente diferentes en todos los niveles, excepto la funcionalidad JQLite, y lo verás una vez que comiences a aprender las características principales de AngularJs (lo explico a continuación).

AngularJs es un marco del lado del cliente que ofrece construir la aplicación del lado del cliente independiente. JQuery es una biblioteca del lado del cliente que juega alrededor del DOM.

Principio fresco de AngularJs: si desea algunos cambios en su interfaz de usuario, piense desde la perspectiva del cambio de datos del modelo. Cambia tus datos y la interfaz de usuario se volverá a representar. No es necesario jugar con DOM cada vez, a menos que sea necesario, y eso también debe manejarse a través de directivas angulares.

Para responder a esta pregunta, quiero compartir mi experiencia en la primera aplicación empresarial con AngularJS. Estas son las características más asombrosas que proporciona Angular donde comenzamos a cambiar nuestra mentalidad de jQuery y obtenemos el Angular como un marco y no la biblioteca.

El enlace de datos bidireccional es asombroso: tenía una cuadrícula con todas las funciones ACTUALIZAR, ENCONTRAR, INSERTAR. Tengo un objeto de datos que une el modelo de la cuadrícula usando ng-repeat. Solo necesitas escribir una sola línea de código JavaScript simple para eliminar e insertar y eso es todo. La cuadrícula se actualiza automáticamente a medida que el modelo de cuadrícula cambia instantáneamente. La funcionalidad de actualización es en tiempo real, no hay código para ello. ¡¡¡Te sientes increíble!!!

Las directivas reutilizables son super: escriba directivas en un solo lugar y úselas en toda la aplicación. ¡¡¡DIOS MIO!!! Utilicé esta directiva para paginación, expresiones regulares, validaciones, etc. ¡Es realmente genial!

El enrutamiento es sólido: depende de su implementación cómo desea usarlo, pero requiere muy pocas líneas de código para enrutar la solicitud para especificar HTML y controlador (JavaScript)

Los controladores son excelentes: los controladores se encargan de su propio HTML, pero esta separación funciona bien para la funcionalidad común. Si desea llamar a la misma función con el clic de un botón en el HTML maestro, simplemente escriba el mismo nombre de función en cada controlador y escriba un código individual.

Complementos: hay muchas otras características similares, como mostrar una superposición en su aplicación. No necesita escribir código para ello, solo use un complemento de superposición disponible como wc-overlay, y esto se encargará automáticamente de todas las solicitudes XMLHttpRequest (XHR).

Ideal para arquitectura RESTful : ser un marco completo hace que AngularJS sea ideal para trabajar con una arquitectura RESTful. Llamar a las API REST CRUD es muy fácil y

Servicios : Escriba códigos comunes usando servicios y menos código en los controladores. Los servicios pueden usarse para compartir funcionalidades comunes entre los controladores.

Extensibilidad : Angular ha ampliado las directivas HTML utilizando directivas angulares. Escribir expresiones dentro de html y evaluarlas en tiempo de ejecución. Cree sus propias directivas y servicios y utilícelos en otro proyecto sin ningún esfuerzo adicional.

Answer 7

Esas son algunas respuestas muy bonitas, pero largas.

Para resumir mis experiencias:

1. Los controladores y proveedores (servicios, fábricas, etc.) son para modificar el modelo de datos, NO HTML.
2. HTML y directivas definen el diseño y el enlace al modelo.
3. Si necesita compartir datos entre controladores, cree un servicio o una fábrica, son singletons que se comparten en la aplicación.
4. Si necesita un widget HTML, cree una directiva.
5. Si tiene algunos datos y ahora está intentando actualizar HTML ... ¡PARE! actualice el modelo y asegúrese de que su HTML esté vinculado al modelo.

Answer 8

Para describir el "cambio de paradigma", creo que una respuesta corta puede ser suficiente.

AngularJS cambia la forma en que encuentras los elementos.

En jQuery , normalmente usas selectores para encontrar elementos y luego los conectas:
$(''#id .class'').click(doStuff);

En AngularJS , usa directivas para marcar los elementos directamente, para cablearlos:
<a ng-click="doStuff()">

AngularJS no necesita (o quiere) a encontrar los elementos que utilizan selectores - la principal diferencia entre AngularJS de jqLite frente en toda regla jQuery es que jqLite no soporta selectores .

Entonces, cuando la gente dice "no incluyas jQuery en absoluto", es principalmente porque no quieren que uses selectores; quieren que aprendas a usar directivas en su lugar. Directo, no seleccionar!

Answer 9

jQuery es una biblioteca de manipulación de DOM.

AngularJS es un framework MV *.

De hecho, AngularJS es uno de los pocos marcos de trabajo de JavaScript MV * (muchas herramientas de JavaScript MVC aún se encuentran en la biblioteca de categorías).

Al ser un marco, aloja su código y se apropia de las decisiones sobre qué llamar y cuándo.

AngularJS incluye en sí mismo una edición jQuery-lite. Por lo tanto, para una selección / manipulación de DOM básica, realmente no tiene que incluir la biblioteca jQuery (ahorra muchos bytes para ejecutarse en la red).

AngularJS tiene el concepto de "Directivas" para la manipulación de DOM y el diseño de componentes reutilizables de la interfaz de usuario, por lo que debe usarlo siempre que sienta la necesidad de hacer cosas relacionadas con la manipulación de DOM (las directivas solo son lugares donde debe escribir código jQuery mientras usa AngularJS).

AngularJS implica alguna curva de aprendizaje (más que jQuery :-).

-> Para cualquier desarrollador que provenga de los antecedentes de jQuery, mi primer consejo sería "¡aprender JavaScript como un lenguaje de primera clase antes de saltar a un marco rico como AngularJS!" Aprendí el hecho anterior de la manera difícil.

Buena suerte.

Answer 10

Como principiante en MV * de MV * y que se centra exclusivamente en la arquitectura de la aplicación (no en el lado del servidor / cliente), recomendaría el siguiente recurso (que me sorprende que aún no se haya mencionado): Patrones de diseño de JavaScript , por Addy Osmani , como una introducción a diferentes patrones de diseño de JavaScript . Los términos utilizados en esta respuesta están tomados del documento vinculado anterior. No voy a repetir lo que estaba muy bien redactado en la respuesta aceptada. En su lugar, esta respuesta enlaza con los antecedentes teóricos que impulsan a AngularJS (y otras bibliotecas).

Al igual que yo, pronto se dará cuenta de que AngularJS (o Ember.js , Durandal, y otros marcos MV *) es un marco complejo que reúne muchos de los diferentes patrones de diseño de JavaScript.

También me resultó más fácil probar (1) el código JavaScript nativo y (2) las bibliotecas más pequeñas para cada uno de estos patrones por separado antes de sumergirse en un marco global. Esto me permitió comprender mejor qué problemas cruciales aborda un marco (porque usted se enfrenta personalmente con el problema).

Por ejemplo:

• Programación orientada a objetos de JavaScript (este es un enlace de búsqueda de Google). No es una biblioteca, pero ciertamente es un requisito previo para cualquier programación de aplicaciones. Me enseñó las implementaciones nativas de los patrones de prototipo, constructor, singleton y decorador.
• jQuery / Underscore para el patrón de fachada (como WYSIWYG para manipular el DOM)
• Prototype.js para el patrón prototipo / constructor / mixin
• RequireJS / Curl.js para el patrón de módulo / AMD
• KnockoutJS para el patrón observable, publicación / suscripción

NB: esta lista no está completa, ni ''las mejores bibliotecas''; Simplemente resultan ser las bibliotecas que he usado. Estas bibliotecas también incluyen más patrones, los mencionados son solo sus enfoques principales o intenciones originales. Si cree que falta algo en esta lista, por favor mencione en los comentarios, y con gusto lo agregaré.

Answer 11

En realidad, si estás usando AngularJS, ya no necesitas jQuery. AngularJS tiene el enlace y la directiva, que es un "reemplazo" muy bueno para la mayoría de las cosas que puedes hacer con jQuery.

Normalmente desarrollo aplicaciones móviles usando AngularJS y Cordova . Lo ÚNICO de jQuery que necesitaba es el Selector.

Al buscar en Google, veo que hay un módulo selector jQuery independiente por ahí. Es Sizzle.

Y decidí hacer un pequeño fragmento de código que me ayude a iniciar rápidamente un sitio web usando AngularJS con el poder de jQuery Selector (usando Sizzle).

Compartí mi código aquí: https://github.com/huytd/Sizzular

Answer 12

Escuche el podcast JavaScript Jabber: Episodio # 32 que presenta a los creadores originales de AngularJS: Misko Hevery & Igor Minar. Hablan mucho sobre cómo es venir a AngularJS desde otros fondos de JavaScript, especialmente jQuery.

Uno de los puntos señalados en el podcast hizo que muchas cosas hicieran clic para mí con respecto a su pregunta:

MISKO : [...] una de las cosas en las que pensamos muy poco en Angular es, ¿cómo proporcionamos un montón de escotillas de escape para que pueda salir y, básicamente, encontrar una manera de salir de esto? Así que para nosotros, la respuesta es esta cosa llamada "Directivas". Y con las directivas, esencialmente te conviertes en un pequeño jQuery JavaScript regular, puedes hacer lo que quieras.

IGOR : Entonces, piense en la directiva como la instrucción al compilador que le dice cada vez que encuentra este elemento determinado o este CSS en la plantilla, y mantiene este tipo de código y ese código está a cargo del elemento y todo lo que está debajo de ese elemento en el arbol DOM.

Una transcripción de todo el episodio está disponible en el enlace proporcionado anteriormente.

Por lo tanto, para responder directamente a su pregunta: AngularJS es muy crítico y es un verdadero marco de MV *. Sin embargo, aún puedes hacer todas las cosas realmente geniales que conoces y amas con jQuery dentro de las directivas. No es una cuestión de "¿Cómo hago lo que solía hacer en jQuery?" tanto como es una cuestión de "¿Cómo suplemento AngularJS con todo lo que solía hacer en jQuery?"

Son realmente dos estados mentales muy diferentes.

Answer 13

Me parece interesante esta pregunta, porque mi primera exposición seria a la programación de JavaScript fue Node.js y AngularJS. Nunca aprendí jQuery, y creo que eso es algo bueno, porque no tengo que desaprender nada. De hecho, evito activamente las soluciones jQuery para mis problemas, y en su lugar, solo busco una "forma AngularJS" para resolverlos. Entonces, supongo que mi respuesta a esta pregunta se reduciría esencialmente a "pensar como alguien que nunca aprendió jQuery" y evitar cualquier tentación de incorporar jQuery directamente (obviamente, AngularJS lo usa en cierta medida detrás de escena).

Answer 14

Son manzanas y naranjas. No quieres compararlos. Son dos cosas diferentes. AngularJs ya tiene jQuery lite incorporado, lo que te permite realizar una manipulación básica de DOM sin siquiera incluir la versión completa de jQuery.

jQuery tiene que ver con la manipulación de DOM. Resuelve todo el problema del navegador cruzado, de lo contrario, tendrá que lidiar con él, pero no es un marco que le permita dividir su aplicación en componentes como AngularJS.

Lo bueno de AngularJs es que le permite separar / aislar la manipulación DOM en las directivas. Existen directivas integradas listas para su uso, como ng-click. Puede crear sus propias directivas personalizadas que contendrán toda su lógica de visualización o la manipulación de DOM para que no termine de mezclar el código de manipulación de DOM en los controladores o servicios que deben hacerse cargo de la lógica empresarial.

Angular descompone su aplicación en - Controladores - Servicios - Vistas - etc.

Y hay una cosa más, esa es la directiva. Es un atributo que puede adjuntar a cualquier elemento DOM y puede volverse loco con jQuery dentro de él sin tener que preocuparse de que jQuery entre en conflicto con los componentes de AngularJs o se confunda con su arquitectura.

Escuché de una reunión a la que asistí, uno de los fundadores de Angular dijo que trabajaron muy duro para separar la manipulación de DOM, así que no intentes incluirlos de nuevo

Answer 15

jQuery: piensas mucho en ''CONSULTA DEL DOM '' para elementos DOM y hacer algo.

AngularJS: EL modelo es la verdad, y siempre piensas desde ese ÁNGULO.

Por ejemplo, cuando obtiene datos del servidor THE que pretende mostrar en algún formato en el DOM, en jQuery, necesita ''1. ENCONTRAR ''donde en el DOM desea colocar estos datos, el'' 2. ACTUALICE / APÉNDICE ''allí creando un nuevo nodo o simplemente configurando su innerHTML . Luego, cuando quiera actualizar esta vista, entonces ''3. ENCUENTRA ''la ubicación y'' 4. ACTUALIZAR''. Este ciclo de encontrar y actualizar todo hecho en el mismo contexto de obtención y formato de datos del servidor desaparece en AngularJS.

Con AngularJS tiene su modelo (objetos de JavaScript a los que ya está acostumbrado) y el valor del modelo le informa sobre el modelo (obviamente) y sobre la vista, y una operación en el modelo se propaga automáticamente a la vista, por lo que no lo hace. t tiene que pensar en ello Te encontrarás en AngularJS que ya no encuentra cosas en el DOM.

En otras palabras, en jQuery, debes pensar en los selectores de CSS, es decir, dónde está el divo tdque tiene una clase o atributo, etc., para que pueda obtener su HTML o color o valor, pero en AngularJS, Te encontrarás pensando así: con qué modelo estoy tratando, estableceré el valor del modelo en verdadero. No se está molestando en si la vista que refleja este valor es una casilla marcada o reside en un tdelemento (detalles que a menudo habría tenido que pensar en jQuery).

Y con la manipulación de DOM en AngularJS, te encuentras agregando directivas y filtros, que puedes considerar como extensiones HTML válidas.

Una cosa más que experimentará en AngularJS: en jQuery usted llama mucho a las funciones de jQuery, en AngularJS, AngularJS llamará a sus funciones, entonces AngularJS "le dirá cómo hacer las cosas", pero los beneficios valen la pena, así que aprender AngularJS Por lo general, significa aprender lo que quiere AngularJS o la forma en que AngularJS requiere que presente sus funciones y las llame en consecuencia. Esta es una de las cosas que hace de AngularJS un marco en lugar de una biblioteca.