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




usar jquery en angularjs (10)

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 .

https://code.i-harness.com


¿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.


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.


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.


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?


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.

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!


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é.


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


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).


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





angularjs