Skip to content

Laboratoria/DEV004-social-network-lite

BranchesTags

Repository files navigation

Creando una Red Social

Índice

1. Preámbulo

Instagram, Snapchat, Twitter, Facebook, Twitch, Linkedin, etc. Las redes sociales han invadido nuestras vidas. Las amamos u odiamos, y muchos no podemos vivir sin ellas.

adem-ay-Tk9m_HP4rgQ-unsplash

Hay redes sociales de todo tipo y para todo tipo de intereses. Por ejemplo, en una ronda de financiamiento con inversionistas, se presentó una red social para químicos en la que los usuarios podían publicar artículos sobre sus investigaciones, comentar en los artículos de sus colegas, y filtrar artículos de acuerdo a determinadas etiquetas o su popularidad, lo más reciente, o lo más comentado.

2. Resumen del proyecto

En este proyecto construirás una Red Social sobre lo que decidan tú y tu equipo. Podría ser, por ejemplo, sobre alimentación saludable, feminismo, educación, salud, energías renovables, amantes de las Empanadas o de los Tacos de Canasta, de la Feijoada, o de lo que sea.

Tu Red Social tendrá que permitir a cualquier usuario crear una cuenta de acceso y loguearse con ella; crear, editar, borrar y "likear" publicacciones.

Por lo tanto, en este proyecto construirás una Single-page Application (SPA) responsive (con más de una vista / página) en la que podamos leer y escribir datos.

Los objetivos generales de este proyecto son los siguientes

  • Desarrollar una SPA con temática de red social
  • Aplicar los conceptos de responsividad en el desarrollo de las vistas (templates)
  • Implementar un router para la navegación entre las diferentes vistas de la aplicación
  • Emplear un servicio externo para la persistencia de datos de la aplicación
  • Crear una suite de pruebas unitarias que permitan testear código asíncrono

Para lograr estos objetivos, deberás aprender y hacer uso de las siguientes herramientas o habilidades técnicas:

3. Objetivos de aprendizaje

Reflexiona y luego marca los objetivos que has llegado a entender y aplicar en tu proyecto. Piensa en eso al decidir tu estrategia de trabajo.

HTML

CSS

Web APIs

JavaScript

  • Uso de linter (ESLINT)

  • Uso de identificadores descriptivos (Nomenclatura y Semántica)

  • Diferenciar entre expresiones (expressions) y sentencias (statements)

  • Callbacks

    Links

Control de Versiones (Git y GitHub)

  • Git: Instalación y configuración

  • Git: Control de versiones con git (init, clone, add, commit, status, push, pull, remote)

  • Git: Integración de cambios entre ramas (branch, checkout, fetch, merge, reset, rebase, tag)

  • GitHub: Creación de cuenta y repos, configuración de llaves SSH

  • GitHub: Despliegue con GitHub Pages

    Links

  • GitHub: Colaboración en Github (branches | forks | pull requests | code review | tags)

  • GitHub: Organización en Github (projects | issues | labels | milestones | releases)

Centrado en el usuario

  • Diseñar y desarrollar un producto o servicio poniendo a las usuarias en el centro

Diseño de producto

  • Crear prototipos de alta fidelidad que incluyan interacciones

  • Seguir los principios básicos de diseño visual

Investigación

4. Consideraciones generales

  • La lógica del proyecto debe estar implementada completamente en JavaScript (ES6+), HTML y CSS 😃. Para este proyecto no está permitido utilizar frameworks o librerías de CSS y JS.

  • Solamente pueden trabajar en una única historia por vez, no pueden avanzar a la siguiente sin haber completado la anterior. La historia se completa cuando se cumplen todos sus Criterios de Aceptación + toda su Definición de Terminado.

Para comenzar tendrás que hacer un fork y clonar este repositorio.

5. Criterios de aceptación mínimos del proyecto

5.1 Boilerplate

Este proyecto no incluye un boilerplate completo, solo algunos archivos de configuración basico, así es que tendrás que definir la estructura de carpetas y escribir tus propias Pruebas Unitarias (tests). Para hacerlo, puedes guiarte de los proyectos anteriores y/o organizar los archivos siguiendo una estructura de Modelo-Vista-Controlador.

