Avance: Data pareja1

[jllanosg]

Descripción

Agrega los avances para la sección data de la app.

En específico, agrega las siguientes funcionalidades:

• CRUD Collaborators (sin arreglar todos los warns/errors de ESLint)
• CRUD Companies (sin arreglar todos los warns/errors de ESLint)
• CRUD Clients
• CRUD Templates (sin arreglar todos los warns/errors de ESLint)

El arreglo de estos queda pendiente, se hace este PR para tener una aproximación al resultado final, con el fin de poder mostrar resultados en el sprint review 1. La corección de los errores del linter quedó registrada en el issue #52.

Motivación y Contexto

Migración de frontend.

¿Cómo ha sido probado?

• Agregando, editando y eliminando los elementos descritos.
• Corriendo $ npm run build

Capturas de pantalla (si es apropiado):

Tipos de cambios

• [ ] Bugfix (cambio que no interrumpe el funcionamiento y que soluciona un problema)
• [x] New feature (cambio que no interrumpe el funcionamiento y que añade funcionalidad)
• [ ] Breaking change (corrección o funcionalidad que podría causar que la funcionalidad existente cambie)

Lista de verificación:

• [x] Mi código sigue el estilo de código de este proyecto.
• [ ] Mi cambio requiere una modificación en la documentación.
• [ ] He actualizado la documentación en consecuencia.

[caverav]

Por qué no borrar la rama al mergear? Si hay que agregar una feature o fixear algo se hace una rama feature/ o bugfix/, o hay alguna razón para no seguir ese estándar?

[jllanosg]

Por qué no borrar la rama al mergear? Si hay que agregar una feature o fixear algo se hace una rama feature/ o bugfix/, o hay alguna razón para no seguir ese estándar?

Por lo que hablamos el otro dia (pushear estos cambios parcialmente para tenerlos juntos y poder mostrarlos); se seguirá trabajando en data-pareja1 para eliminar los problemas de eslint, y por otro lado la rama custom-data que está en un estado muy prematuro sigue a data-pareja1

[caverav]

Por qué no borrar la rama al mergear? Si hay que agregar una feature o fixear algo se hace una rama feature/ o bugfix/, o hay alguna razón para no seguir ese estándar?

Por lo que hablamos el otro dia (pushear estos cambios parcialmente para tenerlos juntos y poder mostrarlos); se seguirá trabajando en data-pareja1 para eliminar los problemas de eslint, y por otro lado la rama custom-data que está en un estado muy prematuro sigue a data-pareja1

Justamente el solucionar problemas de ESLint puede ir en una nueva rama, al igual que la feature de custom-data, es una forma de organizar las cosas, así además se puede hacer PR de una si ya está lista, y no tener que incluir cambios de la otra rama que tal vez ni estén completos

[jllanosg]

Por qué no borrar la rama al mergear? Si hay que agregar una feature o fixear algo se hace una rama feature/ o bugfix/, o hay alguna razón para no seguir ese estándar?

Por lo que hablamos el otro dia (pushear estos cambios parcialmente para tenerlos juntos y poder mostrarlos); se seguirá trabajando en data-pareja1 para eliminar los problemas de eslint, y por otro lado la rama custom-data que está en un estado muy prematuro sigue a data-pareja1

Justamente el solucionar problemas de ESLint puede ir en una nueva rama, al igual que la feature de custom-data, es una forma de organizar las cosas, así además se puede hacer PR de una si ya está lista, y no tener que incluir cambios de la otra rama que tal vez ni estén completos

Estoy de acuerdo en lo primero, pero el tema de custom data es que ya tiene avances hechos, esta rama sale de data-pareja1 entonces no se qué pasaría con la misma si se borra la de origen

[caverav]

Por qué no borrar la rama al mergear? Si hay que agregar una feature o fixear algo se hace una rama feature/ o bugfix/, o hay alguna razón para no seguir ese estándar?

Por lo que hablamos el otro dia (pushear estos cambios parcialmente para tenerlos juntos y poder mostrarlos); se seguirá trabajando en data-pareja1 para eliminar los problemas de eslint, y por otro lado la rama custom-data que está en un estado muy prematuro sigue a data-pareja1

Justamente el solucionar problemas de ESLint puede ir en una nueva rama, al igual que la feature de custom-data, es una forma de organizar las cosas, así además se puede hacer PR de una si ya está lista, y no tener que incluir cambios de la otra rama que tal vez ni estén completos

