Encontré un error y es que al filtar por Furnitures no filtra los items. La API los encuentra por Furniture, sin la S.

Construir una página de My Account en React te permite mostrar la información del usuario y editarla en tiempo real, conectándola con el local storage. Esta vista es clave en cualquier prueba técnica de frontend porque combina conditional rendering, formularios y manejo de estado, tres habilidades que reclutadores evalúan constantemente.
¿Cómo se construye la vista My Account paso a paso?
La solución parte de dos cambios concretos en el proyecto, descritos en el pull request número nueve [01:00].
Primero, hay que reemplazar el correo quemado del navbar por el email real del usuario. Para lograrlo, traes la información de account que ya está disponible en el componente Navbar y la inyectas en el campo correspondiente.
Segundo, creas la página MyAccount, donde aplicas conditional rendering mediante un componente llamado RenderView. Según el estado local, esa vista alterna entre dos pantallas: una para visualizar y otra para editar.
¿Qué es el conditional rendering en React? Es una técnica que muestra distintos componentes según el valor de una variable de estado. Si el estado dice ver, renderiza la información; si dice editar, renderiza el formulario.
¿Qué hace el componente RenderUserInfo?
Este componente se encarga solo de mostrar datos, nada más [02:30]. Lee la información de account desde el local storage y la pinta en pantalla junto con un botón Edit. Ese botón tiene un onClick que cambia la vista, exactamente como ya hiciste en la pantalla de Sign in.
¿Y qué hace RenderEditUserInfo?
Es el formulario que aparece al pulsar Edit. Su estructura es idéntica a la del formulario de creación de cuenta:
form que envuelve los campos.label e input precargados con los datos actuales.La precarga de los campos es importante porque le dice al usuario qué tiene guardado y qué puede modificar.
¿Cómo se editan los datos del usuario en local storage?
La lógica de edición replica el flujo de creación de usuario [03:45]. Tomas la información del formulario y la vuelves a setear sobre el objeto account que ya existe en local storage. Así, cuando el usuario hace clic en Editar, los cambios se reflejan tanto en la vista como en el almacenamiento del navegador.
Por ejemplo, si cambias el nombre a 123123 y el email a 123123, al confirmar verás de inmediato la actualización en la pantalla y en el local storage.
¿Por qué usar local storage en lugar de un backend? En una prueba técnica de frontend, el local storage simula la persistencia sin depender de un servidor. Es rápido de implementar y suficiente para demostrar manejo de estado y sincronización de datos.
¿Qué detalles visuales mejoran la experiencia final?
Durante las pruebas finales aparecieron dos ajustes pequeños pero relevantes, agrupados en el último pull request [05:10].
El primero corrige un texto desalineado dentro de las cards de producto. La solución usa items-center de Flexbox en Tailwind para centrar verticalmente el texto respecto al precio.
El segundo cambia el background del navbar. Antes, al hacer scroll, el contenido se entrecruzaba con las imágenes y los ítems del menú no se leían bien. La solución fue aplicar la clase bg-white de Tailwind para fijar un fondo blanco sólido.
¿Por qué importan estos detalles en una prueba técnica?
Porque revelan tu criterio de UI más allá de la funcionalidad. Un reclutador no solo evalúa que el código corra; también revisa si notas estos pulidos:
items-center y bg-white.Con estos ajustes, la prueba técnica queda completa: navegación funcional, autenticación simulada, gestión de cuenta editable y una interfaz pulida.
Muéstrame en los comentarios cómo resolviste tu versión y si encontraste un camino distinto al usar conditional rendering o al sincronizar el formulario con el local storage.
Construir una página de My Account en React te permite mostrar la información del usuario y editarla en tiempo real, conectándola con el local storage. Esta vista es clave en cualquier prueba técnica de frontend porque combina conditional rendering, formularios y manejo de estado, tres habilidades que reclutadores evalúan constantemente.
La solución parte de dos cambios concretos en el proyecto, descritos en el pull request número nueve [01:00].
Primero, hay que reemplazar el correo quemado del navbar por el email real del usuario. Para lograrlo, traes la información de account que ya está disponible en el componente Navbar y la inyectas en el campo correspondiente.
Segundo, creas la página MyAccount, donde aplicas conditional rendering mediante un componente llamado RenderView. Según el estado local, esa vista alterna entre dos pantallas: una para visualizar y otra para editar.
¿Qué es el conditional rendering en React? Es una técnica que muestra distintos componentes según el valor de una variable de estado. Si el estado dice ver, renderiza la información; si dice editar, renderiza el formulario.
Este componente se encarga solo de mostrar datos, nada más [02:30]. Lee la información de account desde el local storage y la pinta en pantalla junto con un botón Edit. Ese botón tiene un onClick que cambia la vista, exactamente como ya hiciste en la pantalla de Sign in.
Es el formulario que aparece al pulsar Edit. Su estructura es idéntica a la del formulario de creación de cuenta:
form que envuelve los campos.label e input precargados con los datos actuales.La precarga de los campos es importante porque le dice al usuario qué tiene guardado y qué puede modificar.
La lógica de edición replica el flujo de creación de usuario [03:45]. Tomas la información del formulario y la vuelves a setear sobre el objeto account que ya existe en local storage. Así, cuando el usuario hace clic en Editar, los cambios se reflejan tanto en la vista como en el almacenamiento del navegador.
Por ejemplo, si cambias el nombre a 123123 y el email a 123123, al confirmar verás de inmediato la actualización en la pantalla y en el local storage.
¿Por qué usar local storage en lugar de un backend? En una prueba técnica de frontend, el local storage simula la persistencia sin depender de un servidor. Es rápido de implementar y suficiente para demostrar manejo de estado y sincronización de datos.
Durante las pruebas finales aparecieron dos ajustes pequeños pero relevantes, agrupados en el último pull request [05:10].
El primero corrige un texto desalineado dentro de las cards de producto. La solución usa items-center de Flexbox en Tailwind para centrar verticalmente el texto respecto al precio.
El segundo cambia el background del navbar. Antes, al hacer scroll, el contenido se entrecruzaba con las imágenes y los ítems del menú no se leían bien. La solución fue aplicar la clase bg-white de Tailwind para fijar un fondo blanco sólido.
Porque revelan tu criterio de UI más allá de la funcionalidad. Un reclutador no solo evalúa que el código corra; también revisa si notas estos pulidos:
items-center y bg-white.Con estos ajustes, la prueba técnica queda completa: navegación funcional, autenticación simulada, gestión de cuenta editable y una interfaz pulida.
Muéstrame en los comentarios cómo resolviste tu versión y si encontraste un camino distinto al usar conditional rendering o al sincronizar el formulario con el local storage.
Encontré un error y es que al filtar por Furnitures no filtra los items. La API los encuentra por Furniture, sin la S.

