Sembra ottimo, David! Un suggerimento: sarebbe possibile mantenere la barra in movimento (magari a ritmo più lento) invece di farla fermare verso la metà, anche se sta aspettando una risposta? Potrebbe procedere più lentamente dal 40% al 70% e poi fermarsi solo se non arriva una risposta?
Nascondere quella breve pausa, a mio avviso, renderebbe tutto più reattivo e immediato 
Attualmente, sembra rallentare per 5 secondi prima di fermarsi all’80% di larghezza.
Qui ho simulato una connessione Internet molto, molto lenta:
SCSS attuale:
.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, per me si blocca a circa il 40%, ma una barra in movimento – anche se più lenta – sarebbe meglio di una pausa, penso.
Inoltre, riguardo allo sfumamento: forse sfumare il contenuto in uscita e far apparire quello nuovo potrebbe farlo sembrare più veloce (se è possibile indirizzare l’uscita per la rotta di caricamento)?
Ci sono due cose che stanno accadendo…
@Canapin ha ragione: l’animazione iniziale termina dopo 5 secondi all’80%… quindi con una connessione lenta si bloccherà lì e non verrà completata finché non si passa alla pagina successiva
Il caso di @P16 è quello che sperimento con una connessione più veloce… una volta che avviene la transizione dalla pagina corrente, l’animazione si ferma brevemente dove si trovava in quel momento… e riprende un secondo dopo sulla nuova pagina (qui ho esagerato l’altezza della barra per renderla visibile)
Sono d’accordo sul fatto che mantenere in corso un certo movimento sia l’ideale, ma potrebbe non essere possibile senza cambiare completamente il modo in cui è implementato…
Non credo che lo sfondo in entrata aiuti molto… non puoi far apparire il contenuto in sfumatura finché non lo hai, quindi ne ritardi leggermente la visualizzazione in questo modo. Immagino che possa creare un’illusione di velocità, ma tecnicamente sarà più lento della durata dell’animazione di sfondo in entrata!
Ho appena realized che puoi testare lo sfondo in entrata (in un certo senso) con il componente della tabella dei contenuti (perché sfuma in entrata il post), ad esempio… visita: PostgreSQL 13 update. Non credo che sembri particolarmente più veloce… ma è sicuramente “più morbido”.
Oooh, penso che accada perché il contenuto è stato caricato, ma si verifica un lungo blocco durante il parsing HTML, la cascata degli stili, il layout e il rendering, momento in cui l’animazione non può muoversi.
.loading-indicator-container .loading-indicator, .loading-indicator-container {
background-color:#FFCC00;
}
Ho provato a cambiare il colore nel CSS del tema, ma rimane blu. Qualche aiuto?
Esatto. La natura single-thread di JS e del rendering del DOM significa che perdiamo molti frame mentre si renderizza un argomento 
. Lo slider si sta ‘muovendo’ per tutto il tempo, è solo che i frame non vengono mai renderizzati.
Grazie. Ho appena sistemato la cosa nel core, quindi sarà corretto qui su Meta molto presto.
Farò partire un dissolvenza in entrata su Meta oggi così potremo vedere come si sente. Anche se ovviamente, se lo facciamo, vorremo rimuovere altri dissolvenze in entrata come il componente TOC.
Modifica: fatto. Dissolvenza in entrata abilitata su meta
A seconda dell’ordine in cui i tuoi temi/componenti vengono caricati, potrebbe non funzionare. Devi rendere il selettore ‘più specifico’ del CSS del componente dello slider di caricamento. La cosa più semplice è probabilmente aggiungere !important al background-color. Dovrai anche rimuovere il selettore del container, altrimenti lo sfondo sarà uguale al primo piano:
.loading-indicator-container .loading-indicator {
background-color:#FFCC00 !important;
}
Grazie David, sembra ottimo!
Ora calcola la media degli ultimi 5 caricamenti della pagina e la utilizza per impostare la velocità della barra.
Ciao David,
Questo loader sta diventando sempre migliore Continua così.
Con questo nuovo aggiornamento sembra più dinamico
Ho appena notato un dettaglio in una categoria. Uso il pulsante “Crea argomento” per rinominare. 
Con lo Loading Slider, il testo del pulsante non si aggiorna. L’ho notato perché potrebbe causare problemi con altri script.
Demo (in questo video clicco su una categoria che ha un testo diverso per il pulsante “Crea argomento” e passo a un’altra categoria con il pulsante predefinito.) Dopo aver ricaricato l’intera pagina, viene mostrato il testo corretto.
L’effetto di dissolvenza in entrata/uscita è un miglioramento. Ma trovo ancora lo slider una distrazione. Mi accorgo di guardarlo, il che significa che impiego più tempo a essere pronto per leggere la pagina quando viene caricata. Con il caricamento a spinner, era in un unico punto, quindi era facile non guardarlo, e la sua improvvisa comparsa mi fa pensare alla velocità (forse a torto).
Potrebbe essere che su connessioni lente lo slider sia meglio, perché ti dà un’idea di quanto sia lenta o veloce la pagina nel caricarsi. Non so dirlo con certezza.
Per me, quando si utilizza uno smartphone, lo slider si trova nella parte superiore dello schermo, mentre quello vecchio era posizionato più al centro, circa al 30% dall’alto…
Invece di mantenere lo sguardo fisso al centro del telefono, gli occhi devono muoversi su e giù, su e giù… solo un mio piccolo contributo…
Sono d’accordo con questo. Penso che sarebbe meglio se lo Slider di caricamento funzionasse solo su desktop e su mobile si mantenesse lo spinner. Lo spinner dà più la sensazione di usare un’app, il che è positivo su mobile. Proprio come fa YouTube con i caricamenti.
Sì, l’ho usato su un iPhone, quindi i miei commenti si riferivano davvero all’uso su mobile.
Adoro il concetto. Sono un grande fan degli slider rispetto ai spinner.
Li ho attivati e provati su molti temi (Dark, Alien, Vincent, Star Wars, ecc.) sia su monitor ROG da 27" che da 34". Si vedeva a malapena lo slider di caricamento. Sembra molto sottile. Nei temi “dark”, la linea sottile sembrava avere un colore troppo tenue per essere notata davvero.
Ho anche provato lo slider su mobile, iPhone 6s e iPhone 6+. Commenti simili. Quasi impercettibile.
Cerco di non essere il guastafeste del gruppo, ma obiettivamente parlando, lo slider sembra promettente ma necessita di ulteriori lavori sul CSS (a mio parere), quindi per ora siamo tornati allo spinner sul nostro sito, poiché è ben visibile e racconta chiaramente la storia del “ricaricamento”. Quando avrò tempo, lo riattiverò e lavorerò sul CSS per il nostro sito; perché sembra davvero promettente!
Sembra molto promettente!
Grazie e continuate così!
PS: Nessun problema di velocità. Sono collegato (appena fuori) alla dorsale nazionale in fibra, con una connessione fibra dedicata alla dorsale principale.
Voglio solo precisare che non mi piace molto il nuovo comportamento dell’interfaccia utente quando si selezionano categorie, argomenti, ecc., in cui la visualizzazione corrente viene attenuata prima che venga caricata la nuova pagina. Ritengo che il vecchio approccio, che prevedeva semplicemente una pagina vuota con un indicatore di caricamento, offrisse un’esperienza molto migliore.
In ogni caso, la pagina cambia due volte. Ma poiché gli indicatori di caricamento sono elementi universali, non si aveva la sensazione che la pagina cambiasse due volte. Sembrava che si stesse preparando al cambiamento e poi avvenisse una sola transizione. Ora invece sembra che cambi due volte, perché dopo entrambe le transizioni rimane del contenuto: una volta attenuato e una volta con il nuovo contenuto della pagina. È difficile capire esattamente perché non mi piaccia, ma credo sia perché non c’è più una vista di caricamento universale. Ora ci sono di fatto un numero infinito di diverse viste di caricamento, e trovo che l’effetto di attenuazione seguito dal caricamento sia distraente, dato che il contenuto di sfondo è diverso ogni volta che si passa a una nuova pagina.
Alcune cose che utilizzano gli hook didInsertElement dovranno essere aggiornate, sì. Con il vecchio caricatore, tutti gli elementi nella pagina venivano distrutti e ricreati. Con questo nuovo sistema, Ember riusa gli elementi quando possibile. Questo potrebbe addirittura rendere il rendering leggermente più veloce, ma potrebbe creare alcuni bug se le personalizzazioni non seguono i normali pattern di Ember. Dovremo lavorare per risolverli e pulirli man mano che li individuiamo.
Hai il codice delle tue personalizzazioni in un repository Git che potresti condividere?
Questo è il motivo principale per cui voglio sperimentare con questo come componente di tema per un po’ di tempo ancora: potremo individuare più problemi possibili prima di integrarlo nel core.
Certo, ecco il repository. Grazie
Penso ci sia un bug su mobile (almeno su iPhone) con questa nuova funzionalità. Se selezioni “Ultime” dal menu a tendina di navigazione, quando la pagina si carica il menu scompare correttamente. Ma se selezioni “Nuovi” o “Non letti” (forse anche altre opzioni), il menu rimane visibile. Non succede il 100% delle volte, ma abbastanza spesso da rendere il problema facilmente riproducibile. Tieni presente che questo accadeva talvolta anche nella versione precedente, ma solo con “Ultime” e mai con “Nuovi” o “Non letti”.
Grazie @Don - ci ho giocato un po’ e penso che questo sia un modo migliore di farlo, che dovrebbe funzionare con il nuovo slider: https://github.com/VaperinaDEV/category-btn-name/pull/1 (scusa se ho sbagliato qualcosa in ungherese). Questo tipo di pattern potrebbe essere utile se altri devono aggiornare i propri componenti (usando le proprietà calcolate invece di didInsertElement e JQuery).
aggiunto alla mia lista da investigare, grazie