Falta de soporte para pruebas

pablo-co commented 8 years ago

En openpay-data no hay getters ni setters públicos para cambiar el host al que se hacen los requests. Esto hace imposible escribir pruebas de integración con un fake, por lo que las pruebas hacen los requests directo al API de Openpay.

Esto es lento y claramente no ideal.

El punto seria poder hace algo así:

OpenpayDeviceData.sandboxHostname = "fake_address";

---
OpenpayDeviceData.setSandboxHostname("fake_address");

pablo-co commented 8 years ago

Hay un problema similar en openpay.v1.js.

_openpay.hostname = "https://api.openpay.mx/v1/",
_openpay.sandboxHostname = "https://sandbox-api.openpay.mx/v1/",
_openpay.developHostname = "https://dev-api.openpay.mx/v1/",

El hostname debería constar de solo la primera parte de la url, es decir, el dominio y protocolo. De lo contrario hace un poco incomodo hacer pruebas con fakes. Ya que solo me interesa hacer el override del host al que se hacen los requests, esto sin incluir el path local.

_openpay.hostname = "https://api.openpay.mx",
_openpay.sandboxHostname = "https://sandbox-api.openpay.mx",
_openpay.developHostname = "https://dev-api.openpay.mx",

m1slash commented 8 years ago

Que tal Pablo, intencionalmente esta un poco cerrado el apartado de los endpoints, debido a que nos ha pasado que al momento de intentar hacer el switch a producción, se tiene incorrecto el ambiente del api al cual apunta el implementador, poniendo los setters que comentas se amplia más ese riesgo (el cuál se traduce a llamadas a soporte técnico), para las pruebas que comentas, bastaría con descargar el js, modificarle dichas rutas y hacer referencia al js modificado. Saludos.

pablo-co commented 8 years ago

Entiendo un poco el razonamiento pero alguien que este usando esos setters y getters es porque se metió a ver el código de la librería. Por consiguiente se puede asumir que sabe lo que esta haciendo. Dudo que por error alguien use esas funciones si no están documentadas en ningún lado como es el caso de estos setters y getters en openpay.v1.js. Se que están ahí porque me metí a ver si existían.

Creo también no sería ideal bajar los JS y modificarlos, se significa que cualquier cambio o bugfix que ustedes hagan a la librería no van a estar presentes en mi versión local (y dudo que alguien quiera estar actualizando de versión agregando sus cambios cada vez).

Volviendo a openpay.v1.js, los setters ya están solo es quitar la versión del API que claramente no debería estar ahí.

Si siguen en duda en cuanto si sería buena idea o no tener estos setters pueden checar las librerías de Stripe y BraintreePayments. Ambas te permiten cambiar los endpoints entre otras muchas cosas.

Todos estos comentarios los hago con la mejor de las intenciones. 👍

Sauri89 commented 6 years ago

alguna ayuda para la implementacion de openpay en React js desde la parte del frontEnd, sin tener que utilizar los scripts de javascript como tales?

oasis1992 commented 6 years ago

me acabo de encontrar con esto, tal vez sea util https://libraries.io/bower/openpay

open-pay / openpay-js

Falta de soporte para pruebas #9