Love the concept. Iām a big fan of sliders v. spinners.
Enabled and tried on many themes (Dark, Alien, Vincent, Star Wars, etc) on both 27" and 34" ROG monitors. Could barely see the loading slider. Seems very thin. On ādarkā themes the thin line seemed too soft of a color to really notice.
Also tried the slider on mobile, iPhone 6s and iPhone 6+. Similar comments. Barely noticeable.
Trying not to be a social party-pooper, but objectively speaking, the slider seems promising but needs additional CSS work (IMO), and so we went back to the spinner on our site for now, since it is noticeable and tells the āreloading story clearlyā. When I have time, I will enable again and work on the CSS for our site; since this looks really promising!
Looks very promising!
Thanks and keep up the good work!
PS: No speed issues. Iām on (just off) our national fiber backbone, on a dedicated fiber to the main backbone.
I just want to mention that I donāt really care for the new UX behavior when selecting categories, topics, etc., where the current view becomes faded before the new page loads. I think the old approach of just having a blank page with a spinner was a much nicer experience.
In either case the page changes twice. But because spinners are universal things, it didnāt really feel like the page changed twice. It felt like it was preparing to change, and then changed once. Now it feels like itās changing twice, because there is still content after both transitions, once faded and once for the new page content. Itās hard to pin down exactly why I donāt like it, but I think itās because thereās no longer a universal loading view. Now there are effectively an infinite number of different loading views, and I find the fade-then-load loading view to be distracting since the background content is different every time I transition to a new page.
Some things that use didInsertElement hooks will need updating, yeah. With the old spinner, all elements on the page would be destroyed and recreated. With this new system, Ember will reuse elements if possible. Which might actually make rendering a little faster, but could create some bugs if customisations are not following normal ember patterns. Weāll have to work through and clean those up as we notice them.
Do you have the code for your customizations in a git repo you could share?
Thatās the main reason I want to experiment with this as a theme component for a little while longer - weāll be able to catch as many issues as possible before moving it into core.
I think thereās a mobile bug (at least on iPhone) with this new feature. If you select āLatestā from the navigation dropdown, when the page loads the dropdown properly goes away. But if you select āNewā or āUnreadā (possibly others), the dropdown is still visible. It doesnāt happen 100% of the time, but often enough that it should be easily reproducible. Note that this did happen sometimes with the old version, but only with āLatestā and never with āNewā or āUnreadā.
Thanks @dodesz - I had a play with this and I think this is a better way of doing it, which should work with the new slider: https://github.com/VaperinaDEV/category-btn-name/pull/1 (sorry if I messed up any of the Hungarian). That kind of pattern should be useful if others need to update their components as well (using computed properties rather than didInsertElement and JQuery).
I think when scrolling up and down a topic / topic-list, activating the slider doesnāt make sense. The page isnāt changing state, weāre just adding content at the top/bottom.
Granted, when clicking the topic title it does feel like a full page loadā¦ so maybe that specific case should use the slider
In the place where the post will appear? I think in that case itās not really a page transition, itās just part of the UI loading, so the spinner is ok? I donāt think weād want to trigger a full page load for this kind of thing, because it would fade out all the other topic content.
Yes this is what I thought But i think it should only use on bigger topics. Because otherwise when you click the topic title it goes to top immediately.
Yeah there are still places where the spinner is OK. I donāt think weāre going for full removal of the spinner, only the logical places where the horizontal top progress bar makes more sense.
added to my list to investigate, thanks
Thank you David! 
