대卫 씨, 정말 잘하셨네요! 한 가지 제안이 있는데요, 응답을 기다리는 동안 중간쯤에서 멈추는 대신, 진행 바가 계속 진행되도록 하는 것은 가능할까요? 예를 들어 40%에서 70% 구간에서는 속도를 늦추고, 그래도 응답이 없으면 그때 멈추는 방식 말이에요. 그렇게 짧은 멈춤을 없애면 더 반응이 빠르고 즉각적인 느낌을 줄 수 있을 것 같습니다 
1개의 좋아요
현재는 5초 동안 속도가 느려진 후 80% 폭에서 멈추는 것 같습니다.
여기서는 매우, 매우 느린 인터넷 연결을 시뮬레이션했습니다:
현재 SCSS:
.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;
}
3개의 좋아요
음, 제 환경에서는 40%쯤에서 멈추는데, 속도가 느리더라도 움직이는 바가 일시정지보다 나을 것 같아요.
그리고 페이드 효과와 관련해서, 기존 콘텐츠를 페이드아웃하고 새 콘텐츠를 페이드인하면 더 빠르게 느껴지지 않을까요? (로딩 라우트의 아웃렛을 대상으로 할 수 있다면요?)
3개의 좋아요
두 가지 일이 동시에 일어나고 있습니다…
@Canapin의 지적처럼 초기 애니메이션은 80% 지점에서 5초에 종료됩니다… 따라서 느린 연결 환경에서는 해당 지점에서 멈추게 되고, 다음 페이지로 이동할 때까지 완료되지 않습니다.
@P16의 경우는 더 빠른 연결 환경에서 제가 경험하는 상황과 일치합니다… 현재 페이지에서 전환되는 순간, 애니메이션은 우연히 멈추게 된 지점에서 잠시 정지되고… 1초 후 새 페이지에서 다시 시작됩니다(여기서는 가시성을 위해 바의 높이를 과장하여 표시했습니다).
일부 움직임이 계속되는 것이 이상적이라는 데 동의하지만, 구현 방식을 완전히 변경하지 않는 한 이것이 불가능할 수도 있습니다…
페이드인 효과가 큰 도움이 될 것 같지 않습니다… 콘텐츠를 가져오기 전까지는 페이드인을 할 수 없으므로, 그렇게 하면 콘텐츠의 출현이 약간 지연됩니다. 속도의 환상을 줄 수 있을 가능성은 있지만, 기술적으로는 페이드인 애니메이션의 길이만큼 더 느려지는 것입니다!
방금 목차(ToC) 구성 요소(게시글을 페이드인하기 때문)로 페이드인 효과를 (어느 정도) 테스트할 수 있다는 사실을 깨달았습니다. 예를 들어 다음 주소를 방문해 보세요: PostgreSQL 13 update. 특별히 더 빠르다고 느껴지지는 않지만… 확실히 더 “부드럽습니다”.
11개의 좋아요
아, 그 이유는 콘텐츠가 실제로 로드되었는데, HTML 파싱 / 스타일 캐스케이딩 / 레이아웃 / 렌더링 과정에서 큰 지연이 발생해서 애니메이션이 움직일 수 없기 때문인 것 같아요.
3개의 좋아요
.loading-indicator-container .loading-indicator, .loading-indicator-container {
background-color:#FFCC00;
}
테마의 CSS에서 색상을 변경해 보았지만 여전히 파란색으로 남아 있습니다. 도움을 주실 수 있나요?
1개의 좋아요
네, 정확합니다. JS / DOM 렌더링의 단일 스레드 특성상 토픽을 렌더링하는 동안 프레임이 많이 유실됩니다 
. 슬라이더는 계속 ‘움직이고’ 있지만, 프레임이 렌더링되지 않는 것뿐입니다.
감사합니다. 방금 코어에서 해당 부분을 정리했으니, 곧 Meta에서도 수정될 것입니다.
오늘 Meta에서 페이드 인을 적용해서 어떤 느낌인지 확인해 보겠습니다. 물론 그렇게 하면 TOC 컴포넌트 같은 다른 페이드 인은 제거하고 싶을 겁니다.
수정: 완료했습니다. Meta에서 페이드 인 활성화됨
테마/컴포넌트가 로드되는 순서에 따라 작동하지 않을 수 있습니다. 선택자를 로딩 슬라이더 컴포넌트 CSS보다 '더 구체적’으로 만들어야 합니다. 가장 간단한 방법은 아마도 background-color에 !important를 추가하는 것입니다. 또한 컨테이너 선택자도 제거해야 합니다. 그렇지 않으면 배경색이前景(전경)과 같아지거든요:
.loading-indicator-container .loading-indicator {
background-color:#FFCC00 !important;
}
7개의 좋아요
데이비드, 감사합니다! 아주 좋습니다!
1개의 좋아요
이제 최근 5번의 페이지 로딩 평균 시간을 계산하여 바의 속도를 설정합니다
18개의 좋아요
데이비드님, 안녕하세요.
이 로더가 점점 더 좋아지고 있네요 좋은 일 계속하세요.
이 새로운 업데이트 덕분에 훨씬 더 동적인 느낌을 줍니다
카테고리에서 이 기능에 대해 한 가지 문제를 발견했습니다. 주제 생성 버튼 이름을 변경하는 기능을 사용 중입니다. 
로딩 슬라이더가 활성화되어 있으면 버튼 텍스트가 새로고장되지 않습니다. 이것이 다른 스크립트와 충돌을 일으킬 수 있을 것 같아서 발견했습니다.
데모 (이 영상에서는 다른 주제 생성 텍스트가 있는 카테고리를 클릭한 후, 기본 주제 생성 버튼이 있는 다른 카테고리로 이동합니다.) 전체 페이지를 새로고장하면 올바른 텍스트가 표시됩니다.
3개의 좋아요
페이드 인/아웃은 개선된 점입니다. 하지만 여전히 슬라이더가 시선을 빼앗는다고 느낍니다. 자꾸 슬라이더를 보게 되면서, 페이지가 로드될 때 읽을 준비를 하는 속도가 느려지는 것 같습니다. 스피너의 경우 한 곳에 고정되어 있어 시선을 덜 끌었고, 갑작스러운 움직임이 속도감을 느끼게 해주었습니다(아마도 제 오해일 수 있겠지만).
느린 연결 환경에서는 페이지 로딩 속도를 체감할 수 있어 슬라이더가 더 나을 수도 있습니다. 하지만 그 부분은 확신할 수 없습니다.
4개의 좋아요
저는 모바일 폰을 사용할 때 슬라이더가 화면 상단에 위치하는데, 이전 버전에서는 화면 중앙에, 즉 상단에서 약 30% 지점에 있었습니다…
눈을 휴대폰 중앙에 고정해 두는 대신, 위아래로, 위아래로 움직여야 합니다… 제 개인적인 의견입니다…
5개의 좋아요
동의합니다. 로딩 슬라이더는 데스크톱에서만 작동하고, 모바일에서는 스피너를 유지하는 것이 가장 좋다고 생각합니다. 스피너는 앱처럼 느껴져서 모바일에서 더 좋은 경험이죠. YouTube가 로더를 사용하는 것처럼요.
4개의 좋아요
네, 저는 아이폰에서 사용하고 있어서 제 의견은 주로 모바일 환경에 관한 것입니다.
4개의 좋아요
개념이 마음에 듭니다. 슬라이더가 스피너보다 훨씬 좋습니다.
다크, 얼라이언, 빈센트, 스타워즈 등 다양한 테마에서 27인치와 34인치 ROG 모니터 모두에서 활성화하여 사용해 보았습니다. 로딩 슬라이더가 거의 보이지 않았습니다. 매우 얇아 보입니다. ‘다크’ 테마에서는 얇은 선의 색상이 너무 흐릿해서 눈에 잘 띄지 않았습니다.
모바일에서도 슬라이더를 시도해 보았는데, iPhone 6s와 iPhone 6+에서 비슷한 결과를 보았습니다. 거의 눈에 띄지 않았습니다.
분위기를 망치는 사람으로 보이지 않으려 하지만, 객관적으로 말하자면 슬라이더는 유망해 보이지만 추가적인 CSS 작업이 필요합니다(개인적 의견). 그래서 현재는 눈에 잘 띄고 '재로딩 중’이라는 상황을 명확히 전달해 주는 스피너로 되돌려 두었습니다. 시간이 나면 다시 활성화하여 우리 사이트의 CSS를 작업할 계획입니다. 정말 유망해 보이니까요!
매우 유망해 보입니다!
감사드리며 좋은 작업 계속해 주세요!
P.S.: 속도 문제는 없습니다. 국가 광백본(직접 광섬유 연결)에 연결되어 있습니다.
5개의 좋아요
새로운 UX 동작에 대해 언급하고 싶은 점이 있습니다. 카테고리, 주제 등을 선택할 때 현재 뷰가 새 페이지가 로드되기 전에 흐려지는 방식인데, 개인적으로는 이 동작을 별로 선호하지 않습니다. 이전처럼 빈 페이지에 스피너만 표시되던 방식이 훨씬 나은 경험이었다고 생각합니다.
어떤 방식을 쓰든 페이지가 두 번 바뀌긴 합니다. 하지만 스피너는 보편적인 요소이기 때문에, 페이지가 두 번 바뀐다는 느낌은 들지 않았습니다. 마치 변경을 준비하다가 한 번에 변경되는 것처럼 느껴졌죠. 지금은 두 번 바뀐다는 느낌이 듭니다. 왜냐하면 두 번의 전환 이후에도 여전히 콘텐츠가 남아 있기 때문입니다. 한 번은 흐려진 상태로, 한 번은 새 페이지 콘텐츠로. 정확히 왜 싫은지 설명하기는 어렵지만, 보편적인 로딩 뷰가 더 이상 없기 때문인 것 같습니다. 이제는 사실상 무한히 많은 서로 다른 로딩 뷰가 존재하는 셈이죠. 배경 콘텐츠가 매번 다르기 때문에, 흐려졌다가 로드되는 방식의 로딩 뷰가 산만하게 느껴집니다.
4개의 좋아요
didInsertElement 훅을 사용하는 일부 기능은 업데이트가 필요할 것입니다. 네. 이전 스피너에서는 페이지의 모든 요소가 제거되고 다시 생성되었습니다. 이 새로운 시스템에서는 Ember가 가능한 경우 요소를 재사용합니다. 이는 아마도 렌더링 속도를 조금 더 빠르게 만들 수 있지만, 커스터마이징이 표준 Ember 패턴을 따르지 않으면 버그를 일으킬 수 있습니다. 발견되는 문제를 하나씩 해결하고 정리해 나가야 합니다.
커스터마이징 코드를 공유할 수 있는 git 저장소가 있으신가요?
이것을 테마 구성 요소로 조금 더 실험해보고 싶은 주된 이유입니다 - 코어에 포함시키기 전에 가능한 한 많은 문제를 잡아낼 수 있을 것이기 때문입니다.
6개의 좋아요
네, 여기 저장소입니다. 감사합니다
4개의 좋아요
이 새로운 기능에 모바일 버그(적어도 iPhone에서는)가 있는 것 같습니다. 내비게이션 드롭다운에서 "최신"을 선택하면 페이지가 로드될 때 드롭다운이 올바르게 사라집니다. 하지만 “새로” 또는 “읽지 않음”(그 외 다른 항목도 가능)을 선택하면 드롭다운이 여전히 표시되는 상태입니다. 100% 재현되는 것은 아니지만, 충분히 자주 발생하여 쉽게 재현할 수 있을 정도입니다. 참고로 이전 버전에서도 때때로 이런 문제가 있었지만, "최신"에서만 발생했으며 "새로"나 "읽지 않음"에서는 절대 발생하지 않았습니다.
5개의 좋아요
감사합니다 @Don - 이것을 직접 테스트해 보았는데, 새로운 슬라이더와 함께 작동할 수 있는 더 나은 방법이라고 생각합니다: https://github.com/VaperinaDEV/category-btn-name/pull/1 (헝가리어를 잘못 번역했다면 죄송합니다). 이러한 패턴은 다른 사람들이 자신의 컴포넌트도 업데이트해야 하는 경우(didInsertElement와 JQuery 대신 계산된 프로퍼티를 사용) 유용할 것입니다.
조사할 목록에 추가했습니다. 감사합니다
8개의 좋아요