DEV Community: DevJoseManuel

Test componentes que usan Redux

DevJoseManuel — Wed, 01 May 2024 07:08:18 +0000

En este artículo vamos a ver los pasos que tenemos que dar para poder testear un componente que esté usando un store de Redux y para ello la mejor forma de hacerlo es mostrando un componente que esté haciendo uso de Redux. Así pues supongamos que en nuestro proyecto tenemos un fichero denominado counterSlice.ts y dentro del mismo vamos a escribir el siguiente código:



import { createSlice } from '@reduxjs/toolkit'
import type { PayloadAction } from '@reduxjs/toolkit'

export interface CounterState {
  value: number
}

const initialState: CounterState = {
  value: 0
}

export const counterSlice = createSlice({
  name: 'counter',
  initialState,
  reducers: {
    increment: state => {
      state.value += 1
    },
    decrement: state => {
      state.value -= 1
    },
    incrementByAmount: (state, action: PayloadAction<number>) => {
      state.value += action.payload
    }
  }
})

export const { increment, decrement, incrementByAmount } = counterSlice.actions

export default counterSlice.reducer

Sin entrar en demasiados detalles del código anterior simplemente mencionar que estamos creando un slice gracias a Redux Toolkit que se denomina counter y este slice lo que hace es guardar la información de un objeto que tiene un único atributo denominado value de tipo númerico. Además, el slice nos ofrece laas posibilidades de incrementar en uno, decrementar en uno o incrementar en una cantidad que nosotros queramos el valor de este contador gracias al uso de los acciones increment, decrement e incrementByAmount respectivamente.

** Nota:** el código anterior está sacado de la documentación de Redux Toolkit. Si se quiere obtener más información de qué representa y cómo funciona se recomienda acudir a la esa misma documentación aquí.

Además vamos a tene definido el fichero store.ts en el que se llevarán a cabo todas las operaciones que nos van a permitir inicializar Redux en nuestra aplicación y cuyo código sería algo como lo siguiente:



import { configureStore } from '@reduxjs/toolkit'
import counterReducer from './counterSlice'

export const store = configureStore({
  reducer: {
    counter: counterReducer
  }
})

export type RootState = ReturnType<typeof store.getState>
export type AppDispatch = typeof store.dispatch

Componente

Una vez tenemos el store de Redux creado el siguiente paso que tenemos que dar consistirá en crear el componente de React que pase a usarlo. Así pues creamos el fichero ReduxCounter.tsx cuyo código será el que podemos ver a continuación:



import { useSelector, useDispatch } from 'react-redux'
import { RootState, decrement, increment } from './counterSlice'

export const ReduxCounter = () => {
  const count = useSelector((state: RootState) => state.counter)
  const dispatch = useDispatch()

  return (
    <div>
      <button
        aria-lable="Increment value"
        onClick={() => dispatch(increment())}
      >
        Increment
      </button>
      <span role="contentinfo">{count}</span>
      <button
        aria-lable="Decrement value"
        onClick={() => dispatch(decrement())}
      >
        Decrement
      </button>
    </div>
  )
}

En el código anterior lo que estamos haciendo es traernos los hook useSelector y useDispatch que son propios de Redux además de las acciones que han sido definidas dentro del slice counterSlice de tal manera que obtenemos el valor actual del contados que está recogido en Redux además de utilizar dispatch para poder ejectar las acciones sobre el store de Redux cuando se pulse sobre los botones para incrementar o decrementar el valor del contador.

Test

La pregunta que surge ahora es ¿qué tenemos que hacer para poder testear nuestro componente? Para ello lo que vamos a hacer es crear el fichero ReduxCounter.test.tsx y dentro del mismo lo que haremos será importarnos todas aquellas funciones que vamos a necesitar desde la React Testing Library así como el código de componente que vamos a probar:



import { render, screen, fireEvent } from '@testing-library/react'
import { ReduxCounter } from './ReduxCounter'

Ahora vamos a definir el test que queremos llevar a cabo en el código y para ello comenzaremos definiendo una nueva suite de test:



describe('ReduxCounter', () => {})

y dentro de la misma comenzaremos escribiendo el primero de nuestros test que será el encargado de comprobar que al pulsar sobre el botón Increment se estará incrementando el valor del contador:



describe('ReduxCounter', () => {
  it('increment', () => {})
})

Bien, como sucede con cualquier otro componente en React cuando lo estemos probando lo primero que vamos a tener que hacer es renderizarlo gracias al uso de la función render que nos proporciona React Testing Library:



describe('ReduxCounter', () => {
  it('increment', () => {
    render(<ReduxCounter />)
  })
})

Hecho esto lo siguiente que vamos a hacer es obtener el contenido del <span> al que le hemos asignado el role de contentinfo con el fin de asegurar que en el momento en el que se está renderizando el componente este tendrá el valor 0 (es decir, que 0 es el valor inicial de partida para el contador):



describe('ReduxCounter', () => {
  it('increment', () => {
    render(<ReduxCounter />)

    const counter = screen.getByRole('contentinfo')
    expect(counter).toHaveTextContent('0')
  })
})

El siguiente paso que daremos será obtener el botón que nos permitirá incrementar el valor de nuestro contador y pulsarlo:



describe('ReduxCounter', () => {
  it('increment', () => {
    render(<ReduxCounter />)

    const counter = screen.getByRole('contentinfo')
    expect(counter).toHaveTextContent('0')

    const addButton = screen.getByText(/Increment/i)
    fireEvent.click(addButton)
  })
})

y si todo funciona tal cual esperaríamos al pulsar sobre este botón Increment el nuevo valor del contador debería ser 1 puesto que se habrá incrementado en una unidad por lo que escribimos la aserción que se encargará de realizar esta comprobación:



describe('ReduxCounter', () => {
  it('increment', () => {
    render(<ReduxCounter />)

    const counter = screen.getByRole('contentinfo')
    expect(counter).toHaveTextContent('0')

    const addButton = screen.getByText(/Increment/i)
    fireEvent.click(addButton)

    expect(counter).toHaveTextContent('1')
  })
})

Nota: el código con el que hemos estado trabajando no cumple el formato de test AAA (Arrange-Action-Assert) porque estamos mezclando cada una de estas secciones pero está hecho así a posta para no alargar demasiado la explicación. Lo correcto sería que tuviésemos más test en nuestro código como por ejemplo uno que asegurase que el valor inicial del contador es 0 y no tener que realizar la aserción en el medido de nuestros test como hemos hecho en el código que hemos ido desarrollando.

Si guardamos nuestro trabajo y ejecutamos este test en la consola nos vamos a encontrar con un error como el que se puede ver en la siguiente imagen:

es decir que no se ha podido renderizar el componente pueto que cualquier componente que esté haciendo uso de Redux siempre va a tener que tener asociado un Provider que le proporcione el acceso al mismo.

Por lo tanto la solución a este problema pasará por proporcionárselo al componente y para ello lo primero que tendremos que hacer será importar el componente Provider de la libraría react-redux como sigue:



import { Provider } from 'react-redux'

lo que hace que a continuación envolvamos el componente ReduxCounter dentro del mismo (o dicho de otra manera, haremos que ReduxCounter pase a ser un children de Provider):



render(
  <Provider>
    <ReduxCounter />
  </Provider>
)

Ahora bien, en este momento tenemos que saber que el Provider de Redux precisa recibir como prop el store con el que estará trabajando por lo que vamos también a importar nuestro store:



import { store } from './store'

Y el siguiente paso será proporcionárlo al Provider en su prop store:



render(
  <Provider store={store}>
    <ReduxCounter />
  </Provider>
)

Al final esto nos deja de la definición del test para probrar la funcionalidad asociada al botón Increment tal y como se puede ver a continuación:



describe('ReduxCounter', () => {
  it('increment', () => {
    render(
      <Provider store={store}>
        <ReduxCounter />
      </Provider>
    )

    const counter = screen.getByRole('contentinfo')
    expect(counter).toHaveTextContent('0')

    const addButton = screen.getByText(/Increment/i)
    fireEvent.click(addButton)

    expect(counter).toHaveTextContent('1')
  })
})

De tal manera que si ahora guardamos nuestro trabajo y volvemos a ejecutar los test obtendremos que todos ellos pasarán correctamente tal y como esperábamos:

Problemas adicionales

Con todo esto parece que hemos logrado resolver nuestro problema pero es un poco más complicado puesto que tenemos que saber que Redux es una parte de nuestra aplicación que es global a toda ella lo que quiere decir que con lo que acabamos de hacer en el test anterior lo que hemos logrado es que el valor del contador dentro del store de Redux tenga el valor 1 incluso fuera del test que acabamos de crear.

¿Qué queremos decir con esto? Pues la mejor manera es verlo nuevamente con un ejemplo y para ello supongamos que duplicamos el test que acabamos de crear pero esta vez lo llamamos increment again dejando algo como lo siguiente:



describe('ReduxCounter', () => {
  it('increment', () => {
    render(
      <Provider store={store}>
        <ReduxCounter />
      </Provider>
    )

    const counter = screen.getByRole('contentinfo')
    expect(counter).toHaveTextContent('0')

    const addButton = screen.getByText(/Increment/i)
    fireEvent.click(addButton)

    expect(counter).toHaveTextContent('1')
  })

  it('increment again', () => {
    render(
      <Provider store={store}>
        <ReduxCounter />
      </Provider>
    )

    const counter = screen.getByRole('contentinfo')
    expect(counter).toHaveTextContent('0')

    const addButton = screen.getByText(/Increment/i)
    fireEvent.click(addButton)

    expect(counter).toHaveTextContent('1')
  })
})

Pues aunque nos pueda parecer lo contrario estará fallando la primera de las dos aserciones que estamos realizando en el segundo de los test puesto que estamos intentando comprobar que el contenido del contador cuando comienza la ejecución de nuestro test es 0 y sin embargo tiene el valor 1 puesto que se ha visto incrementado tras la ejecución del primero de nuestros test:

¿Qué solución tenemos para ello? Pues para ello vamos a hacer una pequeña modificación en el fichero store.ts de tal manera que asígnaremos la función configureStore con los parámetros que crean nuestro store de Redux a una variable:



export const createStore = configureStore({
  reducer: {
    counter: counterReducer
  }
})

y la creación del store ahora simplemente se conseguirá invocando a dicha función:



export const store = createStore()

Esto nos deja el código del fichero store.ts como se puede ver en la siguiente imagen:



import { configureStore } from '@reduxjs/toolkit'
import counterReducer from './counterSlice'

export const createStore = configureStore({
  reducer: {
    counter: counterReducer
  }
})

export const store = createStore()

export type RootState = ReturnType<typeof store.getState>
export type AppDispatch = typeof store.dispatch

¿Cuál es el objetivo de todo esto? Pues que en el momento en el que estemos asignando la prop store del Provider de Redux lo que vamos a hacer es crear un nuevo store cada vez que se vaya a ejecutar cada uno de los test (o dicho de otra manera, en cada uno de los test que necesitan del Provider de Redux lo que vamos a hacer es crear un store nuevo).

Así pues en nuestro test importaremos la función createStore:



import { createStore } from './store'

y ahora pasamos a usarla en los test que hemos definido lo que nos deja algo como lo siguiente:



describe('ReduxCounter', () => {
  it('increment', () => {
    render(
      <Provider store={createStore()}>
        <ReduxCounter />
      </Provider>
    )

    const counter = screen.getByRole('contentinfo')
    expect(counter).toHaveTextContent('0')

    const addButton = screen.getByText(/Increment/i)
    fireEvent.click(addButton)

    expect(counter).toHaveTextContent('1')
  })

  it('increment again', () => {
    render(
      <Provider store={createStore()}>
        <ReduxCounter />
      </Provider>
    )

    const counter = screen.getByRole('contentinfo')
    expect(counter).toHaveTextContent('0')

    const addButton = screen.getByText(/Increment/i)
    fireEvent.click(addButton)

    expect(counter).toHaveTextContent('1')
  })
})

Si ahora guardamos el código de nuestros test podremos comprobar como ambos pasarán correctamente tal y como esperábamos:

Nota: No desarrollamos los test para el botón Decrement porque el razonamiento que se ha de seguir es exactamente el mismo que hemos hecho para Increment y así no alargaremos más la explicación.

Código completo

El código completo de nuestro test es el que podemos ver a continuación:



import { render, screen, fireEvent } from '@testing-library/react'
import { Provider } from 'react-redux'
import { createStore } from './store'
import { ReduxCounter } from './ReduxCounter'

describe('ReduxCounter', () => {
  it('increment', () => {
    render(
      <Provider store={createStore()}>
        <ReduxCounter />
      </Provider>
    )

    const counter = screen.getByRole('contentinfo')
    expect(counter).toHaveTextContent('0')

    const addButton = screen.getByText(/Increment/i)
    fireEvent.click(addButton)

    expect(counter).toHaveTextContent('1')
  })
})

Type Guards & Type Assertions

DevJoseManuel — Tue, 30 Apr 2024 07:52:29 +0000

