- 1. Preámbulo
- 2. Resumen del proyecto
- 3. Objetivos de aprendizaje
- 4. Consideraciones generales
- 5. Criterios de aceptación mínimos del proyecto
- 6. Hacker edition
- 7. Consideraciones técnicas
- 8. Pistas, tips y lecturas complementarias
- 9. Checklist
El juego Memory Match, también conocido como Concentration, Match Match, Match Up, Memory, entre otros, es un juego de cartas en el que todas las cartas se ponen cara abajo sobre una superficie y se le dan la vuelta a dos cartas en cada turno. El objetivo del juego es destapar parejas de cartas que coincidan.
Ejemplos:
En este proyecto construirás una versión web del juego Memory Match, en la que una jugadora pueda jugar sola, en el navegador.
El objetivo principal de este proyecto es que aprendas a diseñar y construir una interfaz web basada en data e interacción con la usuaria.
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.
-
Uso de selectores del DOM
-
Manejo de eventos del DOM (listeners, propagación, delegación)
-
Manipulación dinámica del DOM
-
Diferenciar entre tipos de datos primitivos y no primitivos
-
Arrays (arreglos)
-
Objetos (key, value)
-
Variables (declaración, asignación, ámbito)
-
Uso de condicionales (if-else, switch, operador ternario, lógica booleana)
-
Uso de bucles/ciclos (while, for, for..of)
-
Funciones (params, args, return)
-
Pruebas unitarias (unit tests)
-
Módulos de ECMAScript (ES Modules)
-
Uso de linter (ESLINT)
-
Uso de identificadores descriptivos (Nomenclatura y Semántica)
-
Diferenciar entre expresiones (expressions) y sentencias (statements)
-
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
- GitHub: Colaboración en Github (branches | forks | pull requests | code review | tags)
- Este proyecto se debe resolverse de forma individual.
- El proyecto será entregado subiendo tu código a GitHub (commit/push) y la interfaz será desplegada usando GitHub Pages.
- Tiempo para completarlo: Toma como referencia 3 semanas.
Los criterios para considerar que has completado este proyecto son:
No es necesario que construyas la interfaz de usuario desde 0, por eso este proyecto viene con un prototipo de alta fidelidad en HTML/CSS.
Tu tiempo de hacking es escaso, así que deberás priorizar en los OAs que necesitas trabajar.
Como mínimo, tu implementación debe:
- Dado un set de cartas, barajar las cartas y mostrarlas en la interfaz usando el algoritmo de Fisher-Yates.
- Permitir al usuario destapar máximo 2 cartas a la vez, eso quiere decir que no pueden haber mas de 3 cartas giradas al mismo tiempo.
- Al girar las cartas dejar las cartas que coincidan giradas.
- Indicar al usuario que ganó cuando haya girado todas las cartas.
La lógica del proyecto debe estar implementada completamente en JavaScript, HTML y CSS. En este proyecto NO está permitido usar librerías o frameworks, solo vanilla JavaScript.
Para iniciar un nuevo juego, siempre tendremos que barajar las cartas antes de pintarlas en la pantalla. Para eso, te invitamos a que explores algoritmos existentes para este tipo de operación (llamada shuffle en inglés), como por ejemplo el algoritmo de Fisher-Yates (aka Knuth).
En este proyecto no se espera que inventes o implementes tu propio algoritmo
para barajar las cartas, si no que googlees, veas opciones existentes,
consideres opciones y adaptes una a tu proyecto (agregando una función shuffle
que se pueda usar en tu aplicación).
El boilerplate contiene una estructura de archivos como punto de partida, asi como el prototipo de alta fidelidad en HTML/CSS y la configuración de dependencias.
.
├── .babelrc
├── .editorconfig
├── .eslintrc
├── .gitignore
├── package.json
├── README.md
└── src
├── components
│ ├── App.js
│ └── App.spec.js
├── data
│ ├── pokemon
│ │ ├── pokemon.js
│ │ └── pokemon.json
│ ├── README.md
│ └── webdev
│ ├── webdev.js
│ └── webdev.json
├── index.html
├── main.js
└── style.css
A diferencia del proyecto anterior, en este archivo hemos incluido la estructura HTML que sera requerida como punto de partida.
A diferencia del proyecto anterior, en este proyecto hemos dado estilos por lo que no deberás preocuparte por ello, de tal forma que tu no necesitas hacerlo y podrás dedicarte a navegar el garabato desde JS y el DOM.
Recomendamos usar src/main.js como punto de entrada de tu aplicación. El
boilerplate incluye este archivo para conectar o montar el componente
App en el DOM. De esta forma podremos hacer pruebas unitarias de nuestros
componentes sin necesidad de que estén conectados a un DOM global.
Esta no es la única forma de dividir tu código, puedes usar más archivos y carpetas, siempre y cuando la estructura sea clara para tus compañeras.
Este archivo contiene un componente de ejemplo que muestra cómo podemos
representar un componente como una función que retorna un HTMLElement. A la
hora de construir interfaces es útil pensar en términos de componentes o
vistas que podemos ir anidando unas dentro de otras. Te invitamos a que
pienses qué componentes o cajitas necesitas para construir tu aplicación y
que vayas agregando componentes en el directorio components para implementar
cada uno de ellos. Aunque, otra vez, la forma de organizar tu archivos depende
al final de tí y de tu equipo. Hay muchas formas de hacerlo, y el boilerplate
es solo una sugerencia 🙊.
Este archivo muestra cómo podemos crear archivos con especificaciones (expresadas como pruebas unitarias) de nuestros componentes.
En esta carpeta hay data con sets de cartas de ejemplo que puedes usar en tu
aplicación, así como información sobre cómo agregar tus propios sets.
Encontrarás una carpeta por cada set, y dentro de cada carpeta dos archivos: uno
con la extensión .js y otro .json. Ambos archivos contienen la misma data;
la diferencia es que el .js lo usaremos a través de un import, mientras que
el .json está ahí para opcionalmente cargar la data de forma asíncrona con
fetch().
Cuando ya estés lista para codear, te sugerimos empezar de esta manera:
-
Debes hacer un 🍴 fork del repo de tu cohort, tus coaches te compartirán un link a un repo y te darán acceso de lectura en ese repo.
-
⬇️ Clona tu fork a tu computadora (copia local) con el siguiente comando
git clone --branch js git@github.com:Laboratoria/CDMX011-memory-match.git
-
📦 Instala las dependencias del proyecto con el comando
npm install. Esto asume que has instalado Node.js (que incluye npm). -
Si todo ha ido bien, deberías poder ejecutar las 🚥 pruebas unitarias (unit tests) con el comando
npm test. -
Para ver la interfaz de tu programa en el navegador, usa el comando
npm startpara arrancar el servidor web y dirígete ahttp://localhost:5000en tu navegador. -
A codear se ha dicho! 🚀
- Unidad de arreglos en curso de JavaScript en LMS.
- Unidad de objetos en curso de JavaScript en LMS.
- Unidad de funciones en curso de JavaScript en LMS.
- Unidad de DOM en curso de Browser JavaScript en LMS.
- Array en MDN
- Array.sort en MDN
- Array.map en MDN
- Array.filter en MDN
- Array.reduce en MDN
- Array.forEach en MDN
- Object.keys en MDN
- Object.entries en MDN
- json.org
- expressions-vs-statements
- expresión vs sentencia
- datos atómicos vs datos estructurados
- Modulos: Export
- Modulos: Import
- Historias de Usuario. Ojo que Cris no diferencia Definición de terminado de Criterios de Aceptación y nosotros sí lo haremos. Más detalles en la guía.
- Cómo dividir H.U.
- Guía de Historias de usuario
- Usa VanillaJS.
- Pasa linter (
npm run pretest) - Pasa tests (
npm test) - UI: Muestra cartas barajadas correctamente.
- UI: Permite al usuario destapar las cartas de 2 en 2.
- UI: Deja destapadas las cartas que coincidan al destaparlas.
- UI: Indica al usuario que ganó cuando sea relevante.