En este proyecto vamos a usar una herramienta llamada Vite para empaquetar nuestros módulos y arrancar el servidor de desarrollo, el cual provee nuestros archivos utilizando la estrategia Hot Module Replacement (HMR), esto significa que cuando hagas cambios en los archivos que estén siendo servidos, el navegador automáticamente se actualizará sin tener que refrescar y volver a cargar todo el sitio. Debes tener especial cuidado de no tener ninguna dependencia circular en tu código ya que eso puede ocasionar problemas con HMR. (eslint-plugin-import tiene una regla import/no-cycle que va a avisar si las tiene.)

5.2 Definición del producto

En el README.md cuéntanos brevemente cómo descubriste las necesidades de los usuarios y cómo llegaste a la definición final de tu producto. Es importante que detalles:

  • Quiénes son los principales usuarios de producto.
  • Qué problema resuelve el producto / para qué le servirá a estos usuarios.

5.3 Historias de usuario

Una vez que entiendas las necesidades de tus usuarixs, escribe las Historias de Usuario que representen todo lo que necesitan hacer/ver en la Red Social. Cada una de tus Historias de Usuario debe tener:

  • Criterios de Aceptación: todo lo que debe ocurrir para satisfacer las necesidades del usuario.

  • Definición de terminado: todos los aspectos técnicos que deben cumplirse para que, como equipo, sepan que esa historia está terminada y lista para publicarse. Todas tus Historias de Usuario (salvo excepciones), deben incluir estos aspectos en su Definición de Terminado (más todo lo que necesiten agregar):

    • Debe ser una SPA.
    • Debe ser responsive.
    • Deben haber recibido code review de al menos una compañera de otro equipo.
    • Hicieron los test unitarios
    • Testearon manualmente buscando errores e imperfecciones simples.
    • Hicieron pruebas de usabilidad e incorporaron el feedback de los usuarios como mejoras.
    • Desplegaron su aplicación y etiquetaron la versión (git tag).

5.4 Diseño de la Interfaz de Usuario (prototipo de baja fidelidad)

Debes definir cuál será el flujo que seguirá el usuario dentro de tu aplicación y, con eso, diseña la Interfaz de Usuario (UI por sus siglas en inglés) que siga este flujo.

5.5 Responsive

Debe verse bien en dispositivos de pantallas grandes (computadoras/es, laptops, etc.) y pequeñas (tablets, celulares, etc.). Te sugerimos seguir la técnica de mobile first (más detalles sobre esta técnica al final).

5.6 Consideraciones del comportamiento de la interfaz de usuario (UI)

Estas consideraciones te ayudarán a escribir las Definiciones de Terminado de tus H.U.:

Creación de cuenta de usuario e inicio de sesión

  • Login:
    • Para el login y las publicaciones en el muro debes utilizar las funciones del archivo src/lib/services.js
    • Creación de cuenta de acceso y autenticación con cuenta de correo y contraseña, y también con una cuenta de Google.
  • Validaciones:
    • Solamente se permite el acceso a usuarios con cuentas válidas.
    • No pueden haber usuarios repetidos.
    • La cuenta de usuario debe ser un correo electrónico válido.
    • Lo que se escriba en el campo (input) de contraseña debe ser secreto.
  • Comportamiento:
    • Al enviarse el formulario de registro o inicio de sesión, debe validarse.
    • Si hay errores, se deben mostrar mensajes descriptivos para ayudar al usuario a corregirlos.

Muro/timeline

  • Validaciones:
    • Al publicar, se debe validar que exista contenido en el input.
  • Comportamiento:
    • Al recargar la aplicación, se debe verificar si el usuario está logueado antes de mostrar contenido.
    • Poder publicar un post.
    • Poder eliminar un post específico.
    • Pedir confirmación antes de eliminar un post.
    • Al dar click para editar un post, debe cambiar el texto por un input que permita editar el texto y luego guardar los cambios.
    • Al guardar los cambios debe cambiar de vuelta a un texto normal pero con la información editada.
    • Al recargar la página debo de poder ver los textos editados.

5.7 Consideraciones técnicas Front-end

  • Separar la manipulación del DOM de la lógica (Separación de responsabilidades).
  • Contar con múltiples vistas. Para esto, tu aplicación debe ser una Single Page Application (SPA)
  • Alterar y persistir datos. Los datos que agregues o modifiques deberán persistir a lo largo de la aplicación. Usa las funciones del archivo src/lib/services.js para esto.