En este artículo vamos a ver cómo podemos filtrar correctamente los elementos de un array quedándonos con los tipos que tienen asociados los elementos que lo conforman. Para ello vamos a suponer que partimos de un tipo de datos ResponseData que viene a simular la respuesta que nos ha proporcionado un API y dicho dato solamente tiene un atributo denominado data que es de tipo string:

type ResponseData = {
  data: string
}

Ahora vamos a suponer que definimos un array de elementos que concuerdan con este tipado pero sin establecer que el array está formado por elementos de este tipo pudiendo de esta manera afirmar que está incluyendo objetos del tipo ResponseData:

const items = [{ data: 'Banana' }, { data: 'Dog' }]

Para hacer las cosas más interesantes vamos a añadir algún elemento más al array que estamos asignando a items que sea undefined dejándolo definitivamente tal y como vemos a continuación:

const items = [{ data: 'Banana' }, undefined, { data: 'Dog' }, undefined]

Ahora que tenemos nuestro conjunto de datos de partida lo que vamos a hacer es añadir la anotación del tipo que estará asociado con items que sabemos que será un array de que estará formado por objetos del tipo ResponseData o undefined, es decir, que lo definimos como sigue:

const items: (ResponseData | undefined)[] = [
  { data: 'Banana' },
  undefined,
  { data: 'Dog' },
  undefined
]

Vamos ahora a definir una función que se encargue de filtrarnos todos los elementos del array que no son undefined por lo que escribiremos algo como lo siguiente:

const payloads = items.filter(items => item !== undefined)

Y ya para terminar vamos a escribir en la consola del sistema todos aquellos elementos que forman parte del array payloads que, de forma intuitiva, podemos ver que se tratará de todos aquellos que no son undefined lo que nos dejará un código final que será similar al que se puede ver a continuación:

type ResponseData = {
  data: string
}

const items: (ResponseData | undefined)[] = [
  { data: 'Banana' },
  undefined,
  { data: 'Dog' },
  undefined
]

const payloads = items.filter(items => item !== undefined)

console.log(payloads)

Vamos a guardar nuestro trabajo y a ejecutar nuestro código simplemente para comprobar que este se está comportando tal y como se espera que lo haga:

Problema

Como podemos observar todo ha funcionado tal y como esperábamos que lo hiciese pero si lo que hacemos es situar el cursor del ratón sobre la declaración del array payloads para que Visual Studio Code nos muestre cuál es el tipado que tiene asignado veremos que este seguirá siendo un array de objetos ResponseData o undefined como se puede ver en la siguiente imagen:

De forma ideal nos gustaría que a partir del filtrado que hemos realizado sea capaz de inferir cuál es el tipo que tendrá asignado a items sabiendo que este sería un array formado por elementos que son únicamente del tipo ResponseData.

Pero ¿cómo podemos lograr esto? Pues gracias a los Type Guards de TypeScript.

Type Guard

¿Pero en qué consiste crear un Type Guard? Pues en nuestro caso es que a partir de la función que tenemos asignada a la función que estamos pasando como argumento al método filter() tenemos que definir el tipo de datos que retornará y esto lo hacemos gracias al uso de la palabra reservada is de TypeScript como sigue:

const payloads = items.filter(
  (items): item is ResponseData => item !== undefined
)

De esta manera que lo que estamos diciéndole a TypeScript es que le podemos asegurar que el resultado de la ejecución de dicha función es del tipo ResponseData de tal manera que si ahora ponemos el cursor sobre la definición de la variable payloads podemos ver que TypeScript nos indica que será un array de objetos de tipo ResponseData:

Es más, para ser mucho más explícitos podemos extraer el Type Guard a una función separada. Así pues vamos a crear una función a la que vamos a denominar isResponseData de tal manera que recibirá camo argumento un valor que puede ser de tipo RespondeData o undefined donde ademanas definiremos como tipo de retorno un Type Predicate como sigue:

function isResponseData(item: ResponseData | undefined): item is ResponseData {}

Dentro de la función isResponseData lo que haremos será comprobar si el valor del parámetro es undefined o no de tal manera que si lo es retornaremos true y en caso contrario retornaremos false:

function isResponseData(item: ResponseData | undefined): item is ResponseData {
  return item !== undefined
}

Con la declaración de nuestro Type Guard como una función ahora vamos a podérsela pasar como argumento al método filter() dejándonos el siguiente código completo donde mostramos todos los cambios que hemos realizado hasta este momento:

type ResponseData = {
  data: string
}

const items: (ResponseData | undefined)[] = [
  { data: 'Banana' },
  undefined,
  { data: 'Dog' },
  undefined
]

function isResponseData(item: ResponseData | undefined): item is ResponseData {
  return item !== undefined
}

const payloads = items.filter(isResponseData)

console.log(payloads)

Si ahora guardamos nuestros cambios y volvemos a ejecutar nuestro código veremos que efectivamente nos volverá a mostrar por la consola un nuevo array de elementos que incluirán únicamente todos aquellos que no son undefined como se puede ver en la siguiente imagen:

y no solamente eso sino que además si ponemos el cursor dentro de Visual Studio Code sobre la variable payloads vemos que TypeScript es capaz de indicarnos que es del tipo ResponseData[] tal y como esperábamos:

Desventajas del uso de los Type Guards

Vamos a ver ahora las desventajas que están asociados al uso de los Type Guards tal y como hemos hecho hasta ahora y el principal error es que a la hora de definir el Type Predicate que está asociado a la función que ejerce de Type Guard es posible que la podamos definir con un tipo de datos que no le corresponda.

Por poner un ejemplo más claro a partir del código que hemos estado utilizando a lo largo de esta explicación, lo que tratamos de decir es que es posible declarar la función isResponseData como sigue:

function isResponseData(item: ResponseData | undefined): item is undefined {
  return item !== undefined
}

y en este caso el tipo de datos que se inferirá para la variable payloads será un array de elementos undefined como podemos imaginarnos a partir de lo que acabamos de definir:

es decir que estamos diciendo que el array de los elementos que retorna isResponseData es una array de elementos undefined cuando viendo el código de esta función podemos estar seguros de que no es así. ¿Qué conclusión podemos sacar de esto? Pues que el Type Predicate que hemos utiliado en la definición de nuestro Type Guard sobreescribirá la inferencia de tipos que pueda llegar a hacer TypeScript:

Esto además es un problema desde el punto de vista del desarrollo porque mientras estamos construyendo nuestro software TypeScript nos dejará trabajar con payloads teniendo en cuenta que lo interpretará como un array de undefined pese a que esto no es realmente así siendo esta la razón por la que se recomienda que todos los Type Predicates que tengamos declarados en nuestro código siempre estén supervisados por tests.

Asertion Functions

Vamos a ver ahora otro caso que será la implementación de una Asertion Function para lo cual deberemos hacer uso de la palabra assert que nos proporciona TypeScript que puede transformar un Type Guard en una Type Assertion. Pero ¿cómo se hace esto en el código? Pues vamos a verlo en nuestro ejemplo:

function isResponseData(item: ResponseData | undefined): assert item is ResponseData {
}

Y no solamente eso sino que además tendremos que cambiar la implementación de nuestro isResponseData porque en lugar de retornar un valor booleano deberemos lanzar un Error en el caso de que no se cumpla la condición que se quiere comprobar con la ejecución de la función. ¿Qué quiere esto decir? Pues que en nuestro caso el código de la Type Assertion sería algo como lo siguiente:

function isResponseData(item: ResponseData | undefined): assert item is ResponseData {
  if (item === undefined) {
    throw new Error('It is undefined')
  }
}

De esta manera el compilador de TypeScript es capaz de deducir que en el caso de que se pase la vetificación que se lleva a cabo en el Type Assertion (es decir, que no se lanza un error), entonoces se tipo de datos que tendrá asociado será un ResponseData gracias a cómo está declarado el código dentro de la función.

Ahora bien, aunque esto es correcto no es una buena aproximación a seguir para ser utilizada como una argumento del método filter() puesto que lanzará un Error si no se cumple la condición y por lo tanto detendrá la ejecución del programa en el caso de que no sea capturado:

Nota: es importante tener en cuenta que los Type Assertions pueden lanzar errores en tiempo de ejecución y por lo tanto interrumpir la ejecución de nuestros programas mientras que los Type Guards lo que pueden llegar a provocar es que se produzcan errores en tiempo de construcción.

Por lo tanto ¿Cuándo deberíamos usar una Assertion Function? Pues sin duda alguna cuando tengamos que realizar algún tipo de validación en tiempo de ejecución mientras que los Type Guard son perfectos para cuando necesitamos hacer un narrowing type (extrechar el tipo de datos) durante el tiempo de compilación.

Higher Order Functions

DevJoseManuel — Mon, 29 Apr 2024 08:47:55 +0000

En este artículo vamos a ver qué son las Higher Order Functions y cómo podemos aplicarlas para lograr que nuestro código sea mucho más funcional. Pero antes de nada ¿qué es una Higher Order Function? Pues no es más que una función que toma como argumento una o más funciones o bien es una función que retorna a su vez otra función como resultado de su invocación.

Pero ¿esto cómo es posible? Pues lo primero que tenemos que pensar es que en JavaScript las funciones son un tipo de datos más como lo son los tipos primitivos o los objectos (lo que se conoce a su vez como first class citizens). Esto quiere decir que las funciones van a poder ser utilizadas el código como se utilizan el resto de los valores con los que podemos trabajar.

¿Y qué nos permite esto? Pues es una forma de lograr la composición de funciones dentro de nuestro código con el fin de lograr nuevas funcionalidades a partir de las que ya tenemos construidas.

Es más deberíamos pensar en el uso de las Higher Order Functions principalmente por dos razones. La primera de ellas es que van a hacer que nuestro código sea mucho más legible porque tras ellas quedarán ocultos varios detalles de implementación que no nos tienen que preocupar cuando las estemos utilizando y por otra parte nos permitirán lograr que nuestro código sea mucho más reutilizable.

Funciones sobre arrays.

Es más que probable que sin saberlo ya hayas utilizado Higher Order Functions cuando has estado programando en JavaScript puesto que las funciones map(), filter() o reduce() que nos proporciona el lenguaje para trabajar con los arrays en el código son consideradas Higher Order Functions.

Para entender cómo funcionan las Higher Order Functions vamos a centrarnos en primer lugar en estos métodos asociados a los arrays y para ello vamos a trabajar con los arrays. Para ello vamos a definir un array de números como sigue:

const data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Si ahora queremos invocar al método map() sobre el array que acabamos de definir lo primero que tenemos que saber es que este método espera recibir como argumento una función que a su vez puede tener definidos hasta 3 argumentos siendo el primero de ellos el elemento del array sobre el que se está iterando, el segundo el índice que está asociado sobre ese elemento dentro de la iteración y el tercero el array en sí mismo.

De esta manera si lo que queremos lograr es un nuevo array que contenga los mismos elementos que el array data pero donde cada uno de ellos sea el elemento de data multiplicado por dos lo que escribiríamos sería algo como lo que se puede ver a continuación:

const data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
const mapped = data.map(n => n * 2)

console.log({ mapped })

Si ahora ejecutamos nuestro código en la terminal del sistema nos vamos a encontrar algo parecido a lo que se puede ver en la siguiente imagen:

Higher Order Functions

Pensemos ahora en el argumento que le estamos pasando al método map() puesto que se trata a su vez de una función y como tal la vamos a poder extraer a una variable como sigue:

const double = n => n * 2

es decir que estamos ante una función que tomará como argumento un número y lo que hará será devolvernos el valor de ese número multiplicado por dos (doblado). Ahora podemos aplicar esta función a nuestro código pasándola como argumento del método map() como sigue:

const data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

const double = n => n * 2
const mapped = data.map(double)

console.log({ mapped })

y si volvemos a ejecutar nuestro código el resultado que vamos a obtener por la consola volverá a ser exactamente el mismo que habíamos obtenido anteriormente tal y como esperamos que así sea:

Una de las cosas que tenemos que asegurar cuando estamos pasando funciones como argumentos de las Higher Order Functions es que la función que vamos a pasar deberá seguir la firma (entiendo como tal, que sigue la definición de los argumentos) que a su vez espera la Higher Order Function y de esta manera que pueda ser aplicada como argumento.

¿Lioso? Seguro que sí porque es más difícil explicarlo de palabra que verlo con un ejemplo. En nuestro caso recordemos los tres argumentos que map() espera que la función que recibe como parámetro reciba:

por lo tanto la función double (la que estamos pasando a la Higher Order Function) deberá tratar el primero de sus parámetros como un número para que funcione correctamente. ¿Qué quiere esto decir? Pues que la función double podría tener una declaración completa en la que además del número recibiese el índice y el array sobre el que se está trabajando:

const double = (n, index, array) => n * 2

Nota: en definitiva lo que estamos tratando de decir es que en el caso de que vayamos a definir una función para ser utilizada como parámetro de una Higher Order Function deberemos asegurarnos de que admitirá los argumentos con los que se debería operar.

Método `filter()`

Vamos a verlo ahora con el método filter() que nos proporcionan los arrays pero en este caso supongamos que vamos a definir la función que pasaremos como argumento a este método de tal manera que nos proporcione aquellos elementos del array que son número pares sabiendo que estos serán aquellos números que al dividirlos por 2 el resto que nos dejan será cero. Por lo tanto definimos:

const data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

const even = (n, index, array) => n % 2 === 0
const filtered = data.filter(even)

console.log({ filtered })

Esta forma de trabajar es exactamente la misma que en el caso del método map() que hemos descrito anteriormente pero también podríamos haber pensado en crear nuestra propia implementación de una función filter que actúe como una Higher Order Function. Para ello vamos a comenzar definiendo una nueva función en nuestro código que llamaremos filter y que espera recibir dos argumentos: el primero de ellos un array y el segudo un callback function:

const filter = (arr, func) => {}

Nota: recordemos que en la definición que hemos dado de una Higher Order Function hemos dicho que será cualquier función que tome como argumento una función por lo que en el caso de esta implementación de filter que estemos desarrollando estaremos ante una Higher Order Function.

Dentro del código de la función filter lo que vamos a hacer es definir un nuevo array que contendrá los resultados de aplicar la función filter y recorreremos todos los elementos del array que se ha recibido como argumento:

const filter = (arr, func) => {
  const result = []

  for (let i = 0; i < arr.length; i++ >) { }
}

En cada una de las iteraciones del bucle lo que vamos a hacer es llamar a la callback función func a la que le vamos a pasar el elemento del array que se está procesando sabiendo que esta función ha de retornar true en el caso de que se cumpla el filtro o false en caso contrario. De esta manera si el resultado de la invocación de la función es truelo que tendremos que hacer será depositar el elemento que se está procesando en el array de resultados y en el caso de que sea false lo que haremos será saltárnoslo:

const filter = (arr, func) => {
  const result = []

  for (let i = 0; i < arr.length; i++ >) {
    if (func(arr[i])) {
      result.push(arr[i])
    }
  }
}

Para terminar la implementación de nuestra función filter ya solamente nos quedará retornar el array con todos los resultados de que se han obtenido:

const filter = (arr, func) => {
  const result = []

  for (let i = 0; i < arr.length; i++ >) {
    if (func(arr[i])) {
      result.push(arr[i])
    }
  }

  return result
}

Ahora que hemos construido nuestra propia implementación del método filter() de los arrays vamos a utilizarla en el código que estamos desarrollando y de hecho vamos a volver a desarrollar el ejemplo que habíamos hecho anteriormente y para ello definiremos la función even que servirá para obtener los elementos que son pares dentro de un array como sigue:

const even = filter(data, n => n % 2 === 0)

Como vemos definimos la función even como el resulado de la función filter que esperará recibir un array de datos (en el argumento data) y como callback function le pasamos una que recibe un número como argumento y retornará true en el caso de se trate un número par o false si se trata de un número par.

Si además añadimos el código que nos permitirá escribir por la consola el resultado de que está recogido en even nos vamos a encontrar con algo como lo que se puede ver a continuación:

const data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

const filter = (arr, func) => {
  const result = []

  for (let i = 0; i < arr.length; i++ >) {
    if (func(arr[i])) {
      result.push(arr[i])
    }
  }

  return result
}

const even = filter(data, n => n % 2 === 0)

console.log({ even })

Y si ejecutamos el código lo que obtendremos en la consola será algo parecido a lo que se puede ver en la siguiente imagen en la que efectivamente vemos que el array evenestá formado únicamente por los elementos que son pares dentro del array data tal y como esperábamos:

Por lo tanto ver que gracias al uso de las Higher Order Functions vamos a poder combinar varias funciones que están definidas dentro de nuestro código para lograr nuevas funcionalidades como cuando estamos usando filter() para quedarnos únicamente con los elementos pares de un array de números.

Renderizado de 10.000 filas en React

DevJoseManuel — Sun, 28 Apr 2024 07:43:43 +0000

En este artículo vamos a ver la forma en la que vamos a poder renderizar 10.000 filas de elementos de forma eficiente y para ello la cantidad de código que vamos a utilizar es más bien poca pero el grado de rendimiento (performance) que lograremos será muy alto.

Código de partida

Para entender bien el problema al que nos estamos enfrentando vamos a suponer que estamos ante el siguiente componente de React el cual tiene declara un atributo de su estado denominado users gracias al uso del hook useState:

import { useState } from 'react'

import { UserCard } from './components/UserCard'
import { createUsers } from './user'

export const App = () => {
  const [users, setUsers] = useState(createUsers)

  return (
    <div>
      {users.map(user => (
        <UserCard key={user.id} user={user} />
      ))}
    </div>
  )
}

En el código de nuestro componente podemos ver cómo el valor del atributo del estado users está siendo inicializado con el resultado de la invocación de la función createUsers que no es más que una función auxiliar dentro de nuestro código que se utilizará para crear un array de 10.000 usuarios sabiendo que un usuario User no es más que un objeto que tiene los atributos id y name:

export type User = {
  id: number
  name: string
}

export const createUsers = (from = 0, to = 10_000): User[] => {
  return Array.from({ length: to - from }, (_, i) => ({
    id: i + from,
    name: `User ${i + from}`
  }))
}

Siguiendo con el código del componente App y en lo que respecta a la parte del JSX lo que estamos haciendo iterar sobre todos los elementos que están recogidos en el atributo del estado users e iteramos sobre los mismos pasándoselos en la prop user del componente UserCard el cual es un componente muy sencillo en el que simplemente estaremos mostrando el nombre del usuario que se está recibiendo:

import { User } from './User'

export const UserCard = ({ user }: User) => {
  return <div>{user.name}</div>
}

Problema

Como podemos intuir el problema al que nos estamos enfrentando desde el punto de vista del rendimiento es que este será realmente pésimo si tomamos los 10.000 usuarios y los escribimos todos directamente gracias a la utilización de la función map como en el código que se ha presentado.

Solución

Para lograr solucionar el problema de rendimiento que hay detrás de situaciones como las que acabamos de describir una solución pasa por utilizar una librería de virtualización que nos ayude en nuestro trabajo. Pero ¿qué es eso de la virtualización? Pues se trata de un concepto realmente sencillo que lo que viene a decir es que únicamente se ha de renderizar un subconjunto de elementos en lugar de todos ellos en función de determinadas condiciones.

¿Y de qué tipo pueden ser estas condiciones? Pues en el caso de nuestro ejemplo lo que nos gustaría es que únicamente se renderizasen en el DOM aquellos usuarios que son visibles en el viewport (que en nuestro caso será la pantalla de un ordenador pero podría ser la pantalla de un dispositivo móvil o de una tablet).

De entre todas las opciones que tenemos a nuestra disposición nosotros nos vamos a decantar por el uso de la librería Virtuoso puesto que se trata de una de las librerías más populares para poder lograr el objetivo que estamos persiguiendo (la virtualización de los usuarios) además de ser un proyecto que está muy bien mantenido.

Nota: se puede obtener más información sobre Virtuoso en su sitio web.

Uso de Virtuoso

Como sucede con cualquier otra librería con la que podemos trabajar en nuestros proyectos lo primero que vamos a tener que hacer será instalarla para lo cual abriremos una terminal del sistema dentro de nuestro proyecto y ejecutaremos:

$ yarn add react-virtuoso

Una vez tenemos la librería instalada vamos a comenzar a hacer los cambios en el código que nos permitan trabajar con la librería y el primer cambio que vamos a realizar consistirá en eliminar el código que ejecta la función map() dentro del JSX para poder renderizar los usuarios puesto que nuestro objetivo será que Virtuoso sea el que acabe renderizando los usuarios:

export const App = () => {
  const [users, setUsers] = useState(createUsers)

  return <div></div>
}

Ahora deberemos importar Virtuoso para poder trabajar con la librería por lo que añadimos la siguiente línea de código:

import { Virtuoso } from 'react-virtuoso'

Nota: al haber instalado Virtuoso en nuestro proyecto vamos a tener muchos más componentes a nuestra disposición a partir de Virtuoso los cuáles iremos viendo a medida que vayamos avanzando en el artículo.

Una vez tenemos Virtuoso importado en nuestro componente su uso es muy sencillo puesto que simplemente deberemos escribir algo como lo siguiente:

export const App = () => {
  const [users, setUsers] = useState(createUsers)

  return (
    <div>
      <Virtuoso />
    </div>
  )
}

Evidentemente con el código anterior no habremos logrado nada puesto que Virtuoso va a necesitar utilizar tres props para lograr su objetivo. En primer lugar tenemos la prop data que es donde deberemos especificar los datos de partida de los que queremos que Virtuoso haga las tareas de virtualización. En nuestro caso estos datos serán los usuarios con los que estamos trabajando o, dicho de otra manera, el atributo del estado users.

<Virtuoso data={users} />

La segundo prop que tenemos que considerar esitemContent la cual es una función que será la que utilizaremos para que se pueda renderizar cada uno de los elementos que están virtualizados de forma individual. En nuestro caso lo que vamos a tener que hacer es proporcionarle una función que se encargue del renderizado de cada uno de los usuarios de forma individual. Si estamos usando un editor como VS Code para escribir nuestro código podemos ver que la función que debemos utilizar tiene que tener definida dos argumentos siendo el primero index (que es un número) y el segundo argumento será data que será del tipo de datos que está asociado a cada uno de los elementos que forman parte del array proporcionado en la prop data (que en nuestro caso serán del tipo User):

Como en nuestro caso no vamos a hacer uso del índice lo que haremos en la función que vamos a asignar a itemContent es establecer un caracter de subrayado _ como el primero de los parámetros puesto que esta es una convención de código que se sigue en el caso de que se especifique un argumento de una función pero que realmente no usaremos. Es más en el cuerpo de la función lo que haremos será llamar al componente UserCard pasándole el usuario que se ha recibido como segundo parámetro:

<Virtuoso data={users} itemContent={(_, user) => <UserCard user={user} />} />

Nota: es importante resaltar que cuando estamos usando la función itemContent para renderizar el contenido asociado a cada uno de los elementos que se están renderizando no es necesario hacer uso de la props key como sucede cuando estamos renderizando elementos con dentro de una iteración en JSX y la razón por la que esto no es necesario es porque Virtuoso estará proporcionándola por nosotros sin que nos demos cuenta.

Nos queda una tercera prop en la que le proporcionaremos a Virtuoso cuál es la altura actual (height) del componente puesto que es una pieza de información importante para poder determinar qué elementos serán visibles y cuáles no. Para proporcionar esta información podemos usar la prop style a la que le podemos asignar un objeto que define los estilos que queremos que se apliquen al componente Virtuoso. En nuestro caso vamos a suponer que el componente va a tener una altura de 200 píxeles por lo que escribiremos:

<Virtuoso
  data={users}
  itemContent={(_, user) => <UserCard user={user} />}
  style={{ height: 200 }}
/>

Ahora bien, suponiendo que en nuestro proyecto estamos usando Tailwind ¿cómo podemos especificar esta altura? Pues en estas situaciones tenemos que hacer uso de la prop className en al que especificaremos el tamaño que queremos para el componente con una exclamación ! delante para indicar de esta manera que el tamaño especificado es !important y por lo tanto que es el que ha de ser considerado:

<Virtuoso
  className="!h-[200px]"
  data={users}
  itemContent={(_, user) => <UserCard user={user} />}
/>

Nota:: la razón por la que hemos tenido que usar la exclamación para poder especificar el tamaño del componente Virtuoso es porque en el caso de que no especifiquemos nosotros una altura esta será determinada de forma automática por el Virtuoso y esa altura que se determina automáticamente tendrá más preferencia que la que se le asigne en la prop className. Sin embargo al hacer uso de la ! estaremos indicando que el valor especificado es !important desde el punto de vista de CSS y por lo tanto será el que se tendrá en cuenta como altura del componente.

El código completo del componente App que recoge todos los cambios que se han realizado para utilizar Virtuoso son los que se pueden ver a continuación:

import { useState } from 'react'
import { Virtuoso } from 'react-virtuoso'

import { UserCard } from './components/UserCard'
import { createUsers } from './user'

export const App = () => {
  const [users, setUsers] = useState(createUsers)

  return (
    <div>
      <Virtuoso
        className="!h-[200px]"
        data={users}
        itemContent={(_, user) => <UserCard user={user} />}
      />
    </div>
  )
}

Si ahora guardamos nuestro trabajo y nos dirigimos a nuestro navegador para ver cómo funciona nuestra aplicación nos encontraremos con algo parecido a lo que se puede ver en la siguiente imagen donde podemos ver que se hace scroll en la página y no tenemos ningún tipo de problema de rendimiento lo cual es justamente lo que queríamos:

Navegar de forma aleatoria a un elemento

Para poder seguir profundizando en el uso de Virtuoso vamos a crear un botón dentro de nuestra interfaz de usuario que al ser pulsado lo que haga sea navegar de forma aleatoria (haciendo scroll) a uno de los elementos del array de usuarios con el que estamos trabajando con la intención de ver cómo se comportará el rendimiento de nuestra aplicación en un caso como este.

Para lograr nuestro objetivo lo primero que vamos a hacer es crear una ref de React puesto que posteriormente se la vamos a proporcionar a Virtuoso para poder trabajar con ella dentro de la función que se encargará de navegar a un elemento concreto dentro del array de usuarios. Así comenzaremos escribiendo el siguiente código en el que importaremos todos los elementos adicionales que necesitaremos:

