Host< >Volpe Communication
reader-host-template.html
<iframe> al reader sin src
No tiene el src para que reader-host-manager.js pueda controlar cuando comienza a cargar
reader-host-manager.js
- Buscar el DOM del reader
- Determina volpeUrl
- Escucha onload del reader
- setAttribute src a volpeUrl
- onload => reader.postMessage con hostLocation
- Settea HOST_LOCATION en reader
- ya dentro del reader => loadingProcess.init
- Wait until document.readyState === 'complete'
- loadingProcess.determineEnvironment
- loadingProcess.loadInsideIframe
- Wait until window.HOST_LOCATION is defined
- Will be used to communicate with parent
- window.parent.postMessage 'readerInitialized'
- Listen for postMessage 'e.data.name === 'readerInitialized''
- ReaderVolpe.contentWindow.postMessage with all issue data
All postMessage communications between the 2 parts need to compy with the spec, which requires the following properties:
- connectorVersionTarget: required, string, at the time of writing it must be 'volpe:1.0.0'
- target: volpeHost, volpe
- timestamp: required, number
- type: required, string, must be 'event'
- name: required, string
- payload: optional, object
Un pequeño repaso de cómo funciona en nuestras codebases para web y app actual:
- Tenemos un reader-host-template.html que contiene un
<iframe>para cargar el reader, pero inicialmente sin src . Y justamente no tiene el src para quereader-host-manager.jspueda controlar cuando comienza a cargar. - Tenemos un
reader-host-manager.jsque se encarga de bootstrapear el reader (volpe), enviarle la información de la publicación y, también, servir de nexo para acciones que deben llevarse a cabo desde el host. Las acciones que lleva a cabo el host son:readerInitializeden la que el reader le avisa al host que ya está listo para recibir la información del contenidocloseen la que el reader le avisa al host que lo tiene que cerrarlocationChangeden la que el reader le avisa al host que cambió la posición en el contenidoshareContenten la que el reader le da al host data para compartir mediante la UI de share nativa del OSfavoriteIssuesToggleren la que el reader le pide al host que haga un ping al endpoint para marcar la publicación como favorita
De esos eventos el más complejo es readerInitialized. Cuando el host recibe ese evento le envía un postMessage al reader con toda la información de la publicación y config general del reader. Ese evento que el host emite al reader se llama readingSessionData. Eso lo pueden ver acá puntualmente https://gitlab.com/publicala/tartaruga/blob/ced7ceae36178c520d864ca1aad099bad5f0b9cf/src/pages/reader/reader.ts#L180-L237
Hago hincapié en que pueden ver la implementación actual en https://gitlab.com/publicala/tartaruga/-/blob/master/src/pages/reader/reader.ts
--
Y les comparto también un recap del proceso de carga del reader desde el punto de vista del host:
- El host kickstartea la carga del index.html del reader
- En el evento onload, el host emite el evento setHostLocation al reader con el payload
{hostLocation: window.location.href }- Esto es necesario porque la API postMessage necesita que seamos precisos y que cada parte apunte directamente al destinatario esperado. Osea que el reader tiene que saber la URL del host, para poder hablarle directamente.
- El reader continúa su proceso de carga y, cuando está listo, emite el evento
readerInitializedal host - El host escucha ese evento y responde con el evento
readingSessionDataque incluye toda la data para terminar de cargar el reader y el contenido.
--
Hay dos eventos que el reader espera del host setHostLocation y readingSessionData . Esos eventos necesitan tener estas propiedades y valores para pasar la validación del reader:
targetcon valor'volpe'connectorVersionTargetcon valor'volpe:1.0.0'timestampcon un timestamp numérico en milisegundostypecon valor'event'namecon el nombre del evento como valor, oseasetHostLocationoreadingSessionDatapayloades opcional y depende del evento en si