Parece ótimo, David! Uma sugestão: seria possível manter a barra avançando (talvez em um ritmo mais lento) em vez de fazê-la pausar no meio, mesmo enquanto aguarda uma resposta? Ela poderia avançar mais devagar de 40% a 70% e talvez pausar só se não houver resposta?
Esconder essa breve pausa faria parecer mais responsivo e instantâneo, na minha opinião 
Atualmente, parece ir mais devagar por 5s antes de parar em 80% da largura.
Aqui simulei uma conexão de internet muito, muito lenta:
SCSS atual:
.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, para mim ele para em cerca de 40%, mas uma barra em movimento — mesmo que mais lenta — seria melhor do que uma pausa, eu acho.
Além disso, em relação ao fade-out: talvez fazer o conteúdo atual desaparecer e o novo aparecer tornaria tudo mais rápido (se for possível direcionar a saída da rota de carregamento)?
Estão acontecendo duas coisas…
@Canapin está certo de que a animação inicial termina aos 5 segundos, em 80%… então, em uma conexão lenta, ela ficará travada ali e não será concluída até que você esteja na próxima página.
O caso do @P16 é o que eu experimento em uma conexão mais rápida… assim que a transição para fora da página atual ocorre, a animação é brevemente pausada onde quer que tenha parado… e ela retoma um segundo depois na nova página (aqui exagerei a altura da barra para torná-la visível).
Concordo que manter algum movimento contínuo é ideal, mas pode não ser possível sem mudar completamente a forma como é implementado…
Acho que o fade in não ajudará muito… você não pode fazer o conteúdo aparecer gradualmente até tê-lo, então você está atrasando ligeiramente sua aparição dessa maneira. Suponho que seja possível criar uma ilusão de velocidade, mas tecnicamente será mais lento pelo tempo que a animação de fade-in durar!
Acabei de perceber que você pode testar o fade in (de certa forma) com o componente de índice (porque ele faz o post aparecer gradualmente), por exemplo… visite: PostgreSQL 13 update. Achei que não parece particularmente mais rápido… mas definitivamente é “mais suave”.
Oooh, acho que isso está acontecendo porque o conteúdo foi carregado, e houve uma grande travada na Análise de HTML / Encadeamento de Estilos / Layout / Renderização, durante a qual a animação não pode se mover.
.loading-indicator-container .loading-indicator, .loading-indicator-container {
background-color:#FFCC00;
}
Tentei alterar a cor no CSS do tema, mas ela continua azul. Alguma ajuda?
Exatamente. A natureza de thread única da renderização JS/DOM significa que perdemos muitos quadros enquanto renderizamos um tópico 
. O slider está ‘se movendo’ o tempo todo, é apenas que os quadros nunca são renderizados.
Obrigado. Acabei de arrumar isso no núcleo, então será corrigido aqui no Meta muito em breve.
Vou implementar um fade-in no Meta hoje para vermos como fica. Embora, obviamente, se fizermos isso, precisaremos remover outros fade-ins, como o componente de índice de conteúdo.
Edição: feito. Fade-in ativado no Meta.
Dependendo da ordem em que seus temas/componentes são carregados, isso pode não funcionar. Você precisa tornar o seletor ‘mais específico’ do que o CSS do componente de carregamento do slider. A coisa mais simples provavelmente é adicionar !important ao background-color. Você também quererá remover o seletor de container, caso contrário, o fundo será o mesmo que o primeiro plano:
.loading-indicator-container .loading-indicator {
background-color:#FFCC00 !important;
}
Obrigado, David, ficou ótimo!
Agora, ele calcula a média dos últimos 5 carregamentos de página e usa esse valor para definir a velocidade da barra.
Olá David,
Esse loader está ficando cada vez melhor Continue com o excelente trabalho.
Com essa nova atualização, parece mais dinâmico
Notei apenas uma coisa sobre isso na categoria. Uso o botão “Criar tópico” para renomear. 
Com o Loading Slider, o texto do botão não é atualizado. Percebi isso porque pode causar problemas com outros scripts.
Demonstração (neste vídeo, clico em uma categoria que tem outro texto para “Criar tópico” e vou para outra categoria que tem o botão padrão de “Criar tópico”). Depois que atualizo toda a página, o texto correto aparece.
O fade-in/fade-out é uma melhoria. Mas ainda acho que o slider é uma distração. Acabo olhando para ele, o que me deixa mais lento para estar pronto para ler a página quando ela carrega. Com o spinner, ele ficava em um único local, então era fácil não olhar para ele, e a brusquidão me faz pensar em velocidade (talvez equivocadamente).
Pode ser que, em conexões lentas, o slider seja melhor, pois dá uma ideia de quão lenta ou rápida é a carga da página. Não sei dizer sobre isso.
Para mim, ao usar um celular, o controle deslizante fica no topo da tela, enquanto o antigo ficava mais no meio da tela, aproximadamente a 30% do topo…
Em vez de manter os olhos focados no centro do celular, eles precisam se mover para cima e para baixo, para cima e para baixo… apenas minha opinião…
Concordo com isso. Acho que o ideal seria que o Loading Slider funcionasse apenas no desktop e, no mobile, mantivéssemos o spinner. O spinner passa mais a sensação de usar um aplicativo, o que é bom no mobile. É assim que o YouTube usa os loaders.
Sim, tenho usado no iPhone, então meus comentários realmente se referem ao uso em dispositivos móveis.
Adoro o conceito. Sou um grande fã de sliders em vez de spinners.
Ativei e testei em vários temas (Dark, Alien, Vincent, Star Wars, etc.) em monitores ROG de 27" e 34". Mal dava para ver o slider de carregamento. Ele parece muito fino. Nos temas “dark”, a linha fina tinha uma cor muito suave para ser realmente notada.
Também testei o slider no mobile, em um iPhone 6s e um iPhone 6+. Comentários similares. Quase imperceptível.
Estou tentando não ser o chato da festa, mas, objetivamente falando, o slider parece promissor, mas precisa de mais trabalho com CSS (na minha opinião). Por isso, voltamos a usar o spinner no nosso site por enquanto, já que ele é visível e conta a história do “recarregamento” de forma clara. Quando tiver tempo, vou ativá-lo novamente e trabalhar no CSS do nosso site, pois isso parece realmente promissor!
Parece muito promissor!
Obrigado e continuem com o bom trabalho!
PS: Sem problemas de velocidade. Estou conectado (quase diretamente) à nossa espinha dorsal nacional de fibra óptica, com uma ligação dedicada de fibra até a espinha dorsal principal.
Só quero mencionar que não gosto muito do novo comportamento da UX ao selecionar categorias, tópicos etc., onde a visualização atual fica esmaecida antes que a nova página carregue. Acho que a abordagem anterior, de apenas ter uma página em branco com um spinner, era uma experiência muito melhor.
De qualquer forma, a página muda duas vezes. Mas, como os spinners são elementos universais, não parecia realmente que a página mudava duas vezes. Parecia que ela estava se preparando para mudar e, então, mudava uma vez. Agora, parece que muda duas vezes, porque ainda há conteúdo após ambas as transições: uma vez esmaecido e outra com o conteúdo da nova página. É difícil identificar exatamente por que não gosto disso, mas acho que é porque não há mais uma visualização de carregamento universal. Agora, há efetivamente um número infinito de visualizações de carregamento diferentes, e acho que o efeito de esmaecimento seguido de carregamento é distrativo, já que o conteúdo de fundo é diferente toda vez que transito para uma nova página.
Algumas coisas que usam os hooks didInsertElement precisarão de atualização, sim. Com o antigo spinner, todos os elementos na página eram destruídos e recriados. Com este novo sistema, o Ember reutilizará os elementos sempre que possível. Isso pode até tornar a renderização um pouco mais rápida, mas pode criar alguns bugs se as personalizações não seguirem os padrões normais do Ember. Teremos que trabalhar nisso e corrigir esses problemas conforme os identificarmos.
Você tem o código das suas personalizações em um repositório git que possa compartilhar?
Essa é a principal razão pela qual quero experimentar isso como um componente de tema por um pouco mais de tempo — assim, conseguiremos identificar o máximo possível de problemas antes de integrá-lo ao núcleo.
Claro, aqui está o repositório. Obrigado
Acho que há um bug no mobile (pelo menos no iPhone) com esse novo recurso. Se você selecionar “Mais Recentes” no menu suspenso de navegação, ao carregar a página o menu desaparece corretamente. Porém, se selecionar “Novos” ou “Não lidos” (possivelmente outros), o menu permanece visível. Isso não acontece 100% das vezes, mas com frequência suficiente para ser facilmente reproduzido. Vale notar que isso ocorria às vezes na versão antiga, mas apenas com “Mais Recentes” e nunca com “Novos” ou “Não lidos”.
Obrigado @Don - Experimentei isso e acho que é uma maneira melhor de fazer, que deve funcionar com o novo slider: https://github.com/VaperinaDEV/category-btn-name/pull/1 (desculpe se estraguei algum húngaro). Esse tipo de padrão deve ser útil se outros precisarem atualizar seus componentes também (usando propriedades computadas em vez de didInsertElement e JQuery).
adicionado à minha lista para investigar, obrigado