Ça a l’air super, David ! Une suggestion : serait-il possible de faire continuer la barre (peut-être à un rythme plus lent) plutôt que de la faire s’arrêter vers le milieu, même si elle attend une réponse ? Elle pourrait peut-être avancer plus lentement de 40 % à 70 %, puis s’arrêter si aucune réponse n’arrive ?
Cacher cette courte pause donnerait, à mon avis, une impression de réactivité et d’instantanéité plus grande 
Actuellement, il semble ralentir pendant 5 secondes avant de s’arrêter à 80 % de la largeur.
Ici, j’ai simulé une connexion Internet très, très lente :
SCSS actuel :
.loading-indicator-container {
--loading-duration: 5s;
--loading-function: cubic-bezier(0, 0, 0, 1);
--done-duration: 0.4s;
--done-function: ease;
--fade-out-duration: 0.4s;
position: fixed;
top: 0;
left: 0;
z-index: 1001;
height: 3px;
width: 100%;
opacity: 0;
transition: opacity var(--fade-out-duration) ease var(--done-duration);
background-color: var(--primary-low);
}
.loading-indicator-container .loading-indicator {
height: 100%;
width: 100%;
width: 0%;
background-color: var(--tertiary);
}
.loading-indicator-container.loading {
opacity: 1;
transition: opacity 0s;
}
.loading-indicator-container.loading .loading-indicator {
transition: width var(--loading-duration) var(--loading-function);
width: 80%;
}
.loading-indicator-container.done .loading-indicator {
transition: width var(--done-duration) var(--done-function);
width: 100%;
}
body.discourse-hub-webview .loading-indicator-container {
top: 1px;
}
body.footer-nav-ipad .loading-indicator-container {
top: 49px;
}
body.loading #main-outlet {
opacity: 0.2;
transition: opacity 0.2s ease;
}
Hmm, pour moi, ça s’arrête à environ 40 %, mais une barre animée – même si elle est plus lente – serait mieux qu’un arrêt, je pense.
En outre, en ce qui concerne le fondu : peut-être que faire disparaître l’ancien contenu et apparaître le nouveau rendrait le tout plus rapide (si c’est possible de cibler la sortie pour la route de chargement) ?
Il se passe deux choses…
@Canapin a raison : l’animation initiale se termine à 5 secondes, à 80 %… donc sur une connexion lente, elle restera bloquée là et ne se terminera que lorsque vous serez sur la page suivante.
Le cas de @P16 correspond à ce que je vis sur une connexion plus rapide… une fois que la transition hors de la page actuelle se produit, l’animation s’arrête brièvement là où elle en était… et reprend une seconde plus tard sur la nouvelle page (j’ai exagéré la hauteur de la barre ici pour qu’elle soit visible).
Je suis d’accord pour dire qu’il serait idéal de maintenir un certain mouvement en cours, mais cela pourrait ne pas être possible sans changer complètement la façon dont c’est implémenté…
Je ne pense pas que l’apparition en foncé (fade in) aidera beaucoup… vous ne pouvez pas faire apparaître le contenu en foncé tant que vous ne l’avez pas, donc vous en retardez légèrement l’apparition de cette façon. Je suppose qu’il est possible que cela crée une illusion de rapidité, mais techniquement, ce sera plus lent de la durée exacte de l’animation d’apparition en foncé !
Je viens de réaliser que vous pouvez tester l’apparition en foncé (en quelque sorte) avec le composant de la table des matières (car il fait apparaître le message en foncé), par exemple… visitez : PostgreSQL 13 update. Je ne pense pas que cela donne une impression particulièrement plus rapide… mais c’est définitivement plus “doux”.
Oooh, je pense que cela se produit parce que le contenu a chargé, et il y a un important blocage lors de l’analyse HTML / de la cascade de styles / de la mise en page / du rendu, pendant lequel l’animation ne peut pas bouger.
.loading-indicator-container .loading-indicator, .loading-indicator-container {
background-color:#FFCC00;
}
J’ai essayé de changer la couleur dans le CSS du thème, mais elle reste bleue. Une aide serait la bienvenue ?
Exactement. La nature monothreadée du rendu JS / DOM signifie que nous perdons beaucoup de trames pendant le rendu d’un sujet 
. Le curseur « bouge » en permanence, mais les trames ne sont tout simplement jamais rendues.
Merci. Je viens de régler ça dans le noyau, donc cela sera corrigé ici sur Meta très prochainement.
Je vais activer un fondu d’entrée sur Meta aujourd’hui afin que nous puissions voir comment cela se ressent. Bien sûr, si nous le faisons, nous devrons supprimer les autres fondu d’entrée, comme celui du composant sommaire.
Édité : c’est fait. Le fondu d’entrée est activé sur Meta.
Selon l’ordre dans lequel vos thèmes/composants sont chargés, cela pourrait ne pas fonctionner. Vous devez rendre le sélecteur « plus spécifique » que le CSS du composant de chargement. La solution la plus simple est probablement d’ajouter !important à la propriété background-color. Vous voudrez également supprimer le sélecteur container, sinon l’arrière-plan sera identique au premier plan :
.loading-indicator-container .loading-indicator {
background-color:#FFCC00 !important;
}
Merci David, ça a l’air super !
Il prend désormais en moyenne les 5 derniers chargements de page et l’utilise pour définir la vitesse de la barre.
Bonjour David,
Ce chargeur s’améliore de jour en jour Continuez ce excellent travail.
Avec cette nouvelle mise à jour, cela semble plus dynamique
Je viens de remarquer un point concernant cela dans une catégorie. J’utilise le bouton « Créer un sujet » pour le renommer. 
Avec le curseur de chargement, le texte du bouton ne se met pas à jour. Je l’ai remarqué car cela pourrait poser problème avec d’autres scripts.
Démo (dans cette vidéo, je clique sur une catégorie qui a un autre texte pour le bouton « Créer un sujet », puis je vais vers une autre catégorie qui a le bouton « Créer un sujet » par défaut.) Après avoir actualisé toute la page, le texte correct s’affiche.
L’apparition/disparition progressive est une amélioration. Mais je trouve toujours le curseur distrayant. Je me surprends à le regarder, ce qui signifie que je suis plus lent à être prêt à lire la page une fois chargée. Avec le spinner, il était à un endroit fixe, ce qui permettait de facilement ne pas le regarder, et son apparition soudaine me fait penser à la vitesse (peut-être à tort).
Il se peut que sur des connexions lentes, le curseur soit préférable car il donne une idée de la vitesse de chargement de la page. Je ne sais pas trop à ce sujet.
Pour moi, lorsque j’utilise un téléphone mobile, le curseur se trouve en haut de l’écran, tandis que l’ancien était situé plus au milieu, à environ 30 % du haut…
Au lieu de garder les yeux fixés au centre de votre téléphone, ils doivent bouger de haut en bas, de haut en bas… juste mon avis…
Je suis d’accord avec cela. Je pense qu’il serait préférable que le curseur de chargement fonctionne uniquement sur ordinateur de bureau, et que sur mobile, on conserve le spinner. Le spinner donne plus l’impression d’utiliser une application, ce qui est bien sur mobile. Tout comme YouTube utilise des chargeurs.
Oui, je l’ai utilisé sur un iPhone, donc mes commentaires concernaient vraiment la version mobile.
J’adore le concept. Je suis un grand partisan des curseurs plutôt que des chargeurs rotatifs.
J’ai activé et testé sur de nombreux thèmes (Dark, Alien, Vincent, Star Wars, etc.) sur des écrans ROG de 27" et 34". Le curseur de chargement était à peine visible. Il semble très fin. Sur les thèmes “dark”, la ligne fine semblait avoir une couleur trop douce pour être vraiment remarquée.
J’ai également testé le curseur sur mobile, iPhone 6s et iPhone 6+. Commentaires similaires. À peine perceptible.
J’essaie de ne pas être un rabat-joie social, mais objectivement parlant, le curseur semble prometteur mais nécessite un travail supplémentaire sur le CSS (à mon avis). Nous sommes donc revenus pour l’instant au chargeur rotatif sur notre site, car il est bien visible et raconte clairement l’histoire du rechargement. Quand j’aurai le temps, je l’activerai à nouveau et travaillerai sur le CSS de notre site, car cela semble vraiment prometteur !
Cela semble très prometteur !
Merci et continuez le bon travail !
PS : Aucun problème de vitesse. Je suis connecté (juste en dehors) à notre dorsale nationale en fibre, avec une connexion fibre dédiée vers la dorsale principale.
Je tiens simplement à mentionner que je n’apprécie pas vraiment le nouveau comportement UX lors de la sélection de catégories, de sujets, etc., où la vue actuelle s’estompe avant le chargement de la nouvelle page. Je pense que l’ancienne approche, consistant à afficher une page blanche avec un indicateur de chargement, offrait une expérience bien plus agréable.
Dans les deux cas, la page change deux fois. Mais comme les indicateurs de chargement sont universels, on n’avait pas vraiment l’impression que la page changeait deux fois. On avait l’impression qu’elle se préparait à changer, puis changeait une seule fois. Maintenant, on a l’impression qu’elle change deux fois, car il reste du contenu après les deux transitions : une fois estompé, et une fois pour le nouveau contenu de la page. Il est difficile de cerner exactement pourquoi cela ne me plaît pas, mais je pense que c’est parce qu’il n’y a plus de vue de chargement universelle. Désormais, il existe en fait une infinité de vues de chargement différentes, et je trouve que l’effet de fondu suivi du chargement est distrayant, car le contenu d’arrière-plan est différent à chaque fois que je passe à une nouvelle page.
Certaines choses qui utilisent les crochets didInsertElement devront être mises à jour, oui. Avec l’ancien indicateur de chargement, tous les éléments de la page étaient détruits et recréés. Avec ce nouveau système, Ember réutilisera les éléments si possible. Cela pourrait même rendre le rendu un peu plus rapide, mais cela pourrait créer des bugs si les personnalisations ne suivent pas les modèles normaux d’Ember. Nous devrons travailler pour les corriger au fur et à mesure que nous les repérons.
Avez-vous le code de vos personnalisations dans un dépôt Git que vous pourriez partager ?
C’est la principale raison pour laquelle je veux expérimenter cela en tant que composant de thème pendant un peu plus longtemps : nous pourrons détecter autant de problèmes que possible avant de l’intégrer dans le cœur du système.
Bien sûr, voici le dépôt. Merci
Je pense qu’il y a un bug mobile (du moins sur iPhone) avec cette nouvelle fonctionnalité. Si vous sélectionnez « Dernier » dans le menu déroulant de navigation, le menu disparaît correctement une fois la page chargée. En revanche, si vous sélectionnez « Nouveau » ou « Non lu » (et peut-être d’autres options), le menu reste visible. Cela ne se produit pas à chaque fois, mais suffisamment souvent pour que le problème soit facilement reproductible. Notez que cela arrivait parfois avec l’ancienne version, mais uniquement avec « Dernier » et jamais avec « Nouveau » ou « Non lu ».
Merci @Don — j’ai testé cela et je pense que c’est une meilleure approche, qui devrait fonctionner avec le nouveau curseur : https://github.com/VaperinaDEV/category-btn-name/pull/1 (désolé si j’ai fait des erreurs en hongrois). Ce genre de modèle pourrait être utile si d’autres doivent également mettre à jour leurs composants (en utilisant des propriétés calculées plutôt que didInsertElement et JQuery).
ajouté à ma liste d’investigation, merci