Pruebas unitarias (unit tests)

  • Recuerda que no hay un setup de tests definido, dependerá de la estructura de tu proyecto. Algo que no debes de olvidar es pensar en éstas pruebas, te pueden ayudar a definir la estructura y nomenclatura de tu lógica.

  • Los tests unitarios deben cubrir un mínimo del 70% de statements, functions, lines, y branches.

5.8 Consideraciones técnicas UX

  • Hacer al menos 2 entrevistas con usuarios.
  • Hacer un prototipo de baja y alta fidelidad.
  • Asegurarte de que la implementación en código siga los lineamientos del diseño.
  • Hacer sesiones de testing de usabilidad con el producto en HTML.

6. Hacker edition

Las secciones llamadas Hacker Edition son opcionales. Si terminaste con todo lo anterior y te queda tiempo, intenta completarlas. Así podrás profundizar y/o ejercitar más sobre los objetivos de aprendizaje del proyecto.

  • Poder dar y quitar like a una publicación. Máximo uno por usuario.
  • Llevar un conteo de los likes.

7. Entrega

El proyecto será entregado subiendo tu código a GitHub (commit/push) y la interfaz será desplegada usando GitHub pages u otro servicio de hosting (Firebase, Netlify, Vercel, etc) que puedas haber encontrado en el camino. Revisa la documentación de Vite para guiarte con eso.

8. Pistas, tips y Lecturas complementarias

Mobile first

El concepto de mobile first hace referencia a un proceso de diseño y desarrollo donde partimos de cómo se ve y cómo funciona la aplicación en un dispositivo móvil primero, y más adelante se ve como adaptar la aplicación a pantallas progresivamente grandes y características específicas del entorno desktop. Esto es en contraposición al modelo tradicional, donde primero se diseñaban los websites (o webapps) para desktop y después se trataba de arrugar el diseño para que entre en pantallas más chicas. La clave acá es asegurarse de que desde el principio diseñan usando la vista responsive de las herramientas de desarrollador (developer tools) del navegador. De esa forma, partimos de cómo se ve y comporta la aplicación en una pantalla y entorno móvil.

Múltiples vistas

En proyectos anteriores nuestras aplicaciones habían estado compuestas de una sola vista principal (una sóla página). En este proyecto se introduce la necesidad de tener que dividir nuestra interfaz en varias vistas o páginas y ofrecer una manera de navegar entre estas vistas. Este problema se puede afrontar de muchas maneras: con archivos HTML independientes (cada uno con su URL) y links tradicionales, manteniendo estado en memoria y rederizando condicionalmente (sin refrescar la página), manipulando el historial del navegador con window.history. En este proyecto te invitamos a explorar opciones y decidir una opción de implementación.

Escritura de datos

Para almacenar los usuarios y publicaciones de la red social vamos a usar las funciones del archivo src/lib/services.js.

En este archivo tenemos las siguientes funciones:

  • login (email, password): Esta función devuelve true si existe un usuario con el correo y contraseña. Devuelve false si el usuario no existe o la contraseña es inválida.

  • getLoggedInUser(): Esta función devuelve el usuario conectado. Devuelve null si no hay ningún usuario registrado.

  • logout(): Esta función cierra la sesión del usuario.

  • register(email, password): Esta función registra un nuevo usuario. Devuelve true si el usuario se ha registrado correctamente. Lanza un error si el usuario ya existe.

  • getPosts(): Esta función devuelve un array de posts. Cada elemento del arreglo tiene la siguiente estructura:

    { id: string, contenido: string, email: string }

  • createPost(content, email): Esta función crea un nuevo post y devuelve su id

  • editPost(idPost, content): Esta función edita el contenido de una entrada. Lanzar un error si el post no existe.

  • deletePost(idPost): Esta función elimina un post. Lanzar un error si el post no existe.

Otras:

About

No description, website, or topics provided.

Resources

Readme
Activity
Custom properties

Stars

0 stars

Watchers

3 watching

Forks

1 fork
Report repository

Releases

No releases published

Packages

 
 
 

Contributors

Languages