Quisiera dejar por acá mi idea de diseño para la página My Account: . Cree una vista con un botón de edit para cada campo, cuando este es clickeado, el texto se transforma en un input que permite setear la info:
.
.
.
.

Hola, estoy tratando de hacer la logoca de cracion de usuarios en proyecto, para estoy estoy tratando de validar primero que el correo esté disponible po medio del API, este es mi codigo:
async function checkEmail(userData, onSuccess){
const API = 'https://api.escuelajs.co/api/v1/users/is-available';
const emailToCheck = {email: userData.email}
//email to check tiene formato de correo
const query = {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify(emailToCheck)
}
try {
const response = await fetch (API, query);
const data = await response.json();
console.log(data);
}catch(error){
console.error('Error', error);
}
}
se supone que este llamdo a la api responde con un objeto el cual si el correo no está disponible debe ser
{isAvailable: false}
pero si el correo que estoy validando no está registrado en el API la respuesta deberia ser:
{isAvailable: true}
siembargo la respuesta que obtengo es siempe false. ¿´porqué? pd: ya validé la lista de usuarios registrados en el api y me asegurpe de mandar uno que no estviera en la lista y la respuesta sigue siendo false es decir que no está disponible.
¡Hola a todos! 👋
Quiero compartirles que la API original del curso está rota, lo que puede dificultar completar los ejercicios. Para ayudarles, he creado una versión funcional del proyecto base con una nueva API y código actualizado. 🚀
Pueden clonar este repositorio para seguir el curso sin problemas:
👉 <>
Además, si les resulta útil, no olviden darle una estrella ⭐ al repositorio y seguirme en GitHub. ¡Espero que les sea de ayuda y puedan completar el curso con éxito! 💚
¡Happy coding! 💻

Habilite el Home pero con la condicion de que si agrega un produto al carrito y quiere comprarlo debe iniciar sesion! en caso de hacer click lo direcciona al sign-in
✨🦄 Considero que la sección de MyAccount debía estar dentro del primer issue, ya que está relacionado mucho con las páginas de Log In y Sign Up.
Pero esta es la manera en que desarrollé esta sección n.n


Cada cosa con su validación :3

Yo lo que hice fue utilizar el código que ya tenia para crear un usuario, lo extraje e hice un componente el cual cambia el valor del botón "Create/Edit" según donde sea llamado. Capaz abuso del useState un poco o no ?
En el context
Y el resto seria con el onClick hacer el cambio con setText y utilizar otro estado para el render. Ej de MyAccount 

Así quedó mi route "My Account":

Cuando el state view sea igual a "edit-user-info" agrego un button al lado del título con el cual puedo volver "user-info" por si algún usuario se arrepiente de editar su cuenta.

A la teacher se le fue el sonido
Les comparto como me quedo:
