Renderizado de listas reactivas con For en Solid

Contenido del curso

No sé dónde empezar

Introducción a SolidJS

Reactividad a profundidad

Renderizado en Solid

Reactividad en Listas

Componentes

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0013:02

Renderizado de listas reactivas con For en Solid

Curso de SolidJS

Clase 16 de 27

Clase 16 / 27

Comentarios (4)4 comentarios

Kevin J. Zea Alvarado

Hace 7 meses

Quedé muy sorprendido de dónde me llegué a topar con el comma operator. No recuerdo haberlo escuchado alguna vez y quedé impactado cuando el profesor habló de ello. jaja

Muchísimas gracias por tremendo aporte, profe Samuel. Por lo que he visto, es una característica muy poco usada, pero me parece bueno saber que existe. Agradezco que se haya tomado el tiempo de mencionarlo y aplicarlo en esta clase.

Kenneth Angulo L

Hace un mes

¿Qué pasa si uso map directamente?

Si decides usar la función nativa Array.prototype.map para renderizar una lista extensa, te enfrentarás a un cuello de botella de rendimiento severo. Cada vez que un único elemento cambie su estado, la reactividad obligará a evaluar y re-renderizar absolutamente todos los elementos de la colección. Piensa en esto como si tuvieras que revisar cada libro de una biblioteca entera solo porque cambiaste de lugar un solo ejemplar. En listas pequeñas de dos o tres elementos, el impacto es imperceptible, pero en aplicaciones reales con cientos de filas de datos, este comportamiento destruirá la fluidez de la interfaz, consumiendo memoria y ciclos de CPU de forma redundante.

Kenneth Angulo L

Hace un mes

¿Por qué es mejor usar <For>?

Usar el componente <For> es fundamental porque SolidJS está diseñado para ser extremadamente atómico en sus actualizaciones. Imagina que tienes un muro de ladrillos y necesitas cambiar uno solo; en lugar de derribar todo el muro y volver a construirlo (que es lo que hace un map tradicional en JavaScript), <For> simplemente retira el ladrillo viejo y pone el nuevo. Este componente memoriza internamente los elementos de tu lista y rastrea sus cambios de forma individual. Al hacerlo, cuando modificas el estado de un elemento (como marcar una tarea como completada), SolidJS solo actualiza ese nodo específico en el DOM, ahorrando una enorme cantidad de recursos y evitando re-renderizados innecesarios que podrían congelar tu aplicación si la lista crece demasiado.

Danny González

Hace 3 años

  <For each={todos()}>
       {(todo,index)=>(
          <li>
            <input type="checkbox" checked={(console.log("test"),todo.completed)}
            onChange={()=>{ 
              setTodos((todos)=>
                todos.map((t,i)=>{
                   return i === index()
                   ? {
                    ...t,completed:!t.completed 
                   }:
                   t;
                })

            )}} />
            <span>
              <Show when={todo.completed} fallback={todo.text}>
                <s style="pointer-events:none">
                  {todo.text}
                </s>
              </Show>
            </span>
          </li>
        )
       }
         </For>

Recursos

Renderizar listas dinámicas en Solid puede parecer tan simple como hacer un map de JavaScript, pero esa decisión tiene un costo silencioso en el rendimiento. Aquí verás cómo pasar de listas estáticas a listas reactivas y por qué el componente For de Solid es la forma más eficiente de hacerlo cuando trabajas con signals.

¿Cómo convertir una lista estática en una lista reactiva con signals?

El primer paso es dejar de hardcodear elementos y mover la data a un signal. En lugar de escribir cada li a mano, defines un signal con todos y setTodos, y le pasas un valor por defecto: un array de objetos donde cada uno tiene un texto y un estado completed [00:35].

Con ese array ya disponible, accedes al signal como función (todos()) y haces map sobre él para retornar un li por cada elemento. Dentro de ese li, el texto del span y el estado del checkbox dejan de ser literales y pasan a leerse desde cada objeto: todo.text para el contenido y todo.completed para el checked y para el renderizado condicional con Show [02:30].

¿Por qué cada checkbox cambiaba el estado de todos los elementos al inicio? Porque todos compartían el mismo signal completed global. La solución es leer el estado desde cada objeto de la lista, no desde un signal externo.

¿Cómo actualizar un solo elemento sin romper la inmutabilidad?

Para cambiar el estado de un todo específico al hacer clic, usas setTodos con la forma funcional, que te entrega la lista actual. Dentro mapeas la lista comparando el índice actual contra el índice del elemento que cambió:

Si el índice coincide, retornas una copia del objeto con completed invertido (un toggle).
Si no coincide, retornas el elemento tal cual.
El resultado del map reemplaza el valor del signal.

Un detalle clave: la función del setter debe retornar algo. Si envuelves el map en llaves sin return, Solid recibe undefined y la lista se rompe. La forma más limpia es usar el retorno implícito de las arrow functions eliminando las llaves [06:50].

¿Por qué usar todos.map no es la forma óptima en Solid?

Solid se promociona como un framework atómico en sus actualizaciones, y map trabaja en contra de esa filosofía. Cada vez que el signal cambia, map recorre y reevalúa toda la lista completa, sin importar cuán pequeño fue el cambio.

Para comprobarlo, puedes inyectar un console.log dentro del atributo checked usando el comma operator de JavaScript. Esta técnica permite ejecutar una expresión adicional y devolver solo el último valor después de la coma, ideal para depurar reactividad sin alterar el comportamiento [08:40].

¿Qué es el comma operator en JavaScript? Un operador que evalúa varias expresiones separadas por comas y retorna únicamente la última. Útil para inyectar logs dentro de atributos JSX sin romper el valor que se entrega.

