기능 설명

동일한 URL 탭이 존재한다면 자동으로 스크롤을 동기화하는 옵션을 추가하는 것은 어떨까요?
보통 스크롤 동기화를 원하는 경우는 동일한 내용을 다른 형태로 띄워두고 있을 때입니다. 예로 다음과 같은 상황이 있습니다:

• 위지윅 에디터에서 마크다운 입력창과 프리뷰창의 스크롤 동기화
• 번역글과 원글의 스크롤 동기화

보통 이 확장 프로그램을 사용하는 이유는 두 번째 이유일 것입니다. 이때, 동일한 URL 탭을 생성해 하나는 번역기능을 활용해 자신의 언어로 보고 원글을 비교하며 읽는 경우도 있습니다. 이 경우, 스크롤 동기화는 반드시 사용하게 됩니다. 그러므로 동일한 URL 탭이 존재한다면 해당 탭의 스크롤 동기화를 자동으로 하는 기능을 추가하는 것도 좋을 것 같습니다.

이를 원하지 않는 사용자가 있을 수 있으니 기능 on/off 옵션을 통해 기능을 끌 수 있도록 해두는 작업도 필요할 것입니다. 더 나아간다면 동기화를 원하지 않는 URL을 사용자가 직접 리스트에 추가할 수 있도록 하는 자유도도 부여할 수 있을 것입니다.

문제 인식

다양한 높이를 가진 웹 페이지 간의 스크롤 위치를 백분율로 동기화하는 기능에 문제가 있다는 것을 사용자의 리뷰에서 발견했습니다:

works great – if i could request one feature it would be the ability to sync by scroll percentage vs. scroll y-position. this helps a lot when comparing on screens of different pixel densities. (e.g., if we are comparing a page on two screens that renders with heights 500px and 1000px, scrolling to the bottom of the 500px tall tab would scroll to the bottom of the 1000px tab as well.)

사용자는 한 페이지에서 스크롤을 최하단으로 내렸을 때, 다른 페이지에서도 동일하게 최하단으로 스크롤되기를 기대했으나, 실제로는 그렇지 않았다는 내용이었습니다.

애초에 화면 크기나 해상도 차이에 관계없이 두 화면에서 동일한 비율로 스크롤이 동기화될 수 있도록 스크롤 위치를 절대적인 픽셀 값이 아닌, 문서의 전체 높이에 대한 백분율(%)로 동기화하도록 기능을 작성했었습니다.

그래서 처음엔 스크롤 위치를 절대적인 px 값으로도 동기화할 수 있도록 옵션을 추가해달라는 요청으로 이해했습니다. 하지만 사용자가 제시한 예시대로 재현해보기로 했고 여기서 문제를 발견할 수 있었습니다.

문제 분석

사용자가 제시한 문제를 재현하기 위해 두 개의 다른 높이를 가진 웹 페이지를 생성하고, 스크롤 동기화를 테스트할 수 있는 간단한 HTML과 JS 코드를 작성했습니다: https://codepen.io/jaem1n207/pen/bGyNPBE (Codepen 결과 화면의 Before 섹션 참고)

문제의 원인을 분석하기 위해 기존의 스크롤 동기화 로직을 천천히 살펴보았는데요. 기존 로직은 scrollTop 값을 scrollHeight로 나누어 스크롤 위치의 백분율을 계산하고 있었습니다. 그러나 이런 게산 방식은 clientHeight를 고려하지 않아 실제 스크롤 가능한 범위를 정확히 반영하지 못했습니다:

const scrollPosition = window.scrollY || document.documentElement.scrollTop || document.body.scrollTop || 0;
const scrollHeight = document.documentElement.scrollHeight;
const scrollYPercentage = scrollPosition / scrollHeight;

const nextScrollPosition = scrollYPercentage * scrollHeight;
window.scrollTo({ top: nextScrollPosition });

• scrollPosition: 스크롤바의 현재 위치를 나타냅니다.
• scrollHeight: 스크롤 가능한 전체 문서의 높이를 나타냅니다.

여기서 scrollPosition의 최대값은 scrollHeight에서 뷰포트(보이는 영역)의 높이를 뺀 값입니다. 이로 인해 백분율 계산이 잘못되어 스크롤 동기화가 정확히 이루어지지 않는 문제가 발생하던 것이었습니다.

예를 들어, scrollHeight가 3500인 문서가 있고 뷰포트의 높이가 1400이라고 가정하면 scrollY의 최대값은 2100입니다.

해결 방안

문제를 해결하기 위해, 스크롤 백분율을 계산할 때 clientHeight를 고려하여 실제 스크롤 가능한 높이를 사용하도록 로직을 수정했습니다:

const scrollPosition = window.scrollY || document.documentElement.scrollTop || document.body.scrollTop || 0;
const scrollHeight = document.documentElement.scrollHeight;
+ const clientHeight = document.documentElement.clientHeight;

- const scrollYPercentage = scrollPosition / scrollHeight;
// 스크롤 가능한 최대 높이에서 뷰포트 높이를 빼고, 현재 스크롤 위치를 나누어 백분율을 계산
+ const scrollYPercentage = scrollHeight === clientHeight ? 0 : scrollPosition / (scrollHeight - clientHeight);

- const nextScrollPosition = scrollYPercentage * scrollHeight;
// 다른 문서의 스크롤 위치를 계산할 때도 동일하게 뷰포트 높이를 고려
+ const nextScrollPosition = scrollYPercentage * (scrollHeight - clientHeight);
// 다른 문서의 스크롤 위치 조정
window.scrollTo({ top: nextScrollPosition });

이제 스크롤 가능한 범위를 기준으로 백분율을 계산하게 됩니다.

결과

이전 스크롤 로직과 변경 후 스크롤 로직은 코드펜에서 확인할 수 있습니다.

I'm seeing a lot of warnings like this:

In a recent development project, I began to encounter an array of warnings while bundling client output with Vite. Intrigued and somewhat concerned, I decided to delve deeper into the matter, to understand the origins and implications of these warnings.

When is this warning displayed:

Occurs when bundling client output with Vite.

Why is this warning displayed:

The crux of the issue was rooted in the fact that my project wasn't making use of Server Components, and therefore had no necessity to "support" the directive causing these warnings. The bundler, in its quest to create a seamless bundle, stumbled upon this directive at the start of a file it intended to include. Unfortunately, it found itself unable to hoist the directive across the entirety of the bundle and thus opted to remove it. This is where the warnings originated from.

The bundler, in its diligence, doesn't prefer to remove components without providing prior notice. As a result, it generates these warnings, to keep the developer informed about any changes it's making.

The cause of the warnings also traced back to my usage of the unbundled .mjs-version of React Query. Interestingly, this version now includes a 'use client' directive at the top of some files. While this initially seemed to be the issue, I realized it was actually a blessing in disguise. The .mjs version of React Query enables the bundler to perform tree shaking, thereby allowing it to discard any parts of React Query that aren't actively in use. This ensures that the final app-bundle is devoid of any unnecessary parts, resulting in a more streamlined and optimized bundle.

How can I solve this problem:

As for mitigating this barrage of warnings, a viable solution I found is to incorporate a Rollup onwarn filter, effectively hiding the warnings. However, it's important to remember that the warnings don't indicate a fault or problem, but are merely informational. You can find further information on this issue in this GitHub comment.

착각을 주는 애니메이션

싱크 중이라는 것을 표현하기 위해 애니메이션을 추가했지만 오히려 로딩 중이라는 착각을 불러일으킨다는 피드백이 있었음
어떻게 하면 이를 좋게 개선할 수 있을지 파악 중