Los serviceworkers de los cojones...

bLaKnI #1 Jun '20 Inocente

A ver...

Un CMS opensource del curro.
Versión 6, no traía implementación de JS serviceworker. La nueva versión 7, la trae.

El CMS te deja crear workflows. En estos, creas formularios de interacción para los usuarios. Y en estos formularios, arrastras a modo UI los botones, inputs etc...
Una cosa que te deja meter, es una pastilla de "custom HTML", y ahí, le metes lo que te venga en gana dentro del juego JS+CSS+HTML.

Se crea un botón en HTML que al clicarlo, pega un $.get() a un servicio Flask levantado en la misma instancia.
Nada raro:

¿Si el Flask esta parado? Al hacer click en el botón, el $.get() devolvía un 404 y entraba en el trozo de código de .fail().
Si el Flask estaba levantado, entraba con el 200, en el trozo de código del .done(). ¿Si? Hasta aquí OK.

Ahora, versión 7 del CMS, trae una implementación JS de serviceworker.
Por lo que "fetchea" absolutamente toda request que salga de la aplicación. Resultado de esto? Que el $.get() hacia el Flask, este levantado o no, siempre responde con un 200, ya que cuando el Flask está en marcha el 200 lo da el Flask como tal, y cuando esta offline, el 200 lo devuelve el propio serviceworker como tal.

Pregunta:

¿Como hago la llamada de tal forma que el serviceworker no me haga puto caso y me deje trabajar AS ALWAYS?
En caso de imposibilidad en lo anterior, ¿como extiendo la funcionalidad del FETCH para añadir un condicional del tipo "si URL contiene /api/", return;

A ver si habéis lidiado con ello.

Thx!

r2d2rigo #2 Jun '20 Inocente

No he tocado serviceworkers en mi vida, hulio, pero esta clarisimo que hay una cache de por medio que se esta saltando a la torera el estado del servidor. Mirate las docs a ver si esta activada por defecto y si puedes quitarla para ese endpoint.

Y si dices que CMS es lo mismo puedo echarle un ojo a la implementacion a ver que esta pasando.

1 respuesta

Mujiwara #3 Jun '20

No acabo de entender del todo el caso, pero te serviría pasandole un parámetro de timestamp por ejemplo, y que la petición devuelva la respuesta de siempre + el campo, como si fuera un ping-pong, si te llega el 200 comparas tu valor con el valor devuelto de ese parámetro para saber que la respuesta es válida.

B

[Borrado] #4 Jun '20

#1 En el listener, por ejemplo:

if ( event.request.url.indexOf( '/api/' ) !== -1 ) { return false; }

1 respuesta

bLaKnI #5 Jun '20 Inocente

#4 Correcto! Pero necesito extender dicha funcionalidad sin tocar el propio codigo del serviceworker. Como coño me engancho ahí?
Permite JS el uso de decorators en funciones y classes no?

#2 thx! Pensad que no puedo alterar el codigo fuente como tal. Está montado en JAVA con los WARs montados y pre-desplegados. Basicamente es un autodescomprimible que en paquete te facilita un entorno MariaDB, un Tomcat y los webapps pertinentes. De ahí que las pocas cosas que pueden hacerse sean mediante "bean shells" (java inyectado directamente, pero solo en los processes, no en los forms) y custom html. Y si, clarisimamente es una cache. De hecho ese es el quid de los Serviceworkers, gestionar entre otros "el offline".

1 respuesta

B

[Borrado] #6 Jun '20

#5 los serviceworkers van en su propio contexto y son immutables.

Si no tienes opción de modificar el código del service, tendrías que modificar el código donde se registra (para cargar otro diferente). Otra opción sería levantar tu propio serviceworker, el que esté activo se detendrá y pasará a status redundant, usa self.skipWaiting() en el install.

1 respuesta

bLaKnI #7 Jun '20 Inocente

#6 Ok, de todos modos sucede que se trata de un punto muy concreto. Tu cuenta que la app te deja montar forms, procesos, workflows, etc...
Y en un formulario muy concreto, le pones una pastilla de custom html.
Ahí, tendría que inyectar el script de creación de un service worker muy sencillo, y hacer el register inmediatamente para poder hacer simplemente el GET despues, sin ser "catcheado". y la pregunta es: al salir de la pagina entonces y proseguir con el resto de página, el SW creado a tal efecto desaparece? Porque según entiendo una vez instalado no hya marcha atrás...
Y me parece muy heavy tener que crear un SW especifico para inhabilitar el anterior y inmediatamente despues hacer un "switchkill" para realizar el unregister()...

Menuda mierda...

1 respuesta

B

[Borrado] #8 Jun '20

#7 al registrar el service puedes usar las opciones para determinar el alcance y acotarlo a un determinado rango de url.

edit: para una solución "real" en vez de una "ñapa", toca editar el CMS y agregar la funcionalidad al serviceworker.

Los serviceworkers de los cojones...

Usuarios habituales

Tags