Sigue a la discusión en OpenTechEvents/ote-reader#9, donde se preguntaba si, tras añadir a <ote-events> el atributo feeds (para cargar varios feeds a la vez), merecía la pena que ote-reader refactorizara para apoyarse en él.
Conclusión de esa discusión: no para ote-reader tal como está hoy, porque el reader necesita un modelo de suscripciones mucho más rico que "una lista de feeds a fusionar" — carpetas, no-leídos por feed, edición de URL, drag&drop, etc. — y feeds no cubre eso salvo que el widget delegue toda esa gestión, que no es su rol.
Lo que sí quedó como pregunta abierta, y es el motivo de este issue en ote-tools: ¿tendría sentido que <ote-events> exponga una API que acepte una lista de eventos (o un feed) ya resuelto/filtrado por el consumidor, en vez de (o además de) URLs de feeds que el propio widget resuelve? Esto permitiría que integraciones como ote-reader —que ya hacen su propio fetch/parseo/merge de feeds— usen <ote-events> puramente como capa de presentación con una API más explícita, sin depender de asignar directamente la propiedad events del elemento (que es lo que hace hoy ote-reader, ver app.js).
Puntos a explorar:
- ¿Qué forma tendría esa API (atributo, propiedad, método)?
- ¿Compensa exponer también la lógica de bajo nivel de fetch/parseo de un feed OTE (detección de feed vs. evento suelto, discovery vía
<link rel="alternate">, etc.) como utilidad reusable, ya que hoy existe una implementación de eso tanto dentro del widget como duplicada en ote-reader?
- Si se define esa API, ¿vale la pena que
ote-reader migre a ella para dejar de duplicar el fetch/parseo de feeds?
Referencia: OpenTechEvents/ote-reader#9 y su comentario con el análisis completo: OpenTechEvents/ote-reader#9 (comment)
Sigue a la discusión en OpenTechEvents/ote-reader#9, donde se preguntaba si, tras añadir a
<ote-events>el atributofeeds(para cargar varios feeds a la vez), merecía la pena queote-readerrefactorizara para apoyarse en él.Conclusión de esa discusión: no para
ote-readertal como está hoy, porque el reader necesita un modelo de suscripciones mucho más rico que "una lista de feeds a fusionar" — carpetas, no-leídos por feed, edición de URL, drag&drop, etc. — yfeedsno cubre eso salvo que el widget delegue toda esa gestión, que no es su rol.Lo que sí quedó como pregunta abierta, y es el motivo de este issue en
ote-tools: ¿tendría sentido que<ote-events>exponga una API que acepte una lista de eventos (o un feed) ya resuelto/filtrado por el consumidor, en vez de (o además de) URLs de feeds que el propio widget resuelve? Esto permitiría que integraciones comoote-reader—que ya hacen su propio fetch/parseo/merge de feeds— usen<ote-events>puramente como capa de presentación con una API más explícita, sin depender de asignar directamente la propiedadeventsdel elemento (que es lo que hace hoyote-reader, verapp.js).Puntos a explorar:
<link rel="alternate">, etc.) como utilidad reusable, ya que hoy existe una implementación de eso tanto dentro del widget como duplicada enote-reader?ote-readermigre a ella para dejar de duplicar el fetch/parseo de feeds?Referencia: OpenTechEvents/ote-reader#9 y su comentario con el análisis completo: OpenTechEvents/ote-reader#9 (comment)