Remove next groups api

[marcegodoy]

What && Why

• remove next groups api.
• move all methods realted to groups to group service.
• added options parameter where we can pass individual options to calls such as asJSON and handleNotOk, we should stop using this on future calls.

Disclaimers / Extra Comments

Please test it!!

Links

• [FE] Endpoints Groups

How to Review

• Review commit by commit recommended.
• Review all at once recommended.

[marcegodoy]

@Mr-T-Smyth Para mantener compatibilidad inclui este parametro dado que en diferentes partes del codigo aveces pasamos disintos valores de estos parametros para el mismo endpoint.

Lo hice asi para no hacer tanto cambio, y fue solo necesario en este servicio por ahora, no en el de subject, lo bueno seria evitar usar esos parametros en el futuro pero esto asi evita tener que hacer mas cambios de los necesarios.

[Mr-T-Smyth]

Buen laburo! Un par de cosas:

1. Por lo que veo hay dos metodos el de getById y getAll que no usan lo parametros opcionales, por lo que no veo que se necesario.
2. El resto de metodos todos tienen asJSON en false, asique creo que prefiero que hagas al final como hablaste de que siempre devuelva la response y que esta sea parseada en el Service correspondiente
3. El tema de handleNotOK no me termina de convencer como quedo cuando lo hice y creo que seria mejor de la siguiente manera: Que siempre los noOK se atajen en el commonFetch y que tire una excepcion nuestra tipo (por dar un nombre) CommonFetchError() y que adentro tenga los errores tirados por backend si hay asi en el componente todos los errores los manejamos en un try catch y no como ahora en un hibrido de que alguna si y otras no.
   El punto 3 capaz que mejor no hacerlo en este pr pero capaz que si en un pr particular

[santimintegui]

Buen laburo! Un par de cosas:

1. Por lo que veo hay dos metodos el de getById y getAll que no usan lo parametros opcionales, por lo que no veo que se necesario.
2. El resto de metodos todos tienen asJSON en false, asique creo que prefiero que hagas al final como hablaste de que siempre devuelva la response y que esta sea parseada en el Service correspondiente
3. El tema de handleNotOK no me termina de convencer como quedo cuando lo hice y creo que seria mejor de la siguiente manera: Que siempre los noOK se atajen en el commonFetch y que tire una excepcion nuestra tipo (por dar un nombre) CommonFetchError() y que adentro tenga los errores tirados por backend si hay asi en el componente todos los errores los manejamos en un try catch y no como ahora en un hibrido de que alguna si y otras no.
   El punto 3 capaz que mejor no hacerlo en este pr pero capaz que si en un pr particular

@Mr-T-Smyth con esto estoy de acuerdo, yo dejaria que devuelva el json siempre y dsp cada componente muestra los mensajes de error como quiera( como mencionas en el punto 2 ). El unico problema que veo de cambiarlo ahora es que tendriamos que cambiarlo cuidadosamente de no romper todo, no seria mas facil cambiarlo cuando este separado todo en servicios? capas me estoy equivocando y cambiarlo ahora no es tanto trabajo pero no revise bien el codigo

[Mr-T-Smyth]

Buen laburo! Un par de cosas:

1. Por lo que veo hay dos metodos el de getById y getAll que no usan lo parametros opcionales, por lo que no veo que se necesario.
2. El resto de metodos todos tienen asJSON en false, asique creo que prefiero que hagas al final como hablaste de que siempre devuelva la response y que esta sea parseada en el Service correspondiente
3. El tema de handleNotOK no me termina de convencer como quedo cuando lo hice y creo que seria mejor de la siguiente manera: Que siempre los noOK se atajen en el commonFetch y que tire una excepcion nuestra tipo (por dar un nombre) CommonFetchError() y que adentro tenga los errores tirados por backend si hay asi en el componente todos los errores los manejamos en un try catch y no como ahora en un hibrido de que alguna si y otras no.
   El punto 3 capaz que mejor no hacerlo en este pr pero capaz que si en un pr particular

@Mr-T-Smyth con esto estoy de acuerdo, yo dejaria que devuelva el json siempre y dsp cada componente muestra los mensajes de error como quiera( como mencionas en el punto 2 ). El unico problema que veo de cambiarlo ahora es que tendriamos que cambiarlo cuidadosamente de no romper todo, no seria mas facil cambiarlo cuando este separado todo en servicios? capas me estoy equivocando y cambiarlo ahora no es tanto trabajo pero no revise bien el codigo

Si, tenes razón y es como esta siendo encarado al final, en una rama aparte empece el refactor de lo que seria el punto 2 y 3 juntos pero para ser mergeado despues de terminar el resto