jquery-plugins español - jQuery Desplazarse hacia la parte inferior de la página




2018 create (9)

$('html,body').animate({ scrollTop: 9999 }, 'slow');

Tan simple como esto, altura de página 9999 ... gran alcance para que pueda llegar al fondo.

Después de que mi página termine de cargar. Quiero que jQuery se deslice suavemente al final de la página, animando rápidamente, no un chasquido / sacudida.

¿Necesito un complemento como ScrollTo para eso? o está integrado en jQuery de alguna forma?


algo como esto:

var $target = $('html,body'); 
$target.animate({scrollTop: $target.height()}, 1000);

$("div").scrollTop(1000);

Funciona para mi. Se desplaza hacia la parte inferior.


js

var el = document.getElementById("el");
el.scrollTop = el.scrollHeight - el.scrollTop;

Usando 'document.body.clientHeight' puede obtener la altura vista de los elementos del cuerpo

$('html, body').animate({
    scrollTop: $("#particularDivision").offset().top - document.body.clientHeight + $("#particularDivision").height()
}, 1000);

esto se desplaza en el id 'particularDivisión'


Puedes intentar esto

var scroll=$('#scroll');
scroll.animate({scrollTop: scroll.prop("scrollHeight")});

Puede animar para desplazarse hacia abajo por la página animando la propiedad scrollTop , no se requiere ningún complemento, como este:

$(window).load(function() {
  $("html, body").animate({ scrollTop: $(document).height() }, 1000);
});

Tenga en cuenta el uso de window.onload (cuando se cargan imágenes ... que ocupan altura) en lugar de document.ready .

Para ser técnicamente correcto, debe restar la altura de la ventana, pero lo anterior funciona:

$("html, body").animate({ scrollTop: $(document).height()-$(window).height() });

Para desplazarse a una ID particular, use su .scrollTop() , como este:

$("html, body").animate({ scrollTop: $("#myID").scrollTop() }, 1000);

$('#pagedwn').bind("click", function () {
        $('html, body').animate({ scrollTop:3031 },"fast");
        return false;
});

Esta solución funcionó para mí. Está trabajando en la página Desplazarse hacia abajo rápidamente.


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-plugins