La vue des réponses imbriquées (/n/) remplit les pages avec des espaces réservés pour les messages supprimés, que la vue plate omet

Si vous consultez la discussion du plugin Custom Wizard d’@angus en tant qu’utilisateur anonyme, avec l’affichage des réponses imbriquées : https://meta.discourse.org/n/-/73345.json?page=0&sort=old

/n/-/73345.json?page=0&sort=old renvoie 20 messages racine, et chacun d’eux est un espace réservé supprimé — cooked vide, aucun auteur, total_descendant_count: 0. Ainsi, toute la première page est constituée de lignes « supprimées » vides.

L’affichage linéaire des mêmes messages ne montre rien du tout (le message #2 passe directement aux sujets connexes), donc ils sont correctement masqués dans ce cas. L’affichage imbriqué, lui, les conserve et les compte pour la pagination, ce qui crée cette incohérence.

Il semble que le chargeur d’arbres récupère intentionnellement les messages supprimés (afin de garder visible un message parent supprimé lorsqu’il contient encore des réponses actives en dessous), mais il conserve également les messages supprimés qui n’ont plus de réponses visibles. Sur un sujet comme celui-ci, où les premières réponses ont toutes été supprimées, on se retrouve avec une page entière d’espaces réservés vides au lieu de contenu réel.

Le paramètre est bien activé — l’endpoint a renvoyé un code 200 au lieu de 404.

Le coupable semble être apply_visibility dans NestedReplies::TreeLoaderscope.unscope(where: :deleted_at) récupère tous les messages supprimés dans l’arbre. Cela a du sens pour un message parent supprimé qui contient encore des réponses actives, mais cela conserve aussi les messages feuilles supprimés et les branches entièrement supprimées, qui occupent des places dans la fenêtre ROOTS_PER_PAGE (et sont comptées dans has_more_roots).

Pour les utilisateurs non-administrateurs, il me semble qu’il faudrait supprimer un message supprimé à moins qu’il n’ait au moins un descendant non supprimé — ne le conserver que si son total_descendant_count visible est supérieur à 0. NestedViewPostStat exclut déjà les descendants supprimés/chuchotés de ce comptage, donc aucune requête supplémentaire n’est nécessaire.

Il faudrait appliquer cela dans les trois endroits qui construisent la page pour éviter d’obtenir des pages incomplètes : root_posts_scope, batch_preload_tree, et la partie de remplissage de page / has_more_roots. Le chemin pour les administrateurs reste inchangé pour la récupération.

2 « J'aime »

Honnêtement, ça m’a fait tourner en rond pendant un moment — j’étais persuadé que mon client mobile était bugé, puisque les commentaires restaient vides sur certains sujets tout en fonctionnant parfaitement sur d’autres. Ça m’a pris un peu de temps pour comprendre que c’était l’endpoint qui renvoyait une page complète de placeholders supprimés, et pas un problème de mon côté.

1 « J'aime »

Au fait, @markvanlan, au cas où tu aurais des idées.

1 « J'aime »

Oui, c’est juste. S’il n’y a pas de descendants, nous n’avons probablement pas besoin d’afficher l’espace réservé. J’ajouterai cela à ma liste.

Une chose à noter est que les sujets avec des réponses imbriquées sont de retour sur /t/ au lieu de /n/. Vous le verrez lorsque vous mettrez à jour Discourse la prochaine fois.

4 « J'aime »

D’accord, une chose à noter : la capture d’écran n’est pas de mon forum, elle provient de meta.discourse.org. J’ai testé meta avec mon application cliente pour diverses conditions avec des réponses imbriquées.

3 « J'aime »

J’ai placé des espaces réservés pour les messages supprimés en attendant ; avec les réponses imbriquées désactivées dans les paramètres de l’application, l’affichage correct des réponses est conservé.

1 « J'aime »

Et si on faisait autrement et qu’on déplaçait les éléments supprimés sans descendants à la fin ?

1 « J'aime »

@falco une chose à confirmer concernant les modes de tri : avec old/new/top, est-ce que le renversement place les marqueurs de position rétrogradés triés entre eux selon la même clé, ou simplement à la suite dans leur ordre d’origine ? Les deux me conviennent, je veux juste m’assurer qu’une racine supprimée sans descendants ne peut pas réapparaître en plein milieu de la liste avec un tri différent.

1 « J'aime »