{"id":20671293,"url":"https://github.com/allnulled/reactivist","last_synced_at":"2026-04-24T13:03:06.228Z","repository":{"id":98546952,"uuid":"158347266","full_name":"allnulled/reactivist","owner":"allnulled","description":"Plantilla base para proyectos de componentes web basados en React/Redux + Sass + Browserify + Cypress + QUnit + Istanbul + Grunt + Mermaid/Markdown + ...","archived":false,"fork":false,"pushed_at":"2018-11-20T08:22:08.000Z","size":610,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"master","last_synced_at":"2025-04-12T06:39:10.136Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/allnulled.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-11-20T07:20:30.000Z","updated_at":"2020-11-03T19:03:16.000Z","dependencies_parsed_at":"2023-05-29T11:30:29.049Z","dependency_job_id":null,"html_url":"https://github.com/allnulled/reactivist","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/allnulled/reactivist","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/allnulled%2Freactivist","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/allnulled%2Freactivist/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/allnulled%2Freactivist/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/allnulled%2Freactivist/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/allnulled","download_url":"https://codeload.github.com/allnulled/reactivist/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/allnulled%2Freactivist/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32224413,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-24T10:26:35.452Z","status":"ssl_error","status_checked_at":"2026-04-24T10:25:27.643Z","response_time":64,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-16T20:26:14.662Z","updated_at":"2026-04-24T13:03:06.212Z","avatar_url":"https://github.com/allnulled.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Reactivist: una plantila de proyecto para componentes React\n\n***Reactivist*** es una nueva *plantila de proyecto para componentes React* basada en:\n\n|Parte |Contribución |\n|--------------:|------------------|\n| **Componentes:** | React |\n| **Eventos:** | Redux |\n| **Estilos:** | Sass |\n| **Módulos:** | Browserify |\n| **Tests de usuario:** | Cypress |\n| **Tests unitarios:** | QUnit/Electron |\n| **Cobertura de código:** | NYC |\n| **Documentación:** | Javadoc/Markdown/Mermaid |\n| **Desarrollo:** | Grunt/Chokidar/Socket.io/... |\n| **Incluye:** | Flujos de trabajo definidos |\n|  | Comandos por defecto y personalizables |\n|  | Configuraciones de los comandos |\n|  | Configuraciones de entorno |\n|  | Tests unitarios en vivo |\n|  | Tests de usuario en vivo |\n|  | Simples pero avanzadas herramientas |\n|  | Método de trabajo definido |\n\n# Índice\n\n1. [Índice](#indice)\n2. [Instalación](#instalación)\n3. [Referencia de la CLI](#referencia-de-la-cli)\n4. [Arquitectura](#arquitectura)\n5. [Requisitos](#requisitos)\n6. [Flujos de trabajo](#flujos-de-trabajo)\n7. [Referencia de la API](#referencia-de-la-api)\n8. [Tests de usuario](#tests-de-usuario)\n9. [Tests unitarios](#tests-unitarios)\n10. [Comandos](#comandos)\n11. [Cambios](#changelog)\n12. [Licencia](#licencia)\n\n# Instalación\n\nPara instalar la herramienta `reactivist` sólo tienes que ejecutar en tu línea de comandos:\n\n~$ `npm install --save-dev reactivist`\n\n\nSi quieres poder ejecutar el comando de CLI de `reactivist` en cualquier parte fácilmente:\n\n~$ `npm install --global reactivist`\n\n\n# Referencia de la CLI\n\nPara crear un nuevo proyecto `reactivist`, simplemente ejecuta en línea de comandos:\n\n```\n ~$ reactivist --folder \"src/components/MyNewComponent\" \n```\n\nOptionalmente, se pueden proporcionar estas opciones:\n\n```\n    [--name \"MyNewComponent\"]             # Nombre general\n    [--package \"my-new-component-module\"] # Nombre del paquete npm, para el package.json#name\n```\n\nEntonces, los ficheros de un proyecto `reactivist` básicos se copiarán, y las dependencias correspondientes se instalarán (en un proyecto nuevo, si es necesario).\n\n\n\n\n\n\n\n\n\n# Arquitectura\n\nLa arquitectura del proyecto se crea a partir de saber qué debe cumplir éste.\n\nEn esta guía se hablará de: \n\n - requisitos\n - soluciones\n - herramientas\n - implementaciones\n - ventajas\n - desventajas\n - otros temas\n\n\n\n\n\n## Requisitos\n\n`Reactivist` se creó para cumplir unos objetivos.\n\n- Crear proyectos de componentes web...:\n   - open source\n   - reusables\n   - mantenibles\n   - escalables\n   - hechos rápidamente\n   - con sintaxis avanzadas\n   - con dependencias comunes \n   - con sistema de módulos y dependencias flexible\n   - con manejo de estilos con lógica y escalable\n   - con comandos típicos del desarrollo incorporados \n   - con manejo de internacionalización\n   - con manejo fluído de documentación\n   - con entornos para tests de usuario\n   - con entornos para tests unitarios\n   - con cobertura de código incorporada en los tests\n   - con flujos de trabajo definidos\n   - con documentación suficiente\n   - con entorno asistido de compilación/transpilación\n   - que, sobre todo:\n      - delimite claramente el área de trabajo del desarrollador\n      - facilite la trazabilidad del trabajo\n      - facilite el uso de buenas prácticas mucho\n\n\n\nEl nivel de detalle de los puntos es superficial. Sin embargo, en las soluciones se expondrán más en profundidad.\n\n\n\n\n\n## Soluciones\n\nLas soluciones que pretende aportar `Reactivist` se definen en función de los requisitos para los que se pensó.\n\nPor eso, listaremos los requisitos, y explicaremos a continuación las soluciones que se proponen en los proyectos basados en `Reactivist`.\n\n### open source\n\nEl código se puede encontrar en `github` y es un módulo de `npm` también. Además, genera módulos `npm` compatibles con `browserify`.\n\n### reusables\n\nLos componentes se desarrollarían en `react`.\n\n### mantenibles\n\nLos componentes sobreentenderían el uso de `redux`, `react-redux`, `redux-thunk`, y probablemente más.\n\nCon `react` conseguiríamos sistemas de plantillas (estaticidad).\n\nCon `redux` conseguiríamos sistemas de eventos (dinamicidad).\n\nCon `react-redux` conseguiríamos conectar más fácilmente los anteriores.\n\nCon `redux-thunk` conseguiríamos lanzar eventos asíncronamente.\n\n### escalables\n\nLos componentes se podrían usar unos dentro de otros gracias a `react`.\n\nLos eventos podrían convivir entre componentes si:\n\n   - se define un sistema de espacios de nombres\n   - se implementa a la hora de desarrollar componentes\n\n### hechos rápidamente\n\nSe podrían crear nuevos proyectos `Reactivist` o componentes `Reactivist` (que equivaldrían a lo mismo) desde la línea de comandos muy fácilmente.\n\n### con sintaxis avanzadas\n\nSe utilizaría una sintaxis `es6` con `babel`.\n\nSe utilizaría un preset preparado especialmente para sintaxis `jsx` de `react`.\n\nSe utilizaría una sintaxis para los estilos `sass` con ficheros `scss`.\n\nSe utilizaría una sintaxis específica familiar o similar a `cucumber` (no implementado) para definir los tests de usuario.\n\nSe utilizaría una sintaxis de marcado como `markdown` para generar documentación estéticamente flexible.\n\nSe utilizaría una sintaxis de gráficos como `mermaid` para generar documentación basada en gráficos, esquemas y diagramas.\n\nSe utilizarían sintaxis básicas de desarrollo web como `html`, `css` y `js`.\n\nSe utilizarían sintaxis de documentos estáticos como `json`, `yaml`, `xml`, etc.\n\n### con dependencias comunes\n\nSe utilizaría un sistema de módulos externos como `npm`, el cual ya gestiona la interdependencia de módulos a nivel de proyectos.\n\nSe utilizaría un sistema de módulos externas como `browserify` a nivel de lógica pura de aplicación. `import`, `ScriptLoader`, `window`.\n\nSe utilizaría un sistema de módulos externas como `sass` a nivel de lógica de estilos de la aplicación. `@import {file/npm module/url}`.\n\n### con sistema de módulos y dependencias flexible\n\nCon `npm` podríamos manejar los módulos que estarían disponibles en `node.js`, `browserify` y `sass`.\n\n### con manejo de estilos con lógica y escalable\n\nCon `sass` podríamos crear módulos con lógica, subirlos a `npm` y reusarlos. \n\n### con comandos típicos del desarrollo incorporados \n\nCon `grunt` y `gruntfile.js` los ficheros `dev/grunt:*.js` son automáticamente comandos disponibles ejecutando `grunt *`.\n\n### con manejo de internacionalización\n\nLos ficheros `i18n/*.po` pueden integrarse en el desarrollo con el comando `grunt i18n`.\n\n### con manejo fluído de documentación\n\nEl comando `grunt docs` generará toda la documentación que nosotros le vayamos configurando en `settings.json`.\n\nPara ello usamos `javadoc` para extraer la documentación de los comentarios `js`, y `mermaid` para generar gráficos.\n\n### con entornos para tests de usuario\n\nLos tests de usuario son ejecutados mediante `grunt e2e`, y usarían `cypress` ( + `mocha` + `chai` + ...).\n\nLos tests de usuario pueden ser escritos desde `test/e2e/integration/*.test.jsx`.\n\n### con entornos para tests unitarios\n\nLos tests unitarios son compilados e integrados en la aplicación (en entorno `\"test\"` solamente) desde `test/unit/dist/bundle.*`.\n\nLos tests unitarios pueden ser escritos desde `test/unit/src/index.jsx`.\n\n### con cobertura de código incorporada en los tests\n\nLos tests unitarios generarían reportes de cobertura de código a todos los ficheros bajo `src/*` que fueran usados en los tests.\n\nLos tests unitarios generarían reportes de cobertura de código en `unit/coverage`.\n\n### con flujos de trabajo definidos\n\nEn la carpeta `docs/workflows` se especifican los flujos de trabajo contemplados para cualquier proyecto.\n\n### con documentación suficiente\n\nTenemos múltiples ficheros esparcidos por la aplicación que son explicativos y se integran en la documentación de manera automática (con `grunt docs`).\n\nTodos los ficheros `*.md` (para `markdown`) y `*.mmd` (para `mermaid`) están exclusivamente destinados a la documentación.\n\nTambién se genera documentación de los comentarios `javadoc` del código fuente, los estilos y los tests (todo configurable).\n\nToda la documentación generada está configurada para unificarse en el `README.md` del proyecto ordenadamente.\n\n### con entorno asistido de compilación/transpilación\n\nPodríamos iniciar el modo desarrollo con los comandos `grunt serve` y `grunt watch` paralelamente.\n\n### que delimite claramente el área de trabajo del desarrollador\n\nLos flujos están desarrollados más en profundidad en la carpeta de `docs/workflows`.\n\nTodo el proyecto está pensado para que el programador sepa qué debe hacer en cada momento, para que no pierda tiempo en el desarrollo por inexperiencia.\n\n### que facilite la trazabilidad del trabajo\n\nLos flujos de trabajo ya contemplan el uso de estos ficheros que, a medida que se va avanzando en el proyecto, se va quedando registrado toda la actividad.\n\nEl control de versiones es una herramienta más del flujo de trabajo, y ella más que ninguna determina la trazabilidad.\n\n### que facilite el uso de buenas prácticas mucho\n\nBuena parte de la documentación se genera de documentar el código, cosa que tradicionalmente es una buena práctica.\n\nEl proyecto, de base, ya prevee que vas a utilizar herramientas que son bastante avanzadas ahora mismo en el mercado, como `browserify`, `jsx` con `react`, o `redux`. No obstante, hay que decir que es bastante agnóstico en qué tipo de herramienta quieres desarrollar, y por tanto las buenas prácticas, en tanto que código, no están especialmente contempladas en este proyecto. Sin embargo, se brindan muchas herramientas para que se pueda desarrollar cómodamente esta parte del proceso, como la autogeneración de documentación con lenguaje de marcado o un lenguaje específicamente preparado para generar mapas conceptuales, gráficos y árboles.\n\nLos flujos de trabajo están pensados precisamente para que, siguiendo las buenas prácticas, el programador se sitúe rápidamente en el desarrollo.\n\nAdemás, de todo este proyecto ya se desprende un procedimiento, que se formalizará con el punto de esta guía que explica los `workflows` o flujos de trabajo.\n\n\n\n\n\n\n\n\n\n\n## Herramientas\n\nLas herramientas que este proyecto utilizará se pueden consultar fácilmente en el `package.json` de la aplicación.\n\nDe momento, esta guía no pretende explicar qué hace cada dependencia explícitamente.\n\nUna fuerte dependencia recaería en: `node`, `npm`, `grunt`, `cypress`, `browserify`, `qunit` o `istanbul/nyc` entre otros.\n\n\n\n\n\n\n\n\n## Implementaciones\n\nLas versiones específicas de las implementaciones de las dependencias pueden consultarse en el `package.json` de este proyecto.\n\nLas versiones específicas de las implementaciones de este proyecto pueden consultarse en su proyecto en `github`.\n\n\n\n\n\n\n\n\n\n\n\n\n\n## Ventajas\n\n*(Lista de ventajas encontradas)*\n\n\n\n\n\n\n\n\n\n\n\n## Inconvenientes\n\n*(Lista de desventajas encontradas)*\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n## Apéndice\n\n*(Otra información relacionada con la arquitectura)*\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n# Requisitos\n\n## Introducción\n\nEste documento está creado para expresamente exponer los requisitos que este software debe cumplir a los desarrolladores del proyecto.\n\n### Definiciones principales\n\nLa exposición de este documento se crea en base a 3 conceptos:\n\n1. Los **requisitos**. Lista de problemas y requisitos funcionales y de toda índole que este software deba solucionar.\n\n2. Las **soluciones**. Una lista de soluciones (*expresadas en términos no-técnicos*) para cada requisito.\n\n3. Las **implementaciones**. Una lista de implementaciones finales (*expresadas en términos técnicos*) para cada solución.\n\nUna **implementación** es la *materialización de una solución, que intenta resolver un requisito*.\n\nUna **solución** es una *propuesta (no detallada técnicamente) de software para satisfacer un requisito*.\n\nUn **requisito** es una *demanda de software definida abstractamente*.\n\n### Definiciones secundarias\n\nCada **requisito** tiene una **solución final** para él.\n\nCada **solución** tiene una **implementación final** para ella.\n\nCada **implementación** tiene una **`feature`**.\n\nCada **`feature`** tiene una **rama o `branch`**.\n\nCada **rama o `branch`** puede tener una o muchas **`features`**.\n\n*Nota: como más conciso, explícito, específico y detallado se redacten estos puntos, menos se sorprenderán después.*\n\n\n\n\n## Requisitos\n\n*Rellenar con los requisitos por puntos y subpuntos*\n\n- [ ] [1] Requisito 1\n   - [ ] [1.1] Requisito 1.1\n   - [ ] [1.2] Requisito 1.2\n   - [ ] [1.3] Requisito 1.3\n- [ ] [2] Requisito 2\n   - [ ] [2.1] Requisito 2.1\n   - [ ] [2.2] Requisito 2.2\n   - [ ] [2.3] Requisito 2.3\n- [ ] [3] Requisito 3\n   - [ ] [3.1] Requisito 3.1\n   - [ ] [3.2] Requisito 3.2\n   - [ ] [3.3] Requisito 3.3\n\n\n\n\n## Soluciones\n\n*Exponer un listado equivalente a los requisitos, pero con una solución (en términos no-técnicos) en lugar de una descripción.*\n\n*Las soluciones se incorporan a medida que se vayan definiendo, simplemente por ID.*\n\n- [ ] [1] Requisito 1\n- [ ] [1.1] Requisito 1.1\n- [ ] [1.2] Requisito 1.2\n- [ ] [1.3] Requisito 1.3\n- [ ] [2] Requisito 2\n- [ ] [2.1] Requisito 2.1\n- [ ] [2.2] Requisito 2.2\n- [ ] [2.3] Requisito 2.3\n- [ ] [3] Requisito 3\n- [ ] [3.1] Requisito 3.1\n- [ ] [3.2] Requisito 3.2\n- [ ] [3.3] Requisito 3.3\n\n\n\n\n## Implementations\n\n*Exponer un listado equivalente a las soluciones, pero con una referencia de la feature que implementa esta solución.*\n\n*Las implementaciones se incorporan a medida que se vayan definiendo, simplemente por ID.*\n\n- [ ] [1] Requisito 1\n- [ ] [1.1] Requisito 1.1\n- [ ] [1.2] Requisito 1.2\n- [ ] [1.3] Requisito 1.3\n- [ ] [2] Requisito 2\n- [ ] [2.1] Requisito 2.1\n- [ ] [2.2] Requisito 2.2\n- [ ] [2.3] Requisito 2.3\n- [ ] [3] Requisito 3\n- [ ] [3.1] Requisito 3.1\n- [ ] [3.2] Requisito 3.2\n- [ ] [3.3] Requisito 3.3\n\n\n\n\n## Temporizaciones\n\n*Exponer un listado equivalente a las implementaciones, pero con una estimación de la duración o plazo de cada implementación.*\n\n***Importante:** las temporizaciones deberían estar definidas antes del desarrollo.*\n\n- [ ] [1] Requisito 1\n- [ ] [1.1] Requisito 1.1\n- [ ] [1.2] Requisito 1.2\n- [ ] [1.3] Requisito 1.3\n- [ ] [2] Requisito 2\n- [ ] [2.1] Requisito 2.1\n- [ ] [2.2] Requisito 2.2\n- [ ] [2.3] Requisito 2.3\n- [ ] [3] Requisito 3\n- [ ] [3.1] Requisito 3.1\n- [ ] [3.2] Requisito 3.2\n- [ ] [3.3] Requisito 3.3\n\n\n\n\n\n\n\n\n# Flujos de trabajo\n\n## Flujos de trabajo en proyectos `reactivist`\n\nEn aras de hacer un desarrollo productivo y confiable, los proyectos `reactivist` definen ya un `flujo de trabajo de desarrollo de una feature` como referencia de buenas prácticas.\n\n#### El flujo de trabajo del desarrollo de una `feature`\n\nToda `feature` tiene este flujo de estados:\n\n- **`Plenamente requerida`**\n- **`Plenamente abierta`**\n- **`Plenamente definida al usuario`**\n- **`Plenamente definida al desarrollador`**\n- **`Plenamente aceptada`**\n- **`Plenamente documentada`**\n- **`Plenamente subida`**\n- **`Plenamente integrada`**\n- **`Plenamente cerrada`**\n\nPuedes echar un vistazo general al flujo de trabajo aquí:\n\n- Define el requerimiento.\n- Abre una `feature`\n- Define un test de usuario basado en los requerimientos\n- Define un test unitario basado en la codificación y conducta esperadas\n- Desarrolla hasta pasar el test unitario y de usuario\n- Documenta la `feature`\n- Une la `feature` a la branca origen\n- Cierra la `feature`\n\n#### El trabajo inicial del arquitecto\n\nAntes de poder desarrollar, el arquitecto tiene aquí las siguientes tareas asignadas:\n\n- Rellenar la documentación de:\n   - `docs/general/*.md`. El inicio del `README.md` inicial. Este es normalmente el último de todos.\n   - `docs/architecture/*.md`. Estos documentos se rellenan parcialmente con el cliente para que pueda expresar sus demandas, parcialmente con documentación técnica para otros arquitectos.\n   - `docs/requirements/*.md`. Estos documentos duplican a los anteriores a medida que se va definiendo más y más el desarrollo, así que crece más que el anterior. Está expresamente pensado para que el arquitecto exponga los requisitos que entiende que el software necesita desde los requisitos que el cliente ha creído convenientes y los que él aporta en la implementación añadidamente, como la potencial reusabilidad de los componentes requeridos, o dependencias concretas que pueden ayudar o condicionar el desarrollo, pero que al ir más ligado al presente de las tecnologías se deja en el equipo de desarrollo.\n   - `docs/workflows/*.md|*.mmd|*.png`. En este directorio se generan diagramas con `mermaid`, un lenguaje y herramienta para generar diagramas. El arquitecto debería definir todos los diagramas de flujo convenientes aquí para que los desarrolladores puedan comprender rápidamente las ideas que se quieren o se están llevando a cabo. También para otros arquitectos, o incluso para el cliente.\n   - `test/e2e/*.js`. De los comentarios `javadoc` se extrae la documentación de los tests de usuario. Cuantos más comentarios definiendo en qué consiste cada `user test` deje escritos el arquitecto, menos problemas deberían aflorar posteriormente.\n   - `test/unit/*.js`. De los comentarios `javadoc` se extrae la documentación de los tests de usuario. Cuantos más comentarios definiendo en qué consiste cada `unit test` deje escritos el arquitecto, menos problemas deberían aflorar posteriormente.\n   - `src/*.jsx`. De los comentarios `javadoc` se extrae la documentación de la referencia de la API. Cuantos más comentarios definiendo en qué consiste cada clase, método, función, variable, o en general, de fragmento de código, más referencia se tendrá después en la documentación.\n   - `src/*.scss`. De los comentarios `javadoc` se extrae la documentación de la referencia de la API. Cuantos más comentarios definiendo en qué consiste cada clase, método, función, variable, o en general, de fragmento de código, más referencia se tendrá después en la documentación.\n\n#### Los 20 pasos recomendados en el flujo de trabajo del desarrollo de una `feature`\n\n##### Leyenda de la guía de 20 pasos\n\n**[C]** significa **Línea de comandos**.\n\n**[E]** significa **Editor**.\n\n**[R]** significa **Repositorio**.\n\n##### Configuración inicial del entorno\n\n- **[C]** | Crea un nuevo proyecto `reactivist` | `reactivist -f {folder}`.\n\n- **[R]** | Inicializa el proyecto en el repositorio y en el directorio.\n\n- **[R]** | Cámbiate a la branca principal del nuevo proyecto.\n\n##### Flujo de trabajo de 20 pasos de los proyectos `reactivist`\n\n- 1. [ ] **[E]** Añade y toma un requerimiento. `docs/requirements/*.md`\n\n- 2. [ ] **[E]** Añade y toma un cambio del `CHANGELOG.md`. Debe resolver el requerimiento anterior.\n\u003e La `feature` está aquí `PLENAMENTE REQUERIDA`.\n\n- 3. [ ] **[C]** Comprueba que los tests pasan y sube los cambios al repositorio. En caso contrario, resuélvelos, y súbelo.\n\n- 4. [ ] **[C]** Crea una nueva branca y llámala `feature-{ID del requerimiento}`. Cámbiate a la nueva branca.\n\u003e La `feature` está aquí `PLENAMENTE ABIERTA`.\n\n- 5. [ ] **[C]** Iniciar **modo desarrollo** con los comandos apropiados. Por defecto: `grunt serve` y `grunt watch` paralelamente.\n\n- 6. [ ] **[E]** Desarrolla el test de usuario necesario para demostrar el requerimiento anterior.\n\u003e La `feature` está aquí `PLENAMENTE DEFINIDA AL USUARIO`.\n\n- 7. [ ] **[E]** Desarrolla el test unitario para confirmar la codificación y las entradas/salidas/conductas de la implementación.\n\u003e La `feature` está aquí `PLENAMENTE DEFINIDA AL DESARROLLADOR`.\n\n- 8. [ ] **[C]** Haz los tests de usuario y unitarios fallar.\n\n- 9. [ ] **[E]** Desarrolla el código fuente para que pase los tests de usuario y unitario. \n\n- 10. [ ] **[C]** Pásalos satisfactoriamente. Por defecto: `grunt e2e` y `grunt unit`.\n\n- 10. [ ] **[E]** Añade la `feature` en el `CHANGELOG.md`. Las acciones recomendadas son:\n  - `Added`\n  - `Changed`\n  - `Deprecated`\n  - `Removed`\n  - `Fixed`\n\n- 11. [ ] **[R]** Sube los cambios.\n\u003e La `feature` está aquí `PLENAMENTE ACEPTADA`.\n\n- 12. [ ] **[E]** Documenta (en el código fuente, el del test de usuario y el del test unitario) la `feature`.\n\n- 13. [ ] **[C]** Genera documentación las veces necesarias.\n\n- 14. [ ] **[E]** Añade la `feature` de documentación en el `CHANGELOG.md`.\n\u003e La `feature` está aquí `PLENAMENTE DOCUMENTADA`.\n\n- 15. [ ] **[R]** Sube los cambios.\n\u003e La `feature` está aquí `PLENAMENTE SUBIDA`.\n\n- 16. [ ] **[R]** Unifica la branca de la `feature` con la branca `master` (un `merge`).\n\u003e La `feature` está aquí `PLENAMENTE UNIFICADA`.\n\n- 17. [ ] **[R]** Cámbiate a la branca `master`\n\n- 18. [ ] **[C]** Haz pasar todos los tests a la branca unificada resultante.\n   - Si los tests son pasados: continúa al siguiente punto.\n   - Si los tests no son pasados:\n      - Intenta pasarlos.\n      - Alternativamente: duplica la `feature` por ahora, y haz rollback en la feature actual.\n\u003e La `feature` aquí está `PLENAMENTE INTEGRADA`.\n\n- 19. [ ] **[R]** Cerrar branca.\n\u003e La `feature` está aquí `PLENAMENTE CERRADA`.\n\n- 20. [ ] **[-]** Tómate un descanso, respira y estira el cuerpo un poco. Lo mereces porque lo has conseguido.\n\n\n\n## Flujo de trabajo del desarrollo de una `feature`\n\nUna `feature` es una característica de la aplicación.\n\nTodo desarrollo de aplicación se hace añadiéndole `features` o características a un software de base.\n\nToda `feature` tiene su propia `branch` o rama de desarrollo (que es manejado por el control de versiones).\n\nTodo desarrollo de una `feature` sigue un ciclo normal, un flujo de trabajo o `workflow` que el desarrollador va repitiendo.\n\nA continuación se explica paso por paso este `workflow`.\n\nAdemás, se ha intentado establecer la proporción de tiempo para cada tarea (suponiendo que lo mínimo por tarea fuera un día).\n\n![Dibujo del flujo de trabajo del desarrollo de una feature](docs/workflows/workflow-temporization.mmd.png)\n\n### Sección de contrato\n\nEn la sección de contrato, se habla con el cliente (o usuario final) para establecer los requisitos del producto.\n\n#### Definición del `feature`\n\nEn este punto se define, genéricamente, el `requisito`, la `solución` y la `implementación`.\n\nEn este punto se define:\n  \n  - ¿Qué necesita proveer y/o resolver el producto (a modo específico)? `#requisitos`\n  - ¿Qué necesita cumplir al mismo tiempo (a modo específico)? `#requisitos`\n  - ¿Cómo se propone solucionarlo (a modo general)? `#soluciones`\n  - ¿Cómo se propone implementarlo (a modo general)? `#implementaciones`\n\nLos requisitos, las soluciones y las implementaciones de la aplicación se definen en `README-Requirements.md`.\n\n#### Apertura del requisito\n\nEn este punto se declara abierta esta `feature` (con su `branch` correspondiente).\n\n### Sección de diseño\n\nEn la sección de diseño, se plasma la idea completa de la solución ante el requisito o problema, y la implementación o `feature`. Sin código.\n\n#### Diseño de solución\n\nEn este punto se explica con palabras no-técnicas, en qué consiste la solución que se propone.\n\nEn este punto, simplemente, se desarrolla con palabras que cualquiera entendería:\n\n  - [ ] ¿Cómo se propone solucionar el problema?\n  - [ ] ¿Cómo soluciona esta propuesta el problema?\n\nEn este punto se define el siguiente tipo de información:\n\n  - [ ] ¿Qué debe poder hacer el usuario que interactúe con esta `feature`?\n  - [ ] ¿Qué no debe poder hacer el usuario que interactúe con esta `feature`?\n  - [ ] ¿Cómo debe responder la aplicación (y más concretamente la `feature`) ante cierta respuesta?\n  - [ ] ¿Cómo no debe responder la aplicación (y más concretamente la `feature`) ante cierta respuesta?\n  - [ ] ¿Qué debe ocurrir dada una interacción con la aplicación (que implica funcionalmente a la `feature`)?\n\nEn este punto se definen los siguientes tipos de documentos:\n\n  - [ ] Imágenes de prototipos de interfaces de usuario\n  - [ ] Imágenes de mockups de interfaces de usuario\n  - [ ] Documentación exhaustiva (a nivel de UI/UX) del requisito/solución/implementación o `feature` en `docs/requirements.md`.\n\n*En la redacción de este punto, es importante dividir (y subdividir) los contenidos, incluso asignarles tiempo a cada uno.*\n\n#### Diseño de implementación\n\nEn este punto se explica con palabras no-técnicas, en qué consiste la solución concreta (implementación) que se ha propuesto.\n\nEn este punto se desarrolla con palabras no-técnicas y programáticas que cualquiera entendería:\n\n  - [ ] ¿Qué hace la implementación?\n  - [ ] ¿Qué hace la implementación para solucionar el problema?\n\nEn este punto se definen los siguientes tipos de documentos:\n\n  - [ ] Diagramas de árbol: flujos de eventos de la aplicación.\n  - [ ] Diagramas de árbol: clases, interfaces, propiedades, métodos, objetos, funciones, parámetros de entrada, parámetros de salida.\n  - [ ] Diagramas de árbol: componentes y contenedores (e interdependencias).\n  - [ ] Diagramas de árbol: algoritmos de los flujos de datos de la API (no necesariamente un flujo de evento de la aplicación).\n  - [ ] Dibujos: componentes y contenedores.\n  - [ ] Texto internacionalizado\n  - [ ] Documentación estructural y superficial (a nivel de API) de:\n     - [ ] clases\n     - [ ] interfaces\n     - [ ] propiedades\n     - [ ] métodos\n     - [ ] objetos\n     - [ ] funciones\n     - [ ] parámetros de entrada\n     - [ ] parámetros de salida\n     - [ ] flujos de eventos de la aplicación\n     - [ ] componentes\n     - [ ] contenedores\n\n### Sección de testing\n\nEn la sección de testing se codificarán y documentarán en profundidad las especificaciones (o tests) de usuario y unitarias.\n\n#### Especificación de uso\n\nEn este punto se codifican y documentan las especificaciones (o tests) de usuario, o `user specifications`, necesarias para solventar el requisito.\n\nEn este punto se desarrolla:\n\n  - [ ] [con código] Las comprobaciones suficientes para demostrar la correcta solución (`user tests`) de la `feature`.\n  - [ ] [con comentarios] La documentación suficiente de la solución (comentarios en los `user tests`).\n  \nEn este punto se definen los siguientes tipos de documentos:\n\n  - [ ] Código de los tests de usuario demostrando:\n     - [ ] las acciones del usuario que demuestran la `feature`\n     - [ ] las reacciones de la aplicación que demuestran la `feature`\n  - [ ] Imágenes del proceso de `user test`\n  - [ ] Documentación de las especificaciones de usuario para esta `feature`.\n\n#### Especificación de unidad\n\nEn este punto se codifican y documentan las especificaciones (o tests) unitarias, o `unit specifications`, necesarias para solventar el requisito.\n\nEn este punto se desarrolla:\n\n  - [ ] [con código] Las comprobaciones suficientes para demostrar la correcta implementación (`unit tests`) de la `feature`.\n  - [ ] [con código] La documentación suficiente de la implementación (comentarios en los `unit tests`).\n\nEn este punto se definen los siguientes tipos de documentos:\n\n  - [ ] Código de los tests unitarios demostrando:\n     - [ ] la entrada y salida de datos de los métodos, funciones y clases\n     - [ ] los valores de las propiedades, los objetos\n     - [ ] el correcto trazado/flujo de los eventos\n     - [ ] el uso previsto de los componentes\n     - [ ] el uso previsto de los contenedores\n     - [ ] el reporte de cobertura de código de la `feature`.\n\nEs importante que en este punto se especifique, claramente, paso por paso (cronológicamente al desarrollo), qué debe de ser capaz de hacer la `feature`.\n\n### Sección de codificación\n\nEn esta sección se codificará la `feature`, propiamente.\n\n#### Superación de especificaciones\n\nEn este punto se codificará la `feature` de manera que pase los dos tests: los `user tests` y los `unit tests`.\n\nEs importante que en este punto:\n\n  - Se proceda paso por paso a completar las especificaciones (de usuario y unitarias) de la `feature`.\n  - Se mantenga un control constante del tiempo previsto e invertido en la `feature`.\n  - Se advierta y notifique de puntos de conflicto en el desarrollo a tiempo para revisar si hace falta la implementación y la solución.\n\n### Sección de documentación\n\nEn esta sección se documentarán exhaustivamente los cambios que la `feature` implica.\n\n#### Documentación de la `feature`\n\nEn este punto se documentarán exhaustivamente los cambios que la `feature` implica.\n\nEsta documentación quedará reflejada en los ficheros:\n\n  - `test/user/README-User-tests.md`: los (`user`) tests añadidos para demostrar la presente `feature` deben quedar explicados aquí.\n  - `test/unit/README-Unit-tests.md`: los (`unit`) tests añadidos para demostrar la presente `feature` deben quedar explicados aquí.\n  - `README-Feature.md`: la `feature` en su totalidad (`requirement`, `solution` e `implementation`) debe quedar explicada en este documento al finalizar el desarrollo de la branch.\n  - `src/*.jsx` y `src/*.scss`: la `feature` debe quedar documentada a nivel programático en los comentarios de nuestro código fuente.\n\n### Sección de integración\n\nEn esta sección se integrará la `feature` con la branca madre.\n\n#### Subir la `feature`\n\nEn este punto subiremos el código de nuestra `feature` al repositorio externo usando un software de control de versiones.\n\n#### Mezclar branca\n\nEn este punto se resuelven los `merge conflicts` que pudieran haber al mezclar el nuevo código con el actual.\n\n#### Cerrar branca\n\nEn este punto se cierra y elimina la branca, y pasa a considerarse como `feature` finalizada.\n\n\n# Temporización del proceso de desarrollo de una `feature`\n\n1 día:  Definición del `feature` (3% -- toma 02:30 minutos de 1 hora aproximadamente)\n\n1 día:  Apertura del requisito (3% -- toma 02:30 minutos de 1 hora aproximadamente)\n\n4 días: Diseño de solución (15% -- toma 09:00 minutos de 1 hora aproximadamente)\n\n4 días: Diseño de implementación (15% -- toma 09:00 minutos de 1 hora aproximadamente)\n\n2 días: Especificación de uso (7% -- toma 04:30 minutos de 1 hora aproximadamente)\n\n2 días: Especificación de unidad (7% -- toma 04:30 minutos de 1 hora aproximadamente)\n\n6 días: Superación de especificaciones (22% -- toma 15:00 minutos de 1 hora aproximadamente)\n\n3 días: Documentación de la `feature` (11% -- toma 07:30 minutos de 1 hora aproximadamente)\n\n1 día:  Subir la `feature` (3% -- toma 02:30 minutos de 1 hora aproximadamente)\n\n2 días: Mezclar branca (7% -- toma 04:30 minutos de 1 hora aproximadamente)\n\n1 día:  Cerrar branca (3% -- toma 02:30 minutos de 1 hora aproximadamente)\n\n\n\n\n\n\n\n\n\n\n \n\n\n# Referencia de la API\n\n---\n\n\n\n\n \n\n\n\n\n\n\n\n \n\n\n\n\n\n\n\n \n\n\n\n\n\n\n\n \n\n\n### `Application`\n\n\n**Definition:** `Application`\n\n**Type:** `{React.Component}`\n\n**Description:** This component renders the whole application.\n\n\n\n\n\n\n\n\n\n\n \n\n\n# Tests de usuario\n\n\n----\n\n**Dado...**\n\n - Un contexto\n - Unas acciones de usuario (unos estados)\n - Una parte de la UI\n\n**Cuando...**\n\n - Una acción de usuario\n\n**Espera...**\n\n - Una reacción en la UI\n\n----\n\n\n\n\n \n\n\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n\n \n\n\n# Tests unitarios\n\n\n----\n\n**Dado...**\n\n - Un contexto\n - Unos estados\n - Una función\n\n**Cuando...**\n\n - Un input\n\n**Espera...**\n\n - Un output\n - Un estado\n\n----\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n----\n\n## Comandos\n\nLos ficheros `gruntfile.js` y `dev/grunt:*.js` son los encargados de hacer funcionar los comandos de `Reactivist`.\n\nPara crear tu propio comando, crea un nuevo fichero `dev/grunt:\u003c%comando%\u003e.js` tomando como plantilla a `dev/grunt:0.js`.\n\nA continuación se listan los comandos que `Reactivist` proporciona por defecto.\n\n\n\n\n\n \n\n\n----\n\n### `grunt build`\n\n**Subtareas:** \n\n- `clean`\n- `build:lock`\n- `i18n`\n- `sass`\n- `pack`\n- `docs`\n- `build:unlock`\n- `dist`\n\n**Descripción:** Limpia, inernacionaliza, estiliza, empaqueta, documenta y distribuye el código fuente.\n\n\n\n\n \n\n\n----\n\n### `grunt build:lock`\n\n**Descripción:** Modifica el fichero `grunt:build.json` para que indique que el proceso `grunt build` está siendo ejecutado. No es una tarea pensada para el usuario, sino para otras tareas.\n\n\n\n\n \n\n\n----\n\n### `grunt build:unlock`\n\n**Descripción:** Modifica el fichero `grunt:build.json` para que indique que el proceso `grunt build` no está siendo ejecutado. No es una tarea pensada para el usuario, sino para otras tareas.\n\n\n\n\n \n\n\n----\n\n### `grunt clean`\n\n**Parámetros:** `settings.grunt.clean.{env}.files`\n\n**Descripción:** Limpia el proyecto en función de los parámetros.\n\n\n\n\n \n\n\n----\n\n### `grunt component`\n\n**Parámetros:** \n\n- `-f | --folder`: opcional.\n- `-n | --name`: opcional.\n- `-p | --package`: opcional.\n\n**Descripción:** Crea un nuevo componente en `src/components/{componente}` como un nuevo `Proyecto Reactivist` dentro del proyecto.\n\n\n\n\n \n\n\n----\n\n### `grunt default`\n\n**Descripción:** Imprime una explicación de cómo iniciar el modo desarrollo.\n\n\n\n\n \n\n\n----\n\n### `grunt diagrams`\n\n**Parámetros:** `settings.grunt.diagrams.{env}.files`\n\n**Descripción:** Genera imágenes de los ficheros `mmd` (Mermaid) en función de los parámetros.\n\n\n\n\n \n\n\n----\n\n### `grunt dist`\n\n**Parámetros:** `settings.grunt.dist.{env}.files`, `settings.grunt.dist.{env}.options`\n\n**Descripción:** Genera imágenes de los ficheros `mmd` (Mermaid) en función de los parámetros.\n\n\n\n\n \n\n\n----\n\n### `grunt docs`\n\n**Subtareas:** \n\n- `javadoc`\n- `diagrams`\n\n\n\n\n \n\n\n----\n\n### `grunt e2e`\n\n**Parámetros:** `cypress.json`\n\n**Descripción:** Inicia los tests de [Cypress](https://docs.cypress.io/api/api/table-of-contents.html). \n\n\n\n\n \n\n\n----\n\n### `grunt env`\n\n**Parámetros:** `-e` / `--environment`. `{String}`.\n\n**Descripción:** Establece el entorno. Ejemplo: `grunt env -e=test`, `grunt env --environment=production`...\n\n\n\n\n \n\n\n----\n\n### `grunt export:mobile`\n\n**Parámetros:** `package.json`, `settings.grunt.export:mobile.{env}.package`, `settings.grunt.export:mobile.{env}.title`.\n\n**Descripción:** Genera una aplicación móvil con `Cordova` del proyecto en `dist-mobile`.\n\n\n\n\n \n\n\n----\n\n### `grunt export:pc`\n\n**Parámetros:** `package.json`\n\n**Descripción:** Genera una aplicación de escritorio con `Electron` del proyecto en `dist-pc`.\n\n\n\n\n \n\n\n----\n\n### `grunt i18n`\n\n**Parámetros:** `settings.grunt.i18n.{env}.files`, `settings.grunt.i18n.{env}.outFile`, `settings.grunt.i18n.{env}.options`.\n\n**Descripción:** Genera un fichero de tipo JSON a partir de los ficheros de traducción de `i18n/*.po` en `i18n/i18n.json`.\n\n\n\n\n \n\n\n----\n\n### `grunt imports`\n\n**Parámetros:** `settings.grunt.imports.{env}.files`\n\n**Descripción:** Importa los ficheros especificados como clave (URLs o ficheros) a los ficheros especificados como valor del mapa `settings.grunt.imports.{env}.files`.\n\n\n\n\n \n\n\n----\n\n### `grunt javadoc`\n\n**Parámetros:** `settings.grunt.docs.{env}.options`\n\n**Descripción:** Genera la documentación, en formato `json` o `markdown`, de los comentarios tipo Javadoc de los ficheros especificados. Se pueden especificar una lista de configuraciones, y generará un fichero distinto cada vez.\n\n\n\n\n \n\n\n----\n\n### `grunt pack`\n\n**Parámetros:** `settings.grunt.pack.{env}.*`, `settings.grunt.unit.{env}.*`\n\n**Descripción:** Transpila los ficheros desde `src/index.jsx` y genera el `src/bundle.js`. En entorno `\"test\"`, también genera el `unit/test/dist/bundle.test.js` a partir de `unit/test/src/index.jsx`.\n\n\n\n\n \n\n\n----\n\n### `grunt sass`\n\n**Parámetros:** `settings.grunt.sass.{env}.*`, `settings.grunt.unit.{env}.*`\n\n**Descripción:** Transpila los ficheros desde `src/index.scss` y genera el `src/bundle.css`. En entorno `\"test\"`, también genera el `unit/test/dist/bundle.test.css` a partir de `unit/test/src/index.scss`.\n\n\n\n\n \n\n\n----\n\n### `grunt scraps`\n\n**Parámetros:**\n\n**Descripción:** Ejecuta los scripts bajo `scraps/scripts/*.js` en orden natural con Electron, y el módulo `web2os` disponible.\n\nEste comando está pensado para ciertos contextos en los que puede ser importante extraer información de otras páginas web en vivo mediante un navegador.\n\nConsultar ejemplos y API oficial de `web2os` para saber más sobre esta opción.\n\n\n\n\n \n\n\n----\n\n### `grunt serve`\n\n**Parámetros:** -\n\n**Descripción:** Sirve los ficheros `dist` estáticamente bajo `http://{host}:{port}/public`, donde `{host}` y `{port}` son extraídos de `{settings.json#.grunt.serve.{env}.host}` y `{settings.json#.grunt.serve.{env}.port}`, respectivamente.\n\n\n\n\n \n\n\n----\n\n### `grunt test`\n\n**Subtareas:** \n\n- `unit`\n- `e2e`\n\n**Descripción:** Arranca los tests unitarios y luego los tests de usuario.\n\n\n\n\n \n\n\n----\n\n### `grunt unit`\n\n**Descripción:** Arranca los tests unitarios.\n\n\n\n\n \n\n\n----\n\n### `grunt watch`\n\n**Parámetros:** `grunt.watch.{env}.*`\n\n**Descripción:** Establece escucha de ficheros. Al detectar cambios, ejecutará `grunt build`.\n\n\n\n\n\n\n\n# Changelog\n\n## Introducción\n\nTodos los cambios a este proyecto serán documentados en este fichero.\n\nEl formato está basado en [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).\n\nEste proyecto se adhiere a la especificación de [Semantic Versioning](https://semver.org/spec/v2.0.0.html) también.\n\nAcciones: **Added | Changed | Deprecated | Removed | Fixed | Security**\n\n# Enlaces\n\n[Por liberar]: [.](#)\n[0.0.1]: [](#)\n\n# Changes\n\n## Por liberar - hoy\n\n### Changed\n\n- Iniciar y subir proyecto semilla.\n\n### Added\n\n- `feature-1`. Título de la `feature`.\n   - Especificar.\n   - Diseñar.\n   - Testear. \n   - Desarrollar.\n   - Documentar.\n   - Subir.\n   - Mezclar.\n\n### Added\n\n- `feature-2`. Título de la `feature`.\n   - Especificar. \n   - Diseñar.\n   - Testear. \n   - Desarrollar.\n   - Documentar.\n   - Subir.\n   - Mezclar.\n\n## 0.0.1 - 01/01/2019\n\n## 0.1.0 - 01/01/2019\n\n## 1.0.0 - 01/01/2019\n\n\n\n\n\n\n## Licencia\n\nMIT License\n\nCopyright (c) 2019, Reactivist.\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n\n\n# Read this file\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fallnulled%2Freactivist","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fallnulled%2Freactivist","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fallnulled%2Freactivist/lists"}