Paginación en la lista de artículos
Algunos sitios tienen más de 500 artículos que se están mostrando todos juntos en el panel. Esto hace que el plugin de reordenación sea inutilizable (ver #10 (closed)). Redujimos la carga del lado del panel con algo de caché, pero ahora viene un sitio con 2000 artículos con lo que ya tenemos que empezar a pensar en paginación. No me gusta la paginación porque después hay mil páginas ni el scroll infinito porque cuando te vas y volvés perdiste el estado, pero me decantaría por scroll infinito para poder reordenar artículos (pero vale la pena?). Pienso en voz alta:
-
Agregar en la API una forma de consultar artículos con paginación. Como ahora cada vez que se lee el sitio hay que procesar todos los artículos, hay que hacer un par de cambios para hacerlo más eficiente.
-
Usar
Post#updated_at
para invalidar la caché, porque accede a la fecha de modificación del post en el sistema de archivos -
Implementar un método en
Site
para obtener todos los archivos de los artículos (como si fueran un stub delPost
), o sea que habría que moverPost#updated_at
a unStubPost
o cambiar toda la dinámica de lectura deSite
para que no use Jekyll para leer los artículos. Me parece que esta última opción es la más sostenible, porque nos permite leer los artículos individualmente en lugar de todos juntos. En ese casoPost
seguiría teniendo unJekyll::Document
asociado, para no tener que cambiar todos losMetadata
y la estructura interna dePost
, pero la lectura se haría desdePost
y no desdeSite
como ahora. De paso tenemos mejor separación de responsabilidades! -
La API entonces sería algo como
GET /v1/sites/SITIO/posts.json?page=X
. Usamos HTML renderizado en el servidor o una plantilla del lado del navegador? -
Al scrollear, StimulusJS consulta a la API y va agregando los posts que faltan.
-
Podemos usar
localStorage
o unServiceWorker
para ir cacheando la paginación, de forma que cuando te vayas y vuelvas llegues al mismo estado de la página. Habría que ver cómo entra Turbolinks en este cacheado de la página y quizás no haga falta el ServiceWorker. -
Podemos usar stale-while-revalidate