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?