import { userRef, useState } from 'react'
import { Virtuoso, VirtuosoHandle } from 'react-virtuoso'

Y ahora lo que hacemos será declarar la ref con la que vamos a trabajar como sigue:

export const App = () => {
  const [users, setUsers] = useState(createUsers)
  const virtuosoRef = useRef<VirtuosoHandle>(null)

Una vez que tenemos la ref declarada en el código lo siguiente que vamos a tener que hacer es utilizarla dentro del código JSX para asignársela al componente Virtuoso como sigue:

<Virtuoso
  className="!h-[200px]"
  data={users}
  itemContent={(_, user) => <UserCard user={user} />}
  ref={virtuosoRef}
/>

Hecho esto el siguiente paso que vamos a tener que dar consistirá en la creación de un botón normal del HTML (es decir, en la creación de un nuevo elemento <button>) donde en su atributo onClick lo que vamos a hacer es, a través de la virtuosoRef llamar al método scrollToIndex() que nos proporcionará el cual espera recibir como parámetro un objeto donde en su atributo index lo que haremos será pasarle un valor aleatorio que represente el índice del array de usuarios al que queremos desplazarnos:

<button
  onClick={() => {
    virtuosoRef.current?.scrollToIndex({
      index: Math.random() * users.length
    })
  }}
>
  Scroll
</button>

Nota: simplemente recordar que Math.random() lo que hace es retornar un valor entre 0 y 1 que al multiplicarlo por el número de usuarios que tenemos lo que hará será proporcionarnos un número comprendido entre 0 y 9999.

Adicionalmente en el objeto con las opciones que se le pasan a scrollToIndex vamos a pasarle el atributo align en el que tenemos que especificar cómo queremos que se alinee el elemento al que se va a realizar el scroll con respecto al resto de los que se muestran dentro del Virtuoso siendo las posibilidades center (en el centro del los elementos que se renderizan), start (al inicio de las lista de elementos) y end al final. En nuestro caso vamos a decantarnos por la opción start:

<button
  onClick={() => {
    virtuosoRef.current?.scrollToIndex({
      align: 'center',
      index: Math.random() * users.length
    })
  }}
>
  Scroll
</button>

Por último vamos a añadir una clase de Tailwind para el botón deje un espacio (margen) con respecto a la lista de elementos:

<button
  className="mb-4"
  onClick={() => {
    virtuosoRef.current?.scrollToIndex({
      align: 'center',
      index: Math.random() * users.length
    })
  }}
>
  Scroll
</button>

Si ahora guardamos nuestra aplicación y volvemos al navegador podemos ver que inicialmente se estarán mostrando los usuarios que inicialmente van entran dentro del espacio (altura) que le hemos asignado a Virtuoso pero cuando pulsamos sobre el botón Scroll podemos ver cómo se realiza el desplazamiento a uno de ellos de forma aleatoria quedando el elemento seleccionado (el elemento al que se va a desplazar) en el centro:

Como podemos ver el desplazamiento que se produce en la lista de usuarios se produce de forma instantánea lo cual totalmente deseable y mejora el rendimiento de nuestra aplicación. Podemos pulsar tantas veces como queramos en el botón y el desplazamiento se producirá de forma instantánea.

Otra de las opciones que tenemos a la hora de definir cómo queremos que se lleve realice el scroll al elemento que se ha seleccionado de forma aleatoria es gracias a la definición del atributo behavior dentro del objeto de propiedades que recibe el método scrollToIndex() que podrá adoptar los valores auto (que es el valor por defecto) o smooth (que hará que el desplazamiento sea mucho más suave):

<button
  className="mb-4"
  onClick={() => {
    virtuosoRef.current?.scrollToIndex({
      align: 'center',
      behavior: 'smooth',
      index: Math.random() * users.length
    })
  }}
>
  Scroll
</button>

Y si ahora guardamos nuestro trabajo y volvemos al navegador podemos observar como al pulsar sobre el botón Scroll el desplazamiento será mucho más suave:

Nota: tenemos que entender que internamente Virtuoso lo que está haciendo es tener en cuenta el tamaño que tiene que asignado (altura), determinar cuántos elementos podrán ser renderizados dentro de el y únicamente renderizará aquellos que dentro del índice que se está mostrando quepan dentro del dicho tamaño.

El código del componente completo tras incorporar todas las modificaciones que acabamos de explicar es el que se puede ver a continuación:

import { useState } from 'react'
import { Virtuoso, VirtuosoHandle } from 'react-virtuoso'

import { UserCard } from './components/UserCard'
import { createUsers } from './user'

export const App = () => {
  const [users, setUsers] = useState(createUsers)
  const virtuosoRef = useRef<VirtuosoHandle>(null)

  return (
    <div>
      <button
        className="mb-4"
        onClick={() => {
          virtuosoRef.current?.scrollToIndex({
            align: 'center',
            behavior: 'smooth',
            index: Math.random() * users.length
          })
        }}
      >
        Scroll
      </button>
      <Virtuoso
        className="!h-[200px]"
        data={users}
        itemContent={(_, user) => <UserCard user={user} />}
        ref={virtuosoRef}
      />
    </div>
  )
}

Uso de Virtuoso con una tabla.

Vamos a ir un paso más adelante viendo como podemos usar Virtuoso cuando la lista de los usuarios que vamos a renderizar está dentro de una tabla puesto que este es uno de los casos de uso más habituales que nos podemos encontrar cuando tenemos que trabajar con grandes cantidades de datos.

Lo primero que vamos a tener que hacer es cambiar el componente Virtuoso por el componente TableVirtuoso por lo que lo que vamos hacer es definir el import que necesitaremos:

import { TableVirtuoso, VirtuosoHandle } from `react-virtuoso`

E inicialmente el único cambio que vamos a tener que hacer en el código JSX con el que estamos trabajando hasta ahora será reemplazar el la llamada al componente Virtuoso por la llamada al componente TableVirtuoso como se puede ver a continuación:

<TableVirtuoso
  className="!h-[200px]"
  data={users}
  itemContent={(_, user) => <UserCard user={user} />}
  ref={virtuosoRef}
/>

De todas maneras para que TableVirtuoso funcione correctamente vamos a necesitar pasarle alguna prop más. Ahora bien, teniendo en cuenta que TableVirtuoso lo que espera es que en la función que está asociada a itemContent deberá renderizar elementos que forman parte de una tabla. Esto quiere decir que, en nuestro caso, como estamos haciendo uso del componente UserCard para renderizar cada uno de los elementos de la lista con la que estamos trabajando lo que vamos a hacer es modificar el código para que renderice filas de la tabla:

import { User } from './user'

export const UserCard = ({ user }: { user: User }) => {
  return (
    <>
      <td>{user.id}</td>
      <td>{user.name}</td>
    </>
  )
}

Nota: en el caso de estar trabajando con un TableVirtuoso lo que tenemos que pensar es que el código JSX que ha de retornar la función definida en su prop itemContent será encerrado entre nodos <tr> de HTML (es decir, que formarán una fila de la tabla) razón por la que estaremos devolviendo elementos <td> en el codigo anterior.

Es más, como estamos trabajando con una tabla deberíamos tener una manera de poder especificar cuáles los encabezados de esta tabla y para ello TableVirtuoso nos ofrece la prop fixedHeaderContent la cual espera recibir como valor una función que ha de retornar un ReactNode (código JSX) pero en este caso tendremos que especificar que queremos que se cree una nueva fila en la tabla (la primera que quedará fija) y el encabezado que representa el contenido de las columnas, por lo que escribiremos algo como lo siguiente:

<TableVirtuoso
  className="!h-[200px]"
  data={users}
  fixedHeaderContent={() => ({
    <tr>
      <th className='w-[150px] bg-grayscale-700 text-left'>Id</th>
      <th className='w-[150px] bg-grayscale-700 text-left'>Name</th>
    </tr>
  })}
  itemContent={(_, user) => <UserCard user={user} />}
  ref={virtuosoRef}
/>

Si ahora guardamos nuestro trabajo y nos vamos al navegador nos encontraremos algo como lo que se puede ver en la siguiente imagen donde vemos que podemos hacer scroll sobre los elementos de la tabla dejando fijo el encabezado que hemos definido tal y como esperábamos:

Y no solamente eso sino que además si pulsamos sobre el botón Scroll el funcionamiento del scroll seguirá siendo el mismo que hemos visto anteriormente:

El código completo cuando estamos trabajando con tablas de elementos con Virtuoso que recogerá los cambios que hemos estado describiendo hasta este punto será el que se puede ver a continuación:

import { useState } from 'react'
import { TableVirtuoso, VirtuosoHandle } from `react-virtuoso`

import { UserCard } from './components/UserCard'
import { createUsers } from './user'

export const App = () => {
  const [users, setUsers] = useState(createUsers)
  const virtuosoRef = useRef<VirtuosoHandle>(null)

  return (
    <div>
      <button
        className="mb-4"
        onClick={() => {
          virtuosoRef.current?.scrollToIndex({
            align: 'center',
            behavior: 'smooth',
            index: Math.random() * users.length
          })
        }}
      >
        Scroll
      </button>
      <TableVirtuoso
        className="!h-[200px]"
        data={users}
        fixedHeaderContent={() => ({
          <tr>
            <th className='w-[150px] bg-grayscale-700 text-left'>Id</th>
            <th className='w-[150px] bg-grayscale-700 text-left'>Name</th>
          </tr>
        })}
        itemContent={(_, user) => <UserCard user={user} />}
        ref={virtuosoRef}
      />
    </div>
  )
}

Nota: en lo que respecta a las posibilidades de personalización de la tabla son muchas teniendo en cuenta que podemos personalizar tantos los elementos del encabezado como cada uno de los elementos que forman las filas de la tabla.

Datos paginados

Hasta ahora hemos visto la forma en la que gracias a Virtuoso vamos a poder renderizar una gran cantidad de elementos de forma eficiente en nuestras aplicaciones de React pero lo más probable es que en un proyecto real en el que estemos trabajando lo habitual sea que no tengamos todos los elementos a mostrar de una única vez sino que los vayamos obteniendo de forma paginada.

Para ver cómo podemos solucionar este tipo de situaciones vamos a comenzar haciendo unos pequeños cambios en el código que hemos desarrollado hasta ahora comenzando por la función createUsers donde en vez de crear los 10_000 usuarios de una única vez y retornarlo vamos a crear algo más razonable como podrían ser 20 usuarios. Así, cuando dentro del componente App llamemos a createUsers para obtener el número de usuarios con el que vamos a trabajar simplemente invocaremos a createUsers pasándole como parámetros 0 y 20 para indicar de esta manera que queremos obtener los 20 primeros usuarios.

export const App = () => {
  const [users, setUsers] = useState(() => createUsers(0, 20))

El siguiente paso que vamos a dar será crear la función que nos permita obtener la siguiente página de datos, es decir, los siguientes 20 usuarios que se han de mostrar en la página. Así pues escribiremos:

const fetchNextPage = () => {
  const newUsers = createUsers(users.length, users.length + 20)
  setUsers([...users, ...newUsers])
}

Como podemos observar lo que estamos haciendo es volver a llamar a la función createUser pero en este caso la petición de usuarios comenzará por el número de usuarios que tenemos hasta este momento (tras la primera llamada serán los 20 primeros usuarios) y como segundo el tamaño de la página (el número de usuarios que se han de mostrar) es el que dicta que queremos los siguientes 20 usuarios, es decir, que tras la primera llamada querremos los usuarios que van desde el 20 hasta el 40.

Nota: evidentemente en una aplicación más compleja la forma de obtener la siguiente página de datos sería seguramente más compleja que lo que acabamos de mostrar pero a efectos de lo que estamos explicando esta manera nos ayuda a aclarar lo que queremos conseguir.

Por último en la función fetchNexPage simplemente lo que hacemos es actualizar el atributo del estado users con un nuevo array que tenga a los usuarios que había hasta ese momento más los nuevos que hemos obtenido.

La idea ahora es poder conectar a Virtuoso con la función fetchNextPage cuando se alcance el final de los datos que tiene en ese momento disponible para poder ser renderizados y de esta manera que sea el mismo quien se encargue de hacer la petición de la siguiente página. Para ello el componente TableVirtuoso (o el componente Virtuoso en el caso de que no estemos trabajando con datos dentro de una tabla) nos ofrece la prop endReached a la que se le debe asignar la función que queremos que sea ejecutada cuando se alcanza el final de los datos que se están mostrando. Por lo tanto escribiremos:

<TableVirtuoso
  className="!h-[200px]"
  data={users}
  endReached={fetchNextPage}
  fixedHeaderContent={() => ({
    <tr>
      <th className='w-[150px] bg-grayscale-700 text-left'>Id</th>
      <th className='w-[150px] bg-grayscale-700 text-left'>Name</th>
    </tr>
  })}
  itemContent={(_, user) => <UserCard user={user} />}
  ref={virtuosoRef}
/>

Si ahora guardamos nuestros cambios y nos vamos al navegador vemos que el scroll es fluido y que se van obteniendo los datos tal y como esperábamos:

El código completo del componente App una vez incorporamos todas las modificaciones que hemos ido realizando hasta ahora es el que se puede ver a continuación:

import { useState } from 'react'
import { TableVirtuoso, VirtuosoHandle } from `react-virtuoso`

import { UserCard } from './components/UserCard'
import { createUsers } from './user'

export const App = () => {
  const [users, setUsers] = useState(() => createUsers(0, 20))
  const virtuosoRef = useRef<VirtuosoHandle>(null)

  const fetchNextPage = () => {
    const newUsers = createUsers(users.length, users.length + 20)
    setUsers([...users, ...newUsers])
  }

  return (
    <div>
      <button
        className="mb-4"
        onClick={() => {
          virtuosoRef.current?.scrollToIndex({
            align: 'center',
            behavior: 'smooth',
            index: Math.random() * users.length
          })
        }}
      >
        Scroll
      </button>
      <TableVirtuoso
        className="!h-[200px]"
        data={users}
        endReached={fetchNextPage}
        fixedHeaderContent={() => ({
          <tr>
            <th className='w-[150px] bg-grayscale-700 text-left'>Id</th>
            <th className='w-[150px] bg-grayscale-700 text-left'>Name</th>
          </tr>
        })}
        itemContent={(_, user) => <UserCard user={user} />}
        ref={virtuosoRef}
      />
    </div>
  )
}

Datos asíncronos

Es más que probable que los datos a partir de los cuáles esté trabajando Virtuoso provengan de una fuente asíncrona como podría ser una llamada a una API así que vamos a detenernos unos instantes en ver cómo los podemos incorporar a nuestra implementación.

Para ello lo primero que vamos a hacer es crear un nuevo atributo del estado que se encargue de definir cuándo se están cargando los datos:

export const App = () => {
  const [users, setUsers] = useState(() => createUsers(0, 20))
  const [isLoading, setIsLoading] = useState(false)

Para simular la llamada asíncrona lo que vamos a hacer es convertir la función fetchNextPage en una función asíncrona y dentro de la misma vamos a hacer una llamada a una Promesa de JavaScript la cual será resuelta una vez pasa 1000 milisegundos (es decir, 1 segundo) de tal manera que lo que estaremos simulando es que la llamada para la obtención de los datos de la API será asíncrona:

const fetchNextPage = async () => {
  const newUsers = createUsers(users.length, users.length + 20)

  setIsLoading(true)
  await new Promise(resolve => setTimeout(resolve, 1_000))
  setIsLoading(false)

  setUsers([...users, ...newUsers])
}

En el código anterior podemos ver como además antes de que se llame a la Promisa de JavaScript estaremos estableciendo el valor del atributo del estado isLoading como true indicando de esta manera que se están cargando los datos y una vez se resuelve la Promesa establecemos el valor de este atributo a false indicando así que la carga de los datos ha finalizado.

Como podemos imaginar gracias al atributo del estado isLoading vamos a poder mostrarle al usuario un indicador que nos ayude a renderizar algo dentro de la interfaz de usuario que le indicará que los datos se están obteniendo. En el caso de TableVirtuoso tenemos a nuestra disposición la prop fixedFooterContent la cual espera tener asignada una función que se ejecutará cada vez que se re-renderice TableVirtuoso con el fin de mostrar el contenido del pie de la página.

¿Y qué es lo que queremos hacer nosotros? Pues simplemente que en el caso de que los datos se esté cargando (es decir, que el valor del atributo del estado isLoading sea true) mostraremos un mensaje de cargando información o en el caso de que no sea así simplemente retornaremos undefined indicando de esta manera que no se tiene que ejecutar ninguna función y por lo tanto no se escribirá nada en el pie de la tabla.

<TableVirtuoso
  className="!h-[200px]"
  data={users}
  endReached={fetchNextPage}
  fixedFooterContent={ isLoading
    ? () => <div className='bg-grayscale-700'>Loading...</div>
    : undefined
  }
  fixedHeaderContent={() => ({
    <tr>
      <th className='w-[150px] bg-grayscale-700 text-left'>Id</th>
      <th className='w-[150px] bg-grayscale-700 text-left'>Name</th>
    </tr>
  })}
  itemContent={(_, user) => <UserCard user={user} />}
  ref={virtuosoRef}
/>

Si ahora guardamos los cambios y volvemos al navegador podemos ver que en el momento en el que hacemos scroll y se alcanza el número de usuarios que tenemos paginados se muestra en la parte inferior de la tabla el mensaje loading indicando de esta manera que se están pidiendo nuevos datos con los que completar la información de la tabla tal y como esperábamos:

El código completo del componente App una vez incorpora la posibilidad de la obtención de los datos de forma asíncrona es el siguiente:

import { useState } from 'react'
import { TableVirtuoso, VirtuosoHandle } from `react-virtuoso`

import { UserCard } from './components/UserCard'
import { createUsers } from './user'

export const App = () => {
  const [users, setUsers] = useState(() => createUsers(0, 20))
  const [isLoading, setIsLoading] = useState(false)
  const virtuosoRef = useRef<VirtuosoHandle>(null)

  const fetchNextPage = async () => {
    const newUsers = createUsers(users.length, users.length + 20)

    setIsLoading(true)
    await new Promise(resolve => setTimeout(resolve, 1_000))
    setIsLoading(false)

    setUsers([...users, ...newUsers])
  }

  return (
    <div>
      <button
        className="mb-4"
        onClick={() => {
          virtuosoRef.current?.scrollToIndex({
            align: 'center',
            behavior: 'smooth',
            index: Math.random() * users.length
          })
        }}
      >
        Scroll
      </button>
      <TableVirtuoso
        className="!h-[200px]"
        data={users}
        endReached={fetchNextPage}
        fixedFooterContent={ isLoading
          ? () => <div className='bg-grayscale-700'>Loading...</div>
          : undefined
        }
        fixedHeaderContent={() => ({
          <tr>
            <th className='w-[150px] bg-grayscale-700 text-left'>Id</th>
            <th className='w-[150px] bg-grayscale-700 text-left'>Name</th>
          </tr>
        })}
        itemContent={(_, user) => <UserCard user={user} />}
        ref={virtuosoRef}
      />
    </div>
  )
}

Single Responsability Principle (SRP)

DevJoseManuel — Thu, 28 Mar 2024 13:33:38 +0000

Este principio se corresponde con la S de SOLID.

En este artículo vamos a centrarnos en ver cómo lo podemos aplicar a la hora de construir nuestros componentes de React permitiéndonos pasar los denominados "supercomponentes" (componentes que hacen muchas cosas) a una serie de componentes mucho más pequeños que serán mucho más mantenibles y reutilizables.

¿Qué es lo que dice el SPR?

Pues que un componente de software ha de tener una y solamente una responsabilidad o, dicho de otra manera, un componente solamente deberá hacer una cosa y solamente una.

¿Qué beneficios nos va a reportar?

Reducir la complejidad de nuestras aplicaciones puesto que estas están formadas por componentes pequeños esto se traducirá en que serán mucho más sencillos de entender y facilitará nuestro trabajo con ellos.
Estaremos apostando por la reutilización de los componentes puesto que al estar todos ellos enfocados a la realización de una tarea concreta será mucho más sencillo que los volvamos a elegir para realizar la misma tarea en diferentes partes de la aplicación e incluso en aplicaciones diferentes.
Facilitaremos el testing ya que al tratarse de componentes pequeños con funcionalidades bien definidas se traducirá en que el número de casos a testear será menor.
Mejorará el mantenimiento puesto que en el momento en el que aparezca un bug será mucho más fácil aislarlo en el componente en el que se está produciendo o al menos será mucho más sencillo acotar el conjunto de componentes donde se produce.

Ejemplo

Vamos a mostrar un componente que viola el SRP con el fin de irlo refactorizando hasta lograr que sí que lo cumpla. El componente en cuestión es ProductsPage que se encarga de renderiza la página en la que se listan todos los productos de una aplicación.

import { useQuery } from '@tanstack/react-query'
import { Product } from './types/product'

export default function ProductsPage() {
  const {
    data: products,
    isFetching,
    error
  } = useQuery({
    queryKey: ['products'],
    queryFn: async () => {
      const responde = await fetch('https://fakestoreapi.com/products')
      const data = await response.json()
      returns data as Product[]
    }
  })

  return (
    <div>
      <h1>Products Page</h1>
      { isFetching && <p>Loading...</p> }
      { error && <p>Something went wrong</p> }
      { products && && (
        <div>
          { products.map(product => (
              <div key={product.id}>
                <h2>{product.name}</h2>
                <p>{product.price}</p>
                <div>
                  <h3>Seller</h3>
                  <p>{product.seller.name}</p>
                </div>
              </div>
          ))}
        </div>
      )}
    </div>
  )
}

Este componente está violando el SRP puesto que está haciendo muchas cosas:

hace una llamada a una API para obtener la lista de todos los productos que se han de renderizar en la página haciendo uso del hook useQuery.
en el código JSX el componente decide qué es lo que se ha de renderizar en función del estado de la query anterior definiendo el código JSX que se encargará de renderizar en cada uno de los casos.

Obtención de la información de la API

Centrándonos en el código que va a permitir obtener la información de la API aquí tenemos que entender que no es responsabilidad de ProductsPage saber cómo obtener todos los productos sino que simplemente querrá consumir esta información sin que le importe si esta información se obtiene con react-query o utilizando cualquier otra librería.

Así para lograr que ProductsPage siga el SRP lo que vamos a hacer es definir un custom hook que se encargue de realizar el proceso de obtención de la información de los productos y luego pasar a utilizarlo en el componente.

import { useQuery } from '@tanstack/react-query'
import { Product } from '../types/product'

export const useFetchProducts = () => {
  return useQuery({
    queryKey: ['products'],
    queryFn: async () => {
      const responde = await fetch('https://fakestoreapi.com/products')
      const data = await response.json()
      returns data as Product[]
    }
  })
}

Este hook retorna el resultado la invocación de useQuery de tal manera que pueda ser consumido donde se necesite dentro de la aplicación.

Pero... un momento ¿este custom hook no está haciendo a su vez dos cosas? Si es así no estará siguiendo el SRP... y así es puesto que por una parte está definiendo la clave con la que se almacenará la query gracias a react-query pero es que además se define la función gracias a la cual se obtendrán los datos. Esto quiere decir que tendremos que refactorizarlo:

import { useQuery } from '@tanstack/react-query'
import { Product } from '../types/product'

const fetchProducts = async (): Promise<Product[]> => {
  const responde = await fetch('https://fakestoreapi.com/products')
  const data = await response.json()
  returns data as Product[]
}

export const useFetchProducts = () => {
  return useQuery({
    queryKey: ['products'],
    queryFn: fetchProducts
  })
}

Nota: se escribe la función fetchProducts dentro del mismo archivo que tiene el custom hook pero en un aplicación real no debería ser así ya que deberíamos situarlo dentro de una carpeta api o similar.

Ahora ya podemos pasar a utilizar este custom hook en el código de ProductsPage garantizando que el proceso de obtención de la información sigue el SRP.

import { useFetchProducts } from './hooks/useFetchProducts'

export default function ProductPage() {
  const { data: products, isFetching, error } = useFetchProducts()

  return (
    <div>
      <h1>Products Page</h1>
      { isFetching && <p>Loading...</p> }
      { error && <p>Something went wrong</p> }
      { products && && (
        <div>
          { products.map(product => (
              <div key={product.id}>
                <h2>{product.name}</h2>
                <p>{product.price}</p>
                <div>
                  <h3>Seller</h3>
                  <p>{product.seller.name}</p>
                </div>
              </div>
          ))}
        </div>
      )}
    </div>
  )
}

Refactorizar el JSX

En lo primero que tenemos que pensar cuando estamos mirando el código JSX es que el componente ProductPage está renderizando el mensaje mientras se están obteniendo los datos de la API (cuando isLoading es true), cuando se produce un error o bien cuando se tienen los datos de los productos. Esto en principio es así puesto que es el componente quien tiene que decidir qué se ha de renderizar en cada caso pero no es su responsabilidad determinar qué se ha de renderizar en cada caso.

Así en caso del estado isLoading vamos a tener que crear un nuevo componente para mostrar el mensaje cuando se está obteniendo la información de la API.

export default function LoadingDisplay() {
  return <p>Loading...</p>
}

Y siguiendo esta misma filosofía vamos a crear el componente que se encargará de mostrar el mensaje de error cuando sea necesario:

export default function ErrorDisplay() {
  return <p>Something went wrong...</p>
}

Ahora ya podemos utilizar estos dos nuevos componentes dentro de ProductsPage delegando la responsabilidad de mostrar esta información a los nuevos componentes:

import ErrorDisplay from './components/ErrorDisplay'
import LoadingDisplay from './components/LoadingDisplay'
import { useFetchProducts } from './hooks/useFetchProducts'

export default function ProductPage() {
  const { data: products, isFetching, error } = useFetchProducts()

  return (
    <div>
      <h1>Products Page</h1>
      { isFetching && <LoadingDisplay /> }
      { error && <ErrorDisplay /> }
      { products && && (
        <div>
          { products.map(product => (
              <div key={product.id}>
                <h2>{product.name}</h2>
                <p>{product.price}</p>
                <div>
                  <h3>Seller</h3>
                  <p>{product.seller.name}</p>
                </div>
              </div>
          ))}
        </div>
      )}
    </div>
  )
}

Con esta aproximación la ventaja que tenemos es que ahora tenemos dos nuevos componentes que se encargarán de los mensajes de carga de la información y de mostrar los mensajes de error que seguramente vayamos a utilizar más de una vez en toda nuestra aplicación. En este ejemplo estamos tratando de mantener las cosas lo más simples posibles pero en una aplicación real lo normal es que a tranto los mensajes de carga como de error estén mucho más elaborados que lo que acabamos de describir.

Vamos a centrarnos ahora con la parte de los productos donde tenemos que pensar en que el componente ProductsPage no tiene la responsabilidad de saber cómo se han de renderizar múltiples productos en la UI. El componente sí que tiene que saber que se han de renderizar los productos pero se ha de delegar esta funcionalidad a otro componente que se encargue del renderizado.

Por lo tanto vamos a crear el componente ProductList cuyo código sería algo como lo siguiente:

import { Product } from '../types/product'

type ProductListProps = {
  products: Product[]
}

export default function ProductList({ products }: ProductListProps) {
  return (
    <div>
      { products.map(product => (
          <div key={product.id}>
            <h2>{product.name}</h2>
            <p>{product.price}</p>
            <div>
              <h3>Seller</h3>
              <p>{product.seller.name}</p>
            </div>
          </div>
      ))}
    </div>
  )
}

y ya podemos pasar a utilizarlo en el componente ProductList denjándonos el código como sigue:

import ProductList from './components/ProductList'
import ErrorDisplay from './components/ErrorDisplay'
import LoadingDisplay from './components/LoadingDisplay'
import { useFetchProducts } from './hooks/useFetchProducts'

export default function ProductPage() {
  const { data: products, isFetching, error } = useFetchProducts()

  return (
    <div>
      <h1>Products Page</h1>
      { isFetching && <LoadingDisplay /> }
      { error && <ErrorDisplay /> }
      { products && && <ProductList products={products} /> }
    </div>
  )
}

Como podemos ver ahora mismo el componente ProductPage nos ha quedado bastante pequeño y con un código que es simple de mantener y que se entiende muy fácilmente.

Pero no podemos quedarnos aquí puesto que el componente ProductList que hemos definido anteriormente no está siguiendo el SRP puesto que sí que está renderizando la lista de todos los componentes pero además está asumiendo la responsabilidad de renderizar la UI para cada uno de los productos individuales por lo que deberemos crear un neuvo componente que sea el encargado de renderizar la información que se corresponde a cada uno de los elementos individuales.

El aspecto de este componente, al que llamaremos ProductCard, será el que se puede ver en el siguiente código, componente que sí que sigue el SRP puesto que únicamente hace una cosa (una única responsabilidad) ya que toma como prop un producto y renderiza la UI para dicho producto:

type ProductCardProps = {
  product: Product
}

export default function ProductCard({ product }: ProductCardProps ) {
  return (
    <div key={product.id}>
      <h2>{product.name}</h2>
      <p>{product.price}</p>
      <div>
        <h3>Seller</h3>
        <p>{product.seller.name}</p>
      </div>
    </div>
  )
}

Podríamos seguir aplicando el SRP dentro del componente ProductCard puesto que el vendedor es a su vez una persona que no tiene que ver son el producto en sí mismo y así deberíamos hacerlo (por ejemplo, definiendo el componente UserCard donde se renderizaría el avatar del usuario, nombre, etc.). Pero con el fin de mantener las cosas simples de cara a la explicación vamos a suponer que el vendedor forma parte del producto.

Ahora tendremos que ir al componente ProductList y simplemente pasaremos a utilizar ProductCard como sigue logrando también que siga el SRP puesto que su responsabilidad es renderizar una lista de productos delegando la responsabilidad de renderizar la información de cada uno de los productos a otro componente.

import { Product } from '../types/product'

type ProductListProps = {
  products: Product[]
}

export default function ProductList({ products }: ProductListProps) {
  return (
    <div className='flex gap-4'>
      { products.map(product => <ProductCard key={product.id} product={product} /> }
    </div>
  )
}

Nota: hemos añadido los estilos de Tailwind necesarios para renderizar la lista de los productos puesto que es responsabilida del componente ProductList definir cómo se renderiza esa lista de los componentes.

Resúmen

Para saber si un componente está violando o no el SRP deberemos hacernos la siguiente pregunta ¿cuál es la responsabilidad única de este componente? El problema aquí es que la respuesta no tiene por qué ser obvia y muchas veces queda a criterio del desarrollador.

En el ejemplo de ProductsPage podemos ver de forma intuitiva que se está violando el SPR puesto que no solamente estaba obteniendo la información de los productos sino que además pintaba la lista de todos ellos además de controlar lo que se renderizaría en los estados para obtener la información.

El SRP nos viene a decir que deberemos crear nuestros componente pensando en que únicamente han de hacer una cosa y cuando necesitemos añadir nuevas funcionalidades a los mismos la estrategia consistirá en crear un nuevo componente que la ofrezca para posteriormente vincularlos logrando el objetivo que se está persiguiendo.

TypeScript - #02 - Readonly

DevJoseManuel — Sat, 06 Aug 2022 06:16:00 +0000

Other languages: Spanish
Link to the challenge: Readonly

In this challenge what we will pursue is to build the Readonly<T> utility offered by TypeScript but without using it, which implies that what we are going to build is a type that will return all the attributes of type T that have been set as readonly, which means that these attributes cannot be reassigned (it will not be possible to change their value).

As an example:

interface Todo {
    title: "string"
    description: "string"
}

const todo: MyReadonly<Todo> = {
    title: "'Hey',"
    description: 'foobar'
}

todo.title = 'Hello' // Error: cannot reassign a readonly property.
todo.description = 'barFoo' // Error: cannot reassign a readonly property.

Solution

type MyReadonly<T> = {
    readonly [K in keyof T]: T[K]
}

// If we want to remove de readonly we can do
type MyReadonly<T> = {
    -readonly [K in keyof T]: T[K]
}

Explanation

The first thing we have to think about in order to build our solution is that the readonly visibility modifier assignment should only be applied on those first level attributes of the data type on which our utility will work. What does this mean? Well, if we extend the All interface declaration we have in the example:

interface Todo {
    title: string
    description: string
    completed: boolean
    meta: {
        author: string
    }
}

the readonly modifier should only be applied to the first level attributes (title, description, completed and meta) but not to the second level and later ones (which means that the author attribute of the meta object does not have to have it). That is, what we have to obtain is a data type like the following:

interface Todo {
    readonly title: string
    readonly description: string
    readonly completed: boolean
    readonly meta: {
        author: string
    }
}

To obtain the solution the first thing we have to think is that somehow what we are being asked is that our utility creates a new object from a starting one, so whenever we face a challenge of this type the best idea to face it is to think of a mapping of the properties of the starting object in the properties of the object with the solution.

So as an initial step we establish that the result of applying our type is going to be a new object:

type MyReadonly<T> = {}

And how can we go through all the properties that are collected in the T object? Well, first of all we will have to obtain them, which we achieve thanks to the use of the keyof operator on the object T. In the example we are working with we will have something like the following:

keyof Todo --> 'title' | 'description' | 'completed' | 'meta'

and now we are going to have to traverse them as if we were traversing a JavaScript array for which we will rely on the in operator as follows:

K in keyof Todo --> ['title', 'description', 'completed', 'meta']

Now that we know how to obtain all the attributes of the object T the next thing we have to do is to create a mapped type, that is to say, a type that is obtained by mapping the data of another type. In our case what we want is to create a new object where each of its attributes is the same as the starting T object so we would write something like the following:

type MyReadonly<T> = {
    [K in keyof T]: ...
}

And what value will we assign to each of these attributes? Well, in principle the same as the original object, which we obtain by accessing directly to that attribute in T:

type MyReadonly<T> = {
    [K in keyof T]: T[K]
}

What have we achieved so far? Well, the truth is that very little since the only thing that the previous declaration is doing is to return us exactly the same type T with which we are working.

We will have to add the modifier readonly to be able to achieve the objective that we are pursuing for which we will have several possibilities. The first of them would consist of adding it to the part that collects the value of the new data type:

type MyReadonly<T> = {
    [K in keyof T]: readonly T[K]
}

but here the problem lies in that TypeScript will give us an error because readonly is a modifier that can only be applied on arrays or tuples and we do not have the certainty that T[K] is going to be an array or tuple.

The other possibility we have is to add it before the declaration of each of the attributes of our new object:

type MyReadonly<T> = {
    readonly [K in keyof T]: T[K]
}

And with this we would achieve the result we are looking for.

Remove the readonly attribute

Now that we know how to add the readonly attribute, just mention that TypeScript offers us the possibility of using the - operator in front of this modify and what it will do is to remove it from all those attributes that may have it in the T object.

type MyReadonly<T> = {
    -readonly [K in keyof T]: T[K]
}

An additional level of depth

We could go one level deeper in the declaration of the attributes on which the readonly modifier has to be removed, being this an interesting aspect to which it is worth dedicating a few moments.

The first step to achieve this is to use a conditional type to determine whether the value assigned to the attribute we are working with is an object or not:

type MyReadonly<T> = {
    readonly [K in keyof T]: T[K] extends object ? ... : ...
}

And here is where it comes into play to know that TypeScript will allow us to make recursive to the data types that we are defining in an analogous way to how recursive function calls are made in JavaScript. What does this mean? Well, in our case, if the condition is fulfilled, what we will do is to apply MyReadonly again, but in this case passing the object that is associated to the K attribute of the starting T object:

type MyReadonly<T> = {
    readonly [K in keyof T]: T[K] extends object
        ? MyReadonly<T[K]>
        : ...
}

and in the case that the condition is not fulfilled (that is to say, that the value that has assigned the attribute K is not an object) what we will return will be this value:

type MyReadonly<T> = {
    readonly [K in keyof T]: T[K] extends object
        ? MyReadonly<T[K]>
        : T[K]
}

Links of interest

TypeScript - #02 - Readonly

DevJoseManuel — Sat, 06 Aug 2022 06:15:00 +0000

En otros idiomas: Inglés
Enlace al desafío: Readonly

En este desafío lo que perseguiremos es construir es la utilidad Readonly<T> que nos ofrece TypeScript pero sin utilizarla lo que implica que lo que vamos a construir es un tipo que nos retornará todos los atributos del tipo T que han sido establecidos como readonly lo que viene a indicar que estos atributos no van a poder ser reasignados (no se podrá cambiar su valor).

A modo de ejemplo:

interface Todo {
    title: "string"
    description: "string"
}

const todo: MyReadonly<Todo> = {
    title: "'Hey',"
    description: 'foobar'
}

todo.title = 'Hello' // Error: cannot reassign a readonly property.
todo.description = 'barFoo' // Error: cannot reassign a readonly property.

Solución

type MyReadonly<T> = {
    readonly [K in keyof T]: T[K]
}

// If we want to remove de readonly we can do
type MyReadonly<T> = {
    -readonly [K in keyof T]: T[K]
}

Explicación

Lo primero que tenemos que pensar para construir nuestra solución es que la asignación de modificador de visibilidad readonly solamente debería aplicarse sobre aquellos atributos de primer nivel del tipo de datos sobre el que trabajará nuestra utilidad. ¿Qué quiere esto decir? Pues que si ampliamos la declaración de la interfaz Todo que tenemos en el ejemplo:

interface Todo {
    title: string
    description: string
    completed: boolean
    meta: {
        author: string
    }
}

el modificador readonly únicamente deberá aplicarse a los atributos de primer nivel (title, description, completed y meta) pero no a los de segundo nivel y posteriores (lo que viene a decir que el atributo author del objeto meta no tienen que tenerlo). Es decir, que lo que tenemos que obtener es un tipo de datos como el siguiente:

interface Todo {
    readonly title: string
    readonly description: string
    readonly completed: boolean
    readonly meta: {
        author: string
    }
}

Para obtener la solución lo primero que tenemos que pensar es que de alguna manera lo que se nos está pidiendo es que nuestra utilidad lo que haga es crear un nuevo objeto a partir de uno de partida por lo que siempre que nos enfrentemos a un desafío de este tipo la mejor idea de afrontarlo es pensar en una mapeo de las propiedades del objeto de partida en las propiedades del objeto con la solución.

Así pues como paso inicial establecemos que el resultado de aplicar nuestro tipo va a ser un nuevo objeto:

type MyReadonly<T> = {}

¿Y cómo podemos recorrer todas las propiedades que están recogidas en el objeto T? Pues en primer lugar tendremos que obtenerlas cosa que logramos gracias al uso del operador keyof sobre el objeto T. En el ejemplo con el que estamos trabajando tendremos algo como lo siguiente:

keyof Todo --> 'title' | 'description' | 'completed' | 'meta'

y ahora vamos a tener que recorrerlas como si estuviésemos recorriendo un array de JavaScript para lo cual nos apoyaremos en el operador in como sigue:

K in keyof Todo --> ['title', 'description', 'completed', 'meta']

Ahora que ya sabemos cómo obtener todos los atributos del objeto T la siguiente que tenemos que hacer es crear un mapped type es decir, tipo que se obtiene mapeando los datos de otro tipo. En nuestro caso lo que nosotros queremos es recorrer crear un nuevo objeto donde cada uno de sus atributos sea el mismo que el objeto T de partida por lo que escribiríamos algo como lo siguiente:

type MyReadonly<T> = {
    [K in keyof T]: ...
}

¿Y qué valor le asignaremos a cada uno de estos atributos? Pues en principio el mismo que tiene el objeto original cosa que obtenemos accediendo directamente a dicho atributo en T:

type MyReadonly<T> = {
    [K in keyof T]: T[K]
}

¿Qué hemos logrado hasta aquí? Pues la verdad es que muy poco ya que lo único que está haciendo la declaración anterior es devolvernos exactamente el mismo tipo T con el que estamos trabajando.

Nos quedará añadir el modificador readonly para poder lograr el objetivo que estamos persiguiendo para lo cual tendremos varias posibilidades. La primera de ellas consistiría en añadirlo a la parte que recoge el valor del nuevo tipo de datos:

type MyReadonly<T> = {
    [K in keyof T]: readonly T[K]
}

pero aquí el problema radica en que TypeScript nos dará un error porque readonly es un modificador que solamente se puede aplicar sobre arrays o tuplas y nosotros no tenemos la certeza de que T[K] vaya a ser un array o tupla.

La otra posibilidad que tenemos es añadirlo antes de la declaración de cada uno de los atributos de nuestro nuevo objeto:

type MyReadonly<T> = {
    readonly [K in keyof T]: T[K]
}

Y con esto lograríamos el resultado que estamos buscando.

Eliminar el atributo readonly

Ahora que sabemos cómo añadir el atributo readonly simplemente mencionar que TypeScript nos ofrece la posibilidad de utilizar el operador - delante de este modificar y lo que hará será quitarlo de todos aquellos atributos que lo puedan tener en el objeto T.

type MyReadonly<T> = {
    -readonly [K in keyof T]: T[K]
}

Un nivel de profundidad adicional

Podríamos irnos un nivel de profundidad en la declaración de los atributos sobre los que hay que eliminar el modificador readonly siendo este un aspecto interesante al que merece la pena dedicarle unos instantes.

El primero paso para lograrlo consistirá en utilizar un tipo condicional para determinar si el valor que tiene asignado el atributo con el que estamos trabajando es un objeto o no:

type MyReadonly<T> = {
    readonly [K in keyof T]: T[K] extends object ? ... : ...
}

Y aquí es donde entra en juego el conocer que TypeScript nos va a permitir hacer recursivas a los tipos de datos que estamos definiendo de forma análoga a como se hacen llamadas a funciones recursivas en JavaScript. ¿Qué quiere esto decir? Pues que en nuestro caso en el caso de que se cumpla la condición lo que haremos será volver a aplicar MyReadonly pero en este caso pasándole el objeto que está asociado al atributo K del objeto T de partida:

type MyReadonly<T> = {
    readonly [K in keyof T]: T[K] extends object
        ? MyReadonly<T[K]>
        : ...
}

y en el caso de que no se cumpla la condición (es decir, que el valor que tienen asignado el atributo K no sea un objeto) lo que retornaremos será dicho valor:

type MyReadonly<T> = {
    readonly [K in keyof T]: T[K] extends object
        ? MyReadonly<T[K]>
        : T[K]
}

Enlaces de interés

TypeScript - #01 - Pick

DevJoseManuel — Sat, 30 Jul 2022 07:04:00 +0000

Other languages: Spanish
Link to the challenge: Pick

In this challenge what we will pursue is to construct the Pick<T, K> type without making use of it. We will have to construct a data type that will allow us to extract the set of K properties of a T type. For example:

interface Todo {
    title: "string"
    description: "string"
    completed: boolean
}

type TodoPreview = MyPick<Todo, 'title' | 'completed'>

const todo: TodoPreview = {
    title: "'Clean room',"
    completed: false
}

Solution

MyPick<T, K extends keyof T> = {
    [P in K]: T[P]
}

Explanation

We will start from the basic definition of the data type we want to construct where we will set the parameters we expect it to receive and we will also assume that it will initially return any:

type MyPick<T, K> = any

But before we continue, let's stop for a moment to understand how MyPick should work. To do so, we are going to rely on the declaration of the All interface of the challenge definition by presenting three scenarios:

MyPick<Todo, 'title'>
MyPick<Todo, 'title' | 'completed'>
MyPick<Todo, 'title' | 'completed' | 'invalid'>

How should MyPick behave in each of the three scenarios above?

In the first case MyPick should not give an error since title is one of the attributes that are collected inside the All interface.
In the second case we should not have an error either since the union type that is formed by title and completed corresponds to two of the attributes that are defined in MyPick.
The third case is different since we are again in front of a union type but in this case the particularity is that one of the values that form it does not correspond to one of the attributes of the All interface so MyPick should inform us about it with an error message.

With this in mind it seems that the key to solving our problem is to somehow restrict the set of values that we can write to the second parameter of MyPick<T, K> or, in other words, to define K in such a way that it can only accept values that correspond to the attributes of T.

`keyof`

Now how can we say in TypeScript that we want to extract the set of attributes that are associated with a type? The answer is thanks to the use of the keyof operator.

To understand it better with our example, if we apply this operator to the interface All what we are going to obtain is a union type formed by the name of all the attributes that are defined inside the interface.

keyof Todo ---> 'title' | 'description' | 'completed'

`extends`

Now that we have the data type formed by all the attributes of the interface we have to restrict in some way that only one of them can be chosen and this is where the conditional types come into play.

Thinking in terms of set theory:

What do we want to prove? That the set formed by the data types that is associated to all the attributes we want to extract is a subset of the set formed by the type attributes we are working with.
Does TypeScript offer us a mechanism to be able to perform this check? Yes, and it is the use of the conditional types or, in our case, of the extends operator.

As we can guess extends is an operator that will allow us to perform checks in a similar way as we do JavaScript:

A extends B ---> true whenever A is a subset of the elements of B.
A extends B ---> false otherwise.

Let's translate this idea into the scenarios we have shown above:

B = keyof Todo ---> 'title' | 'description' | 'completed'

'title' extends B --> true 
'title' | 'completed' extends B --> true
'title' | 'completed' | 'invalid' extends B --> false

Putting all the pieces together

Now we only have to join the two previous pieces to achieve our goal by establishing that the set of values that can be set in the K parameter must belong to the set of attributes that is collected in the T type. This leaves us with the following:

MyPick<T, K extends keyof T> = any

Returning the value

In the previous statement we are seeing that the result that is being returned is any and this is not what is intended in the challenge since what we want is to return an object that contains only the attributes of T that we have specified in the K parameter.

The way to achieve this is by using what is known as a Mapped Type which is nothing more than constructing a new type from the definition of another.

Let's start by defining the simplest mapped type that we can think of to achieve our goal, which would be one that always returns a type without attributes as a result:

MyPick<T, K extends keyof T> = {}

How do we now define the attributes of this object? Well, this is where we have to understand that both T and K are two types that will be available during the declaration of the type we are constructing (to some extent, if we think in terms of JavaScript, it is as if both types were linked to the scope of the declaration of our new type) and that, in addition, for the definition of the attributes we will be interested in the set that is contained in K.

Is there a possibility to traverse all the values collected in K in TypeScript? The answer is yes, and it is thanks to the use of the in operator. Thinking in terms of arrays we could make a mental scheme like the following:

K ---> 'title' | 'description' | 'completed'
P in K ---> ['title', 'description', 'completed']

where P is a type that will pass the title, description and completed values respectively while traversing the array.

And can we define an attribute within the mapped type from each of these array elements? The answer again is yes, using the notation between [] where

MyPick<T, K extends keyof T> = {
    [P in K]: ...
}

This, which is complex to explain in words, is best seen in the example we are following:

interface Todo {
    title: string
    description: string
    completed: boolean
}

MyPick<Todo, 'title'> ---> { title: ... }
MyPick<Todo, 'title' | 'description'> ---> { title: ..., description: ... }
MyPick<Todo, 'title' | 'description' | 'completed'> ---> { title: ..., description: ..., completed: ... }

Now we only have to assign the data type that is associated to each of the attributes that we are extracting and this is achieved in a very simple way just using the operator [] on the data type indicating which is the element from which we want to extract the information of the type (analogously to how we can do it in TypeScript to access each of the elements of an object).

But how do we know which is the concrete attribute? Well, we have to remember again that all the generic types that we use during the declaration of our type can be used in the rest of its definition.

In our case, as we have declared something like [P in K] to go through all the attributes that are collected within the set of keys to extract K and as we also have the certainty that these keys will belong to the type on which we are working T we can simply use T[P] to obtain the type associated with that attribute:

MyPick<T, K extends keyof T> = {
    [P in K]: T[P]
}

If we go back to our example we would get something like the following:

interface Todo {
    title: string
    description: string
    completed: boolean
}

MyPick<Todo, 'title'> 
    ---> { title: string }
MyPick<Todo, 'title' | 'description'> 
    ---> { title: string, description: string }
MyPick<Todo, 'title' | 'description' | 'completed'> 
    ---> { title: string, description: string, completed: boolean }

Links of interest

TypeScript - #01 - Pick

DevJoseManuel — Sat, 30 Jul 2022 06:46:00 +0000

En otros idiomas: Inglés
Enlace al desafío: Pick

En este desafío lo que perseguiremos es construir el tipo Pick<T, K> sin hacer uso del mismo. Deberemos construir un tipo de datos que nos permitirá extraer el conjunto de propiedades K de un tipo T. Por ejemplo:

interface Todo {
    title: "string"
    description: "string"
    completed: boolean
}

type TodoPreview = MyPick<Todo, 'title' | 'completed'>

const todo: TodoPreview = {
    title: "'Clean room',"
    completed: false
}

Solución

MyPick<T, K extends keyof T> = {
    [P in K]: T[P]
}

Explicación

Vamos a partir de la definición básica del tipo de datos que queremos construir donde estableceremos los parámetros que esperamos que reciba y supondremos además que inicialmente retornará any:

type MyPick<T, K> = any

Pero antes de continuar vamos a detenernos unos instantes para entender bien cómo ha de funcionar MyPick. Para ello nos vamos a apoyar en la declaración de la interfaz Todo de la definición del challenge presentando tres escenarios:

MyPick<Todo, 'title'>
MyPick<Todo, 'title' | 'completed'>
MyPick<Todo, 'title' | 'completed' | 'invalid'>

¿Cómo ha de comportarse MyPick en cada una de los tres escenarios anteriores?

En el primero de los casos MyPick no debería dar un error puesto que title es uno de los atributos que están recogidos dentro de la interfaz Todo.
En el segundo caso tampoco deberíamos tener un error puesto que el union type que está formado por title y completed se corresponde con dos de los atributos que están definidos en MyPick.
El tercer caso es diferente puesto que estamos nuevamente frente a un union type pero en este caso la particularidad es que uno de los valores que lo forman no se corresponde con uno de los atributos de la interfaz Todo por lo que MyPick debería informarnos de ello con un mensaje de error.

Con esto en mente parece que la clave para poder resolver nuestro problema está en restringir de alguna manera el conjunto de los valores que podemos escribir en el segundo de los parámetros de MyPick<T, K> o, dicho de otra manera, definir K de tal manera que solamente pueda aceptar valores que se corresponden con los atributos de T.

`keyof`

Ahora bien ¿cómo podemos decir en TypeScript que queremos extraer el conjunto de los atributos que están asociados con un tipo? La respuesta es gracias al uso del operador keyof.

Para entenderlo mejor con nuestro ejemplo, si aplicamos este operador a la interfaz Todo lo que vamos a obtener es un union type formado por el nombre de todos los atributos que están definidos dentro de la interfaz.

keyof Todo ---> 'title' | 'description' | 'completed'

`extends`

Ahora que ya tenemos el tipo de datos formado por todos los atributos de la interfaz tenemos que restringir de alguna manera que solamente se puedan elegir entre uno de ellos y aquí es donde entran en juego los conditional types.

Pensando en términos de teoría de conjuntos:

¿Qué es lo que queremos probar? Que el conjunto formado por los tipos de datos que está asociados a todos los atributos que queremos extraer es un subconjunto del conjunto formado por los atributos de tipo con el que estamos trabajando.
¿TypeScript nos ofrece una mecanismo para poder realizar esta comprobación? Sí, y es el uso de los conditional types o, en nuestro caso, del operador extends.

Como podemos intuir extends es un operador que nos va a permitir realizar comprobaciones de forma similar a como las realizamos JavaScript:

A extends B ---> true siempre que A sea un subconjunto de los elementos de B.
A extends B ---> false en caso contrario.

Plasmemos esta idea en los escenarios que hemos mostrado anteriormente:

B = keyof Todo ---> 'title' | 'description' | 'completed'

'title' extends B --> true 
'title' | 'completed' extends B --> true
'title' | 'completed' | 'invalid' extends B --> false

Uniendo todas las piezas

Ya solamente nos quedan unir las dos piezas anteriores para lograr nuestro objetivo estableciendo que el conjunto de los valores que se pueden establecer en el parámetro K ha de pertenecer al conjunto de los atributos que está recogidos en el tipo T. Esto nos deja con lo siguiente:

MyPick<T, K extends keyof T> = any

Retornando el valor

En la declaración anterior estamos viendo que el resultado que se está devolviendo es any y esto no es lo que se persigue en el desafío puesto que lo que queremos es retornar un objeto que contenga únicamente los atributos de T que hemos especificado en el parámetro K.

La forma de lograrlo es utilizando lo que se conoce como un Mapped Type que no es más que construcción de un nuevo tipo a partir de la definición de otro.

Vamos a comenzar definiendo el mapped type más sencillo que se nos puede ocurrir para lograr nuestro objetivo que sería aquel que siempre devolviese un tipo sin atributos como resultado:

MyPick<T, K extends keyof T> = {}

¿Cómo definimos ahora los atributos de este objeto? Pues aquí es donde tenemos que entender que tanto T como K son dos tipos que estarán disponibles durante la declaración del tipo que estamos construyendo (en cierta medida, si pensamos en términos de JavaScript, es como si ambos tipos estuviesen vinculados al scope de la declaración de nuestro nuevo tipo) y que, además, para la definición de los atributos nos interesará el conjunto que está recogido en K.

¿Existe una posibilidad de recorrer todos los valores recogidos en K en TypeScript? La respuesta es que sí y es gracias al uso del operador in. Pensando en términos de arrays podíamos hacernos un esquema mental como el siguiente:

K ---> 'title' | 'description' | 'completed'
P in K ---> ['title', 'description', 'completed']

donde P es un tipo que pasará a tener los valores title, description y completed respectivamente mientras se está recorriendo el array.

¿Y podemos definir un atributo dentro del mapped type a partir de cada uno de estos elementos del array? La respuesta nuevamente es que sí utilizando para ello la notación entre [] donde

MyPick<T, K extends keyof T> = {
    [P in K]: ...
}

Esto que de palabra es complejo de explicar se ve mejor en el ejemplo que estamos siguiendo:

interface Todo {
    title: string
    description: string
    completed: boolean
}

MyPick<Todo, 'title'> ---> { title: ... }
MyPick<Todo, 'title' | 'description'> ---> { title: ..., description: ... }
MyPick<Todo, 'title' | 'description' | 'completed'> ---> { title: ..., description: ..., completed: ... }

Ya solamente nos queda por asignar el tipo de datos que está asociado a cada uno de los atributos que estamos extrayendo y esto se consigue de forma muy sencilla sin más que utilizar el operador [] sobre el tipo de datos indicando cuál es el elemento del que queremos extraer la información del tipo (de forma análoga a cómo podemos hacerlo en TypeScript para acceder a cada uno de los elementos de un objeto).

Pero ¿cómo sabemos cuál es el atributo concreto? Pues así tenemos que volver a recordar que todos los tipos genéricos que vayamos utilizando durante la declaración de nuestro tipo pueden ser utilizados en el resto de su definición.

En nuestro caso, como hemos declarado algo como [P in K] para recorrer todos los atributos que están recogidos dentro del conjunto de las claves a extraer K y como además tenemos la certeza de que estas claves pertenecerán al tipo sobre el que estamos trabajando T ya simplemente podemos utilizar T[P] para obtener el tipo asociado a dicho atributo:

MyPick<T, K extends keyof T> = {
    [P in K]: T[P]
}

Si volvemos a nuestro ejemplo obtendríamos algo como lo siguiente:

interface Todo {
    title: string
    description: string
    completed: boolean
}

MyPick<Todo, 'title'> 
    ---> { title: string }
MyPick<Todo, 'title' | 'description'> 
    ---> { title: string, description: string }
MyPick<Todo, 'title' | 'description' | 'completed'> 
    ---> { title: string, description: string, completed: boolean }

Enlaces de interés

JS Tip: #1 - async/await over arrays

DevJoseManuel — Tue, 03 May 2022 07:56:42 +0000

Suppose that, for whatever reason, we are traversing an array with the map() method and we have to execute an asynchronous function on each of the elements. Something like the following:

const users = ['user1', 'user2', 'user3']
const data = users.map(async (user) => await fetchApiData(user))

What we need to understand here is that the dummy function fetchApiData (which receives as parameter the name of one of a user) will be making an asynchronous call to an external API that our application works with.

What happens if we now write the content of the data variable through the console? Well, we are going to find something like the following:

const users = ['user1', 'user2', 'user3']
const data = users.map(async (user) => await fetchApiData(user))

console.log(data)
/*
[
  Promise { <pending> },
  Promise { <pending> },
  Promise { <pending> }
]
*/

That is, the execution of the code does not stop waiting for the results of the external API call and therefore the array data will be formed by as many elements as users we have declared in the array users and associated to each of the positions a JavaScript Promise object in the pending state.

Resolution of all calls in parallel.

The first option we have to solve this problem is to use the all() method of the JavaScript Promise object, which will allow all the promises it receives as parameter (this method expects to receive as parameter an array of promises to be resolved) to be executed in parallel, without depending on each other, and it does not finish its execution until all these promises have finished.

const users = ['user1', 'user2', 'user3']
const data = await Promise.all(
    users.map(async (user) => await fetchApiData(user))
)

console.log(data)
/*
[
  dataFromUser1,
  dataFromUser2,
  dataFromUser3
]
*/

When running in parallel we have to understand that the total execution time of the method will be that of the promise that consumes more resolution time, which makes it a very fast alternative when there is no dependency between promises.

Resolution of flames sequentially.

But what will happen if we have a dependency in the execution of the promises, i.e. the calls to the asynchronous function (in our example the external API will depend on the result of the previous call)? In this case we should use the structure for ... of structure as follows:

const users = ['user1', 'user2', 'user3']
const data = []

for (const user of users) {
    data.push(await fetchApiData(user))
}

console.log(data)
/*
[
  dataFromUser1,
  dataFromUser2,
  dataFromUser3
]
*/

In this case it is easy to understand that, as one call depends on the previous one, the result of the execution of all the code will be the sum of the resolution of each of the promises separately.

JS Tip: #1 - async/await sobre arrays

DevJoseManuel — Tue, 03 May 2022 07:52:50 +0000

Supongamos que, por la razón que sea, estamos recorriendo un array con el método map() y que tenemos que ejecutar una función asíncrona en cada uno de los elementos. Algo como lo siguiente:

const users = ['user1', 'user2', 'user3']
const data = users.map(async (user) => await fetchApiData(user))

lo que tenemos que entender aquí es que la función ficticia fetchApiData (la cual recibe como parámetro el nombre de uno de un usuario) estará realizando una llamada asíncrona a una API externa con la que trabaja nuestra aplicación.

¿Qué ocurre si ahora a continuación escribimos el contenido de la variable data por la consola? Pues que nos vamos a encontrar con algo como lo siguiente:

const users = ['user1', 'user2', 'user3']
const data = users.map(async (user) => await fetchApiData(user))

console.log(data)
/*
[
  Promise { <pending> },
  Promise { <pending> },
  Promise { <pending> }
]
*/

Es decir, que la ejecución del código no se para a la espera de recibir los resultados de la llamada a la API externa y por lo tanto el array data estará formado por tantos elementos como usuarios hemos declarado en el array users y asociados a cada una de las posiciones un objeto Promise de JavaScript en el estado pending.

Resolución de todas las llamadas en paralelo.

La primera de las opciones que tenemos para poder solucionar este problema pasa por utilizar el método all() del objeto Promise de JavaScript el cual va a permitir que todas las promesas que recibe como parámetro (este método espera recibir como parámetro un array de promesas que se deben resolver) pasan a ser ejecutadas en paralelo, sin depender unas de otras, y no finaliza su ejecución hasta que todas estas promesas hayan finalizado.

const users = ['user1', 'user2', 'user3']
const data = await Promise.all(
    users.map(async (user) => await fetchApiData(user))
)

console.log(data)
/*
[
  dataFromUser1,
  dataFromUser2,
  dataFromUser3
]
*/

Al ejecutarse en paralelo tenemos que entender que el tiempo de ejecución total del método será el de la promesa que consume más tiempo de resolucíón, lo cual lo hace una alternativa muy rápida cuando no hay una dependencia entre promesas.

Resolución de las llamas de forma secuencial.

Pero ¿qué ocurrirá en el caso de que tengamos una dependencia en la ejecución de las promesas, es decir, que las llamadas a la función asíncrona (en nuestro ejemplo la API externa dependerán del resultado de la llamada anterior)? Es este caso deberemos utilizar la estructura for ... of como sigue:

const users = ['user1', 'user2', 'user3']
const data = []

for (const user of users) {
    data.push(await fetchApiData(user))
}

console.log(data)
/*
[
  dataFromUser1,
  dataFromUser2,
  dataFromUser3
]
*/

En este caso es fácil entender que, como una llamada depende de la anterior, el resultado de la ejecución de todo el código será la suma de la resolución de cada una de las promesas por separado.

# CSS Tip: #1 - has()

DevJoseManuel — Sun, 10 Apr 2022 19:15:48 +0000

The CSS has() function can be used to apply a style to an element depending on whether a condition is met or not. In this small article we are going to see how we can use it in a specific case.

Suppose we are defining the styles for the label tags of our forms and what we want is to define a certain style only for all those label that are associated to an element of type checkbox. That is, we want the styles to apply to the input element of a markup like the following:

<label for='my-checkbox'>
  <input id='my-checkbox' type='checkbox' value='my-value' />
</label>

It is clear that the first thing we have to define is that our css rule has to apply to all the label tags of the form but we are going to make use of the has() function to be able to launch a kind of query or condition that has to be given in order to apply the CSS rules we want to apply to this type of label. That is to say, we would start from something like the following:

label:has() {
  /* CSS rules to be applied. */
}

We see that what we want is to invoke the has() function on the label tags and only in the case that the condition received as a parameter is met then the set of CSS rules we are going to define will be applied.

But how do we establish that the condition has to be met? Well, this is where we have to make use of the CSS selectors we know. We have to think that what we want is that the rules apply only to elements of type checkbox and how is this expressed in CSS? Well, with something like the following:

input[type="checkbox"]

Now, how should we determine that a style should be applied to the direct descendants of label tags that are of the checkbox type? Well, we would make use of the > operator (direct descendant of CSS as follows:

label > input[type="checkbox"] {
  /* CSS rules to be applied. */
}

With this we are very close to achieving the goal we are pursuing as we know that now the set of CSS rules we put between braces would apply to the checkbox element but we have to remember that the problem we are trying to solve is that we want these rules to apply to the label element. So what if we use this selector as a parameter to the has() function? That is, we write something like the following:

label:has(> input[type="checkbox"]) {
  /* CSS rules to be applied. */
}

Well, the answer is that this is the correct solution because CSS will (to simplify the explanation) look at each of the label tags and invoke the has() function on them asking something like do you have a direct descendant that is a checkbox?. If the answer is yes, then it applies the rules I'm going to give you in braces; otherwise you ignore them.

We should use the CSS has() function when we want a set of styles to be applied to a given element when it is satisfied that it contains elements of certain types.

Nota: para obtener más información acerca de cómo funciona la función has() se recomienda leer esta entrada de la MDN.

DEV Community: DevJoseManuel

Test componentes que usan Redux

Componente

Test

Problemas adicionales

Código completo

Type Guards & Type Assertions

Problema

Type Guard

Desventajas del uso de los Type Guards

Asertion Functions

Higher Order Functions

Funciones sobre arrays.

Higher Order Functions

Método filter()

Renderizado de 10.000 filas en React

Código de partida

Problema

Solución

Uso de Virtuoso

Navegar de forma aleatoria a un elemento

Uso de Virtuoso con una tabla.

Datos paginados

Datos asíncronos

Single Responsability Principle (SRP)

¿Qué es lo que dice el SPR?

¿Qué beneficios nos va a reportar?

Ejemplo

Obtención de la información de la API

Refactorizar el JSX

Resúmen

TypeScript - #02 - Readonly

Solution

Explanation

Remove the readonly attribute

An additional level of depth

Links of interest

TypeScript - #02 - Readonly

Solución

Explicación

Eliminar el atributo readonly

Un nivel de profundidad adicional

Enlaces de interés

TypeScript - #01 - Pick

Solution

Explanation

keyof

extends

Putting all the pieces together

Returning the value

Links of interest

TypeScript - #01 - Pick

Solución

Explicación

keyof

extends

Uniendo todas las piezas

Retornando el valor

Enlaces de interés

JS Tip: #1 - async/await over arrays

Resolution of all calls in parallel.

Resolution of flames sequentially.

JS Tip: #1 - async/await sobre arrays

Resolución de todas las llamadas en paralelo.

Resolución de las llamas de forma secuencial.

# CSS Tip: #1 - has()

Método `filter()`

`keyof`

`extends`

`keyof`

`extends`