Estoy de acuerdo en lo primero, pero el tema de custom data es que ya tiene avances hechos, esta rama sale de data-pareja1 entonces no se qué pasaría con la misma si se borra la de origen

Si tiene cambios hechos, entonces al mergear se mergearán esos cambios, por ende no se perderán, y al hacer una nueva rama desde development, estarán esos cambios

[jllanosg]

Por qué no borrar la rama al mergear? Si hay que agregar una feature o fixear algo se hace una rama feature/ o bugfix/, o hay alguna razón para no seguir ese estándar?

Por lo que hablamos el otro dia (pushear estos cambios parcialmente para tenerlos juntos y poder mostrarlos); se seguirá trabajando en data-pareja1 para eliminar los problemas de eslint, y por otro lado la rama custom-data que está en un estado muy prematuro sigue a data-pareja1

Justamente el solucionar problemas de ESLint puede ir en una nueva rama, al igual que la feature de custom-data, es una forma de organizar las cosas, así además se puede hacer PR de una si ya está lista, y no tener que incluir cambios de la otra rama que tal vez ni estén completos

Estoy de acuerdo en lo primero, pero el tema de custom data es que ya tiene avances hechos, esta rama sale de data-pareja1 entonces no se qué pasaría con la misma si se borra la de origen

Si tiene cambios hechos, entonces al mergear se mergearán esos cambios, por ende no se perderán, y al hacer una nueva rama desde development, estarán esos cambios

Los cambios no están en data-pareja1, solo en data-pareja1-custom-data. Sugieres que mergee primero data-pareja1-custom-data hacia data-pareja1?

[caverav]

Por qué no borrar la rama al mergear? Si hay que agregar una feature o fixear algo se hace una rama feature/ o bugfix/, o hay alguna razón para no seguir ese estándar?

Por lo que hablamos el otro dia (pushear estos cambios parcialmente para tenerlos juntos y poder mostrarlos); se seguirá trabajando en data-pareja1 para eliminar los problemas de eslint, y por otro lado la rama custom-data que está en un estado muy prematuro sigue a data-pareja1

Justamente el solucionar problemas de ESLint puede ir en una nueva rama, al igual que la feature de custom-data, es una forma de organizar las cosas, así además se puede hacer PR de una si ya está lista, y no tener que incluir cambios de la otra rama que tal vez ni estén completos

Estoy de acuerdo en lo primero, pero el tema de custom data es que ya tiene avances hechos, esta rama sale de data-pareja1 entonces no se qué pasaría con la misma si se borra la de origen

Si tiene cambios hechos, entonces al mergear se mergearán esos cambios, por ende no se perderán, y al hacer una nueva rama desde development, estarán esos cambios

Los cambios no están en data-pareja1, solo en data-pareja1-custom-data. Sugieres que mergee primero data-pareja1-custom-data hacia data-pareja1?

Entonces ya está la nueva rama pues, para qué quieres data-pareja1?

[jllanosg]

Por qué no borrar la rama al mergear? Si hay que agregar una feature o fixear algo se hace una rama feature/ o bugfix/, o hay alguna razón para no seguir ese estándar?

Por lo que hablamos el otro dia (pushear estos cambios parcialmente para tenerlos juntos y poder mostrarlos); se seguirá trabajando en data-pareja1 para eliminar los problemas de eslint, y por otro lado la rama custom-data que está en un estado muy prematuro sigue a data-pareja1

Justamente el solucionar problemas de ESLint puede ir en una nueva rama, al igual que la feature de custom-data, es una forma de organizar las cosas, así además se puede hacer PR de una si ya está lista, y no tener que incluir cambios de la otra rama que tal vez ni estén completos

Estoy de acuerdo en lo primero, pero el tema de custom data es que ya tiene avances hechos, esta rama sale de data-pareja1 entonces no se qué pasaría con la misma si se borra la de origen

Si tiene cambios hechos, entonces al mergear se mergearán esos cambios, por ende no se perderán, y al hacer una nueva rama desde development, estarán esos cambios

Los cambios no están en data-pareja1, solo en data-pareja1-custom-data. Sugieres que mergee primero data-pareja1-custom-data hacia data-pareja1?

Entonces ya está la nueva rama pues, para qué quieres data-pareja1?

Nono, me expliqué mal, quiero decir que data-pareja1 se puede borrar pero no sé que pasaría con data-pareja-1-custom-data, simplemente queda en mergearla a dev?

[caverav]

Yep