Al correr la app con ese log, ves que en el render inicial se ejecuta tres veces (una por elemento, lo esperado). Pero al hacer clic en un solo checkbox, vuelve a ejecutarse tres veces más. Cada cambio mínimo dispara la reevaluación de toda la lista. En listas grandes, ese costo se vuelve insostenible.

¿Cómo optimizar el renderizado de listas con el componente For?

Solid resuelve este problema con un componente JSX dedicado: <For>. Funciona parecido al Show que ya usaste para renderizado condicional, pero está diseñado para iterar.

La sintaxis cambia así:

Reemplazas {todos().map(...)} por <For each={todos()}>.
Dentro pasas una callback que recibe el elemento y, si lo necesitas, el índice.
Cierras con </For> al final del bloque iterado [10:50].

Hay un matiz importante: el índice que entrega For no es un valor plano, es un signal. Para leerlo tienes que ejecutarlo como función (index()) en cualquier lugar donde lo uses. Si lo tratas como variable estática, obtienes la referencia a la función y no su valor.

¿Qué hace For por debajo para ser tan eficiente?

Cuando vuelves a ejecutar la app con For y revisas la consola, el comportamiento cambia radicalmente. El render inicial sigue ejecutándose tres veces, pero al hacer clic en un checkbox, no se dispara ningún log adicional. Solid reconcilia solo el elemento afectado.

Esto es posible porque For usa internamente primitivas como memo para memorizar qué elementos ya están renderizados y detectar con precisión qué cambió. En lugar de regenerar la lista completa, aplica únicamente la mutación puntual al nodo correspondiente. Esa es la diferencia entre un framework que reacciona globalmente y uno que reacciona de forma atómica.

¿Cuándo conviene usar For en lugar de map? Siempre que renderices listas reactivas en Solid. map solo es aceptable para arrays estáticos que no cambian. En cuanto haya un signal detrás, For es la opción correcta para evitar reevaluaciones innecesarias.

Con esta base de listas reactivas y optimizadas ya tienes la estructura lista para sumar interacciones más complejas, como agregar, editar o eliminar elementos. ¿Te animas a contar en los comentarios qué patrón usabas antes en otros frameworks para resolver este mismo problema?

  <For each={todos()}>
       {(todo,index)=>(
          <li>
            <input type="checkbox" checked={(console.log("test"),todo.completed)}
            onChange={()=>{ 
              setTodos((todos)=>
                todos.map((t,i)=>{
                   return i === index()
                   ? {
                    ...t,completed:!t.completed 
                   }:
                   t;
                })

            )}} />
            <span>
              <Show when={todo.completed} fallback={todo.text}>
                <s style="pointer-events:none">
                  {todo.text}
                </s>
              </Show>
            </span>
          </li>
        )
       }
         </For>

Resumen

¿Cómo convertir una lista estática en una lista reactiva con signals?

¿Por qué cada checkbox cambiaba el estado de todos los elementos al inicio? Porque todos compartían el mismo signal completed global. La solución es leer el estado desde cada objeto de la lista, no desde un signal externo.

¿Cómo actualizar un solo elemento sin romper la inmutabilidad?

Si el índice coincide, retornas una copia del objeto con completed invertido (un toggle).
Si no coincide, retornas el elemento tal cual.
El resultado del map reemplaza el valor del signal.

¿Por qué usar todos.map no es la forma óptima en Solid?

¿Qué es el comma operator en JavaScript? Un operador que evalúa varias expresiones separadas por comas y retorna únicamente la última. Útil para inyectar logs dentro de atributos JSX sin romper el valor que se entrega.

¿Cómo optimizar el renderizado de listas con el componente For?

Solid resuelve este problema con un componente JSX dedicado: <For>. Funciona parecido al Show que ya usaste para renderizado condicional, pero está diseñado para iterar.

La sintaxis cambia así:

Reemplazas {todos().map(...)} por <For each={todos()}>.
Dentro pasas una callback que recibe el elemento y, si lo necesitas, el índice.
Cierras con </For> al final del bloque iterado [10:50].

¿Qué hace For por debajo para ser tan eficiente?

¿Cuándo conviene usar For en lugar de map? Siempre que renderices listas reactivas en Solid. map solo es aceptable para arrays estáticos que no cambian. En cuanto haya un signal detrás, For es la opción correcta para evitar reevaluaciones innecesarias.

Introducción a SolidJS

SolidJS vs React: reactividad granular explicada

Python para Principiantes: Fundamentos y Aplicaciones Básicas

Signals en SolidJS: crea datos reactivos

createEffect y side effects en SolidJS

Signals derivados vs createMemo en Solid

Reactividad a profundidad

Qué es la reactividad en Solid

Creación de una Librería Reactiva MiniSolid desde Cero

Implementación de Signals en Librería Reactiva Solid

Cómo createEffect conecta signals y efectos

Señales derivadas sin nuevas primitivas

createMemo para evitar renderizados innecesarios

Cómo Solid convierte JSX al DOM real

Renderizado en Solid

Configurando SolidJS con Tailwind para Todo App

Dark mode en SolidJS con signals

Renderizado Condicional en Solid: Técnicas y Optimización

Renderizado de listas reactivas con For en Solid

Manejo de Eventos en Elementos HTML con SolidJS

Reactividad en Listas

Optimización de Renderizado y Reactividad en Listas con SolidJS

Cómo funcionan los stores en Solid JS

Stores de SolidJS para datos complejos

Función produce para mutar stores en Solid

Componentes

Qué son los componentes en Solid

Comunicación padre-hijo con props en SolidJS

Eventos personalizados entre componentes React

Persistencia con localStorage y useEffect

Deploy de app Solid en Netlify

Solid y el futuro del desarrollo web

Renderizado de listas reactivas con For en Solid