Bug: reaction e reaction-received non caricano la pagina successiva

Bug
1

Nella pagina reaction/reaction-received in activity/notification esiste un bug.

Quando l’utente tenta di scorrere verso il basso e caricare la pagina successiva, gli stessi elementi vengono aggiunti all’elenco, causando duplicazioni.

Il problema deriva da un disallineamento tra il frontend e il backend. L’id definito nel frontend è post_id mentre il backend richiede reaction_id.

Una bozza di PR è qui, si prega di rivederla quando è conveniente.

3 Mi Piace
2

Grazie per la bozza di PR, sembra che la paginazione per le reazioni sia ora imprecisa e si ripeta.

Non sono sicuro che la correzione corretta sia impostare post_id. Sembra che la paginazione utilizzi before_reaction_user_id (vedi qui). Potrebbe anche essere utile rimuovere la riga 27 (la PR) poiché è probabilmente impostata nella reaction appiattita sopra.

3

Grazie per la tua risposta.
Lo ispezionerò domani e vedrò se qualcosa può risolverlo.

1 Mi Piace
4

Perfetto, grazie!

Per essere chiari, penso che before_reaction_user_id dovrebbe essere l’ID proveniente da discourse_reactions_reaction_users - penso che il nome di questa variabile sia alquanto confuso. Sentiti libero di chiarire qualsiasi cosa qui o in chat.

1 Mi Piace
6

Ho indagato e ho scoperto perché l’rspec è fallito.

La specifica originale sta verificando un componente con la proprietà expect(page).to have_css(\".user-stream-item [data-post-id='#{post_1.id}']\").

Tuttavia, il #{post_1.id} è stato modificato in reaction_user_id nell’ultimo commit, il che ha causato una discrepanza, portando al fallimento.

Il pensiero originale era quello di cambiare id per soddisfare le esigenze dell’API, tuttavia, ho perso di vista il fatto che l’id è usato anche in PostList come post_id, come segue:

<PostList
    @posts={{@model}}
    @fetchMorePosts={{@controller.loadMore}}
    @emptyText={{i18n "notifications.empty"}}
    @additionalItemClasses="user-stream-item"
    @showUserInfo={{false}}
    class="user-stream"
  >

E l’id utilizzato in esso è mappato nel componente post.gjs

data-post-id={{@post.id}}
data-topic-id={{@post.topicId}}
data-user-id={{@post.user_id}}

Quindi, il comportamento originale di id non dovrebbe essere modificato, poiché ciò potrebbe causare gravi discrepanze nella postList, che porta direttamente al fallimento dell’rspec di ieri.

Come soluzione alternativa, potrebbe esserci un altro modo per risolvere questo problema:

Aggiungere un nuovo campo reaction_user_id: reaction.id quando si esegue flattenForPostList, quindi modificare la funzione #getLastIdFrom(array) da return array.length ? array[array.length - 1].id : null; a return array.length ? array[array.length - 1].reaction_user_id.

TL:DR;
L’reaction_id, il post_id e ora il reaction_user_id sono totalmente diversi, ma l’id utilizzato nel componente postList deve essere post_id. Mentre l’id necessario per recuperare la pagina successiva dovrebbe essere reaction_user_id, il che è estremamente sconcertante.

@nat

7

Grazie per l’indagine e la PR @small-lovely-cat :+1:

Ho aggiunto una specifica alla PR e la unirò.

2 Mi Piace
8

Questo argomento è stato chiuso automaticamente dopo 19 ore. Non sono più ammesse nuove risposte.