mirror of
https://github.com/Raghu-Ch/angular-challenges.git
synced 2026-02-10 12:53:03 -05:00
feat(docs): translate performance pages to spanish
This commit is contained in:
@@ -0,0 +1,26 @@
|
|||||||
|
---
|
||||||
|
title: 🟢 @RouterInput()
|
||||||
|
description: El desafío 22 trata sobre el uso del decorador @Input para utilizar parámetros del router.
|
||||||
|
author: thomas-laforge
|
||||||
|
challengeNumber: 22
|
||||||
|
command: angular-router-input
|
||||||
|
blogLink: https://medium.com/ngconf/accessing-route-params-in-angular-1f8e12770617
|
||||||
|
sidebar:
|
||||||
|
order: 5
|
||||||
|
---
|
||||||
|
|
||||||
|
## Información
|
||||||
|
|
||||||
|
En esta aplicación, tomaremos tres pedazos de información dentro de nuestro `TestComponent` proporcionadas por el router:
|
||||||
|
|
||||||
|
- Queremos obtener el `testId` que tenemos como parte de los parámetros de la URL.
|
||||||
|
- Queremos obtener `user` ubicado dentro de los parámetros de consulta (query params) de la URL.
|
||||||
|
- Queremos acceder a `permission` establecido dentro del objeto `data` de la ruta.
|
||||||
|
|
||||||
|
En las versiones 15 o anteriores de Angular, usamos `ActivatedRoute` para obtener toda esta información y recibirla a través de observables para escuchar los cambios de URL.
|
||||||
|
|
||||||
|
En la versión 16, Angular introdujo un nuevo `Input` que puede 'escuchar' los datos de la ruta. Puedes leer más al respecto [aquí](https://medium.com/ngconf/accessing-route-params-in-angular-1f8e12770617).
|
||||||
|
|
||||||
|
## Declaración
|
||||||
|
|
||||||
|
El objetivo de este ejercicio es refactorizar el código para usar la nueva estrategia `RouterInput`.
|
||||||
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: 🟠 Optimizar el Change Detection al desplazarse
|
||||||
|
description: Desafío 12 sobre la optimización del número de ciclos de detección de cambios al desplazarse
|
||||||
|
author: thomas-laforge
|
||||||
|
challengeNumber: 12
|
||||||
|
command: performance-scroll-cd
|
||||||
|
sidebar:
|
||||||
|
order: 107
|
||||||
|
---
|
||||||
|
|
||||||
|
## Información
|
||||||
|
|
||||||
|
En Angular, hay una biblioteca llamada <b>Zone.js</b> que realiza mucha magia para simplificar la vida del desarrollador. Zone.js parchea todos los eventos del DOM para que vuelva a verificar y volver a renderizar la vista cuando algo ha cambiado dentro de la aplicación. El desarrollador no tiene que activar manualmente la detección de cambios.
|
||||||
|
|
||||||
|
Sin embargo, a veces Zone.js activa mucha más detección de cambios de la necesaria. Por ejemplo, cuando se está escuchando un evento de desplazamiento, cada evento de desplazamiento generará un nuevo ciclo de detección de cambios.
|
||||||
|
|
||||||
|
En este desafío, solo necesitamos actualizar la vista en una posición de desplazamiento específica para mostrar u ocultar un botón. Todos los demás ciclos son innecesarios.
|
||||||
|
|
||||||
|
Para tener una mejor visualización del problema, perfila tu aplicación con Angular Dev Tools.
|
||||||
|
|
||||||
|
:::note
|
||||||
|
Si no sabes cómo usarlo, lee [la página de introducción al rendimiento](/es/challenges/performance/) primero y vuelve después.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Puedes obtener más detalles sobre la contaminación de la zona y cómo resolverla [aquí](https://angular.io/guide/change-detection-zone-pollution).
|
||||||
|
|
||||||
|
El siguiente video explicará más a fondo el problema de esta aplicación.
|
||||||
|
|
||||||
|
<video controls src="https://user-images.githubusercontent.com/30832608/209819211-58d9ddcf-e1ad-4a78-8a7a-2be9d729e3f1.mov">
|
||||||
|
</video>
|
||||||
|
|
||||||
|
## Enunciado
|
||||||
|
|
||||||
|
Tu objetivo para este desafío es evitar todos los ciclos de detección de cambios innecesarios y activar una detección de cambios solo cuando sea necesario.
|
||||||
|
|
||||||
|
## Restricción:
|
||||||
|
|
||||||
|
No puedes optar por no usar Zone.js globalmente. Si este código forma parte de un proyecto grande y optas por no usar Zone.js, sin duda romperás tu aplicación.
|
||||||
@@ -0,0 +1,55 @@
|
|||||||
|
---
|
||||||
|
title: 🟢 Default vs OnPush
|
||||||
|
description: El desafío 34 trata sobre aprender la diferencia entre las estrategias de detección de cambios Default y OnPush.
|
||||||
|
author: thomas-laforge
|
||||||
|
challengeNumber: 34
|
||||||
|
command: performance-default-onpush
|
||||||
|
sidebar:
|
||||||
|
order: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
## Información
|
||||||
|
|
||||||
|
En este desafío, exploraremos las diferencias e impactos de usar `ChangeDetectionStrategy.Default` versus `ChangeDetectionStrategy.OnPush`.
|
||||||
|
|
||||||
|
Puedes leer la [documentación de Angular](https://angular.io/guide/change-detection-skipping-subtrees) para aprender más sobre las diferencias entre estas estrategias.
|
||||||
|
|
||||||
|
En este desafío, todos los componentes comienzan con la estrategia `Default`. Cuando escribas letras dentro del campo de entrada, notarás que todos los componentes se resaltan en naranja.
|
||||||
|
|
||||||
|
:::note[Nota]
|
||||||
|
Agregué resaltado de color a cada componente y cada fila para proporcionar una mejor visualización de cuándo se vuelve a renderizar un componente.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Como puedes ver, cada letra desencadena un nuevo ciclo de detección de cambios, y todos los componentes se vuelven a renderizar, lo que causa problemas de rendimiento.
|
||||||
|
|
||||||
|
Utilicemos la <b>Angular DevTool</b> para perfilar nuestra aplicación y comprender cómo esta herramienta puede ayudarnos a entender qué está sucediendo dentro de nuestra aplicación.
|
||||||
|
|
||||||
|
:::note[Nota]
|
||||||
|
Si no sabes cómo usarlo, lee primero [la página de introducción al rendimiento](/es/challenges/performance/) y vuelve después.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Ahora, comienza a perfilar tu aplicación y escribe algunas letras dentro del campo de entrada para desencadenar algunos ciclos de detección de cambios.
|
||||||
|
|
||||||
|
Si haces clic en una de las barras (indicada por la flecha amarilla en la imagen a continuación), puedes ver que `PersonListComponent`, `RandomComponent` y todos los `MatListItem` se ven afectados por el ciclo de detección de cambios, incluso cuando solo interactuamos con el campo de entrada.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Enunciado
|
||||||
|
|
||||||
|
El objetivo de este desafío es mejorar el agrupamiento de la detección de cambios dentro de la aplicación utilizando la estrategia de detección de cambios `OnPush`, pero no solo eso...
|
||||||
|
|
||||||
|
## Pistas:
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Pista 1</summary>
|
||||||
|
|
||||||
|
Utiliza `ChangeDetectionStrategy.OnPush`, pero esto no será suficiente.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Pista 2</summary>
|
||||||
|
|
||||||
|
Crea componentes más pequeños para separar mejor el campo de entrada de la lista.
|
||||||
|
|
||||||
|
</details>
|
||||||
@@ -0,0 +1,50 @@
|
|||||||
|
---
|
||||||
|
title: 🟢 Memoización
|
||||||
|
description: El desafío 35 trata sobre cómo funcionan las tuberías puras
|
||||||
|
author: thomas-laforge
|
||||||
|
challengeNumber: 35
|
||||||
|
command: performance-memoized
|
||||||
|
sidebar:
|
||||||
|
order: 8
|
||||||
|
---
|
||||||
|
|
||||||
|
<div class="chip">Desafío #35</div>
|
||||||
|
|
||||||
|
## Información
|
||||||
|
|
||||||
|
En Angular, las <b>tuberías puras</b> son muy poderosas porque el valor se memoiza, lo que significa que si el valor de entrada no cambia, la función `transform` de la tubería no se vuelve a calcular y se emite el valor en caché.
|
||||||
|
|
||||||
|
Puedes aprender más sobre las tuberías en la [documentación de Angular](https://angular.io/guide/pipes) y en este [artículo de inmersión profunda](https://medium.com/ngconf/deep-dive-into-angular-pipes-c040588cd15d).
|
||||||
|
|
||||||
|
En este desafío, comenzamos con un botón para cargar una lista de personas. Cada persona está asociada con un número y utilizaremos el cálculo de Fibonacci para crear una computación pesada que ralentizará la aplicación.
|
||||||
|
|
||||||
|
Una vez que se carga la lista, intenta escribir algunas letras dentro del campo de entrada. Te darás cuenta de que la aplicación es muy lenta, a pesar de que solo estás realizando una escritura muy básica.
|
||||||
|
|
||||||
|
:::note[Nota]
|
||||||
|
No nos centraremos en la carga inicial de la lista en este desafío.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Utilicemos la <b>Angular DevTool</b> para perfilar nuestra aplicación y comprender cómo esta herramienta puede ayudarnos a entender qué está sucediendo dentro de nuestra aplicación.
|
||||||
|
|
||||||
|
:::note[Nota]
|
||||||
|
Si no sabes cómo usarlo, lee primero [la página de introducción al rendimiento](/es/challenges/performance/) y vuelve después.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Ahora, comienza a perfilar tu aplicación y escribe algunas letras dentro del campo de entrada. Verás que aparecen algunas barras rojas en el panel del perfilador.
|
||||||
|
|
||||||
|
Si haces clic en una de las barras (indicada por la flecha amarilla en la imagen a continuación), verás que el ciclo de detección de cambios está tardando más de 3 segundos en `PersonListComponent`.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Enunciado
|
||||||
|
|
||||||
|
El objetivo de este desafío es comprender qué está causando esta latencia y mejorarla.
|
||||||
|
|
||||||
|
## Pistas:
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Pista 1</summary>
|
||||||
|
|
||||||
|
Utiliza `Pipes` para memoizar el cálculo de Fibonacci.
|
||||||
|
|
||||||
|
</details>
|
||||||
@@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
title: 🟢 Optimización de NgFor
|
||||||
|
description: El Desafío 36 trata sobre como funciona trackby
|
||||||
|
author: thomas-laforge
|
||||||
|
challengeNumber: 36
|
||||||
|
command: performance-ngfor-optimize
|
||||||
|
sidebar:
|
||||||
|
order: 13
|
||||||
|
---
|
||||||
|
|
||||||
|
## Información
|
||||||
|
|
||||||
|
En esta aplicación, tenemos una lista de individuos que podemos agregar, eliminar o actualizar. Si abres el panel de desarrollador de Chrome presionando **F12**, ve a la pestaña <b>source</b> y expande el elemento para ver la lista, notarás que cada vez que agregas, eliminas o actualizas un elemento de la lista, se destruyen y vuelven a inicializar todos los elementos del DOM. (Ver video a continuación).
|
||||||
|
|
||||||
|
<video controls src="https://github.com/tomalaforge/angular-challenges/assets/30832608/71b90307-3ee3-42c0-a532-b67ce4f20bf6">
|
||||||
|
</video>
|
||||||
|
|
||||||
|
También podemos usar la <b>Angular DevTool</b> para perfilar nuestra aplicación y entender qué está sucediendo dentro de ella. Te mostraré cómo hacerlo en el siguiente video.
|
||||||
|
|
||||||
|
<video controls src="https://github.com/tomalaforge/angular-challenges/assets/30832608/dd8108c6-1d89-4b05-9aa5-e760bd6f7f11">
|
||||||
|
</video>
|
||||||
|
|
||||||
|
:::note
|
||||||
|
Si no sabes cómo usarlo, lee primero [la página de introducción al rendimiento](/es/challenges/performance/) y vuelve después.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Si necesitas más información sobre `NgFor`, te invito a leer primero la [documentación](https://angular.io/api/common/NgFor).
|
||||||
|
|
||||||
|
## Enunciado
|
||||||
|
|
||||||
|
El objetivo de este desafío es entender qué está causando esta actualización del DOM y solucionarlo.
|
||||||
@@ -0,0 +1,32 @@
|
|||||||
|
---
|
||||||
|
title: 🟠 Optimizando una lista larga
|
||||||
|
description: El desafio 37 trata sobre como optimizar una lista grande de elementos
|
||||||
|
author: thomas-laforge
|
||||||
|
challengeNumber: 37
|
||||||
|
command: performance-ngfor-biglist
|
||||||
|
sidebar:
|
||||||
|
order: 117
|
||||||
|
---
|
||||||
|
|
||||||
|
## Información
|
||||||
|
|
||||||
|
En esta aplicación, renderizaremos una lista de 100,000 individuos al hacer clic en el botón loadList. Si abres el panel de desarrollo de Chrome presionando F12, ve al ícono de <b>Fuente</b> y expande el elemento para ver la lista, notarás que los 100,000 elementos se renderizan en el DOM, aunque solo podemos ver alrededor de 20 elementos en el área visible. Este proceso lleva mucho tiempo, por lo que la aplicación es muy lenta al mostrar la lista.
|
||||||
|
|
||||||
|
Podemos utilizar la <b>Herramienta de Desarrollo de Angular</b> para perfilar nuestra aplicación y entender lo que está sucediendo en su interior. Te mostraré cómo hacerlo en el siguiente video.
|
||||||
|
|
||||||
|
<video controls src="https://github.com/tomalaforge/angular-challenges/assets/30832608/713403fa-2eda-49d5-a7c9-acdef8aacd34">
|
||||||
|
</video>
|
||||||
|
:::[nota]
|
||||||
|
Si no sabes cómo usarlo, lee la página de introducción al rendimiento primero y regresa después.
|
||||||
|
:::
|
||||||
|
|
||||||
|
Enunciado
|
||||||
|
El objetivo de este desafío es implementar una alternativa mejor para mostrar una lista grande de elementos.
|
||||||
|
|
||||||
|
Pistas:
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Pista 1</summary>
|
||||||
|
Si no estás seguro por dónde empezar, te recomiendo leer la documentación de virtualización de Angular CDK.
|
||||||
|
|
||||||
|
</details>
|
||||||
49
docs/src/content/docs/es/challenges/performance/index.mdx
Normal file
49
docs/src/content/docs/es/challenges/performance/index.mdx
Normal file
@@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
title: Rendimiento en Angular
|
||||||
|
prev: false
|
||||||
|
next: false
|
||||||
|
description: Aprende a usar la extensión de Chrome Angular Devtools.
|
||||||
|
noCommentSection: true
|
||||||
|
sidebar:
|
||||||
|
order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
import { LinkCard } from '@astrojs/starlight/components';
|
||||||
|
|
||||||
|
En esta serie de desafíos sobre rendimiento, aprenderás cómo optimizar y mejorar el rendimiento de tu aplicación Angular.
|
||||||
|
|
||||||
|
Antes de comenzar a resolver cualquier desafío, te invito a descargar la [extensión de Chrome Angular DevTools](https://chrome.google.com/webstore/detail/angular-devtools/ienfalfjdbdpebioblfackkekamfmbnh) si aún no lo has hecho.
|
||||||
|
|
||||||
|
Esta extensión te permite perfilar tu aplicación y detectar problemas de rendimiento, lo cual es muy útil para entender dónde pueden ocurrir problemas de rendimiento.
|
||||||
|
|
||||||
|
## Cómo usarlo
|
||||||
|
|
||||||
|
Cuando sirves una aplicación Angular, puedes inspeccionar una página presionando <b>F12</b>, lo cual abrirá las <b>herramientas de desarrollo de Chrome</b>. Luego navega a la <b>pestaña Angular</b>. Desde allí, puedes seleccionar la <b>pestaña Profiler</b> como se muestra a continuación.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Ahora puedes perfilar tu aplicación haciendo clic en el botón de grabación. Puedes interactuar con tu aplicación y ver cuándo se activa la detección de cambios y qué componentes se vuelven a renderizar.
|
||||||
|
|
||||||
|
:::tip[Aprende más]
|
||||||
|
Puedes obtener más información en la [página de documentación](https://angular.io/guide/devtools).
|
||||||
|
:::
|
||||||
|
|
||||||
|
Ahora que sabes cómo usar la Angular DevTool, puedes elegir un desafío, perfilarlo y resolverlo.
|
||||||
|
|
||||||
|
<LinkCard
|
||||||
|
title="🟢 Default vs OnPush"
|
||||||
|
description="Aprende la diferencia entre las estrategias de detección de cambios Default y OnPush."
|
||||||
|
href="/challenges/performance/34-default-onpush/"
|
||||||
|
/>
|
||||||
|
|
||||||
|
<LinkCard
|
||||||
|
title="🟢 Memoization"
|
||||||
|
description="Aprende sobre el poder de los pure pipes."
|
||||||
|
href="/challenges/performance/35-memoize/"
|
||||||
|
/>
|
||||||
|
|
||||||
|
<LinkCard
|
||||||
|
title="🟠 Optimizando el Change Detection"
|
||||||
|
description="Aprende sobre como optimizar tu aplicacion entendiendo bien el change detection en Angular"
|
||||||
|
href="/challenges/performance/12-scroll-cd/"
|
||||||
|
/>
|
||||||
Reference in New Issue
Block a user