Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Live vs. static feeds for events

Abierto
#1,280 12 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
csharp

Línea de trabajo

Start by tracing the existing events-feed paging flow from the feed controls to the server request and response; the issue does not name specific files or tests. Check how page numbers and event IDs are currently used. Done means paging can anchor the next view at the last visible event so new events do not shift it, while returning to the first page restores live events.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement help wanted

Issue

There should be a differentiation between a live feed and a static feed. A static feed would be anchored at a specific element id so new elements would not shift the list.

For instance, currently the only mode is live, lets say you're on page 5 of an events view, events are still piling in, but you might want to be looking at that specific page. You shouldn't need to follow the events constantly by going to the next, next, next page.

Suggestion

There might be a (Live|Static) selector at the top of an events feed (defaults to live), clicking to the next page will automatically transition to Static mode so that the page events do not change. You now should be able to navigate through the pages in static mode. Clicking Live mode should take you back to the first page with live events. Also navigating back to the first page might also take you into Live mode automatically.

Implementation

A very simple execution of this would be to replace the current paging mechanism (in the first instance without a selector at all). When you click "next" instead of using a page id it will use the last element in the current view as the anchor to start the next view and send that to the server. The server calculates the next X elements from that ID and returns it. Clicking next again does the same thing but with the last element from the current page. Clicking X (ie, 5th page) would need an additional step of requesting for the page by number and then switching to using an id anchor for the next request.

Lenguaje dominante
C#
Estrellas
2.5k
Forks
508
Merge medio
2 d 17 h
PR fusionados (30 d)
40

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de exceptionless/Exceptionless

Todos los issues de exceptionless/Exceptionless

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.