Dorong Dorong 💻😴

이터러블(Iterable)

정의

• 반복 가능한 객체
• `for...of`, `스프레드(...)`, `디스트럭처링 할당` 등에 사용 가능
• 이터러블은 Symbol.iterator 메서드를 가지고 있으며, 이 메서드가 이터레이터를 반환

예시

const arr = [1, 2, 3]; // 배열 (대표적인 이터러블) 
const str = "hi"; // 문자열도 이터러블 
const set = new Set([1, 2, 3]); // Set도 이터러블 
for (const val of arr) console.log(val); // 1, 2, 3

이터레이터(Iterator)

정의

• 이터러블을 실제로 순회하는 메커니즘
• `next()` 메서드를 가지고 있으며 `{ done: Boolean, value: any }`와 같은 형태의 객체를 반환
• `done: true` 가 될 때까지 순회

예시

const arr = [1, 2, 3]; 
const iterator = arr[Symbol.iterator](); 
console.log(iterator.next()); // { done: false, value: 1 } 
console.log(iterator.next()); // { done: false, value: 2 }
console.log(iterator.next()); // { done: false, value: 3 } 
console.log(iterator.next()); // { done: true, value: undefined }

이터러블  ↔  배열 메서드 활용

• 이터러블을 배열로 변환해 `map`, `filter` 같은 고차 함수 활용 가능

const set = new Set([1, 2, 3]); 
const doubled = [...set].map(x => x * 2); // [2, 4, 6]

장점

1. 일관된 반복 프로토콜 제공
   → for...of, 스프레드, 디스트럭처링 등 어디서든 활용 가능
2. 데이터 구조 확장 가능
   → 트리, 그래프 같은 사용자 정의 구조에서도 원하는 순서(DFS, BFS 등)로 순회 정의 가능
3. 유연성
   → 어떤 순서, 어떤 조건으로든 반복 동작을 직접 정의할 수 있음

한계

1. 성능 문제
   • 대규모 데이터 순회 시 next() 호출 비용 누적
   • 복잡한 구조일수록 접근 비용 증가
2. 메모리 사용량 증가
   • 이터레이터는 상태(state)를 저장해야 하므로 동시에 여러 개를 쓰면 메모리 부담

// 상태 누적 예시
  [Symbol.iterator]() {
    this.current = this.from;
    return this;
  },

  3. 배열 메서드 직접 사용 불가

• 이터러블 자체는 map, filter 같은 배열 메서드를 바로 쓸 수 없음 → 배열로 변환해야 함

개선방안

1. 제너레이터(Generator)
   • 이터러블+이터레이터를 쉽게 구현할 수 있는 문법
   • yield를 사용해 필요할 때만 값을 생성 (lazy evaluation)
   • 메모리 효율적
   • `function* numbers() { yield 1; yield 2; yield 3; } for (const n of numbers()) { console.log(n); // 1, 2, 3 }`
2. Lazy Evaluation 기법 활용
   • 전체 데이터를 한꺼번에 메모리에 올리지 않고, 필요한 순간에만 계산/반환

유사 배열(array-like object)

정의

• 인덱스와 `length` 프로퍼티를 가지고 있어 배열처럼 보이지만
• `next()` 메서드를 가지고 있으며 `{ done: Boolean, value: any }`와 같은 형태의 객체를 반환
• 반드시 `Symbol.iterator`가 구현되어 있는 것은 아님 → for...of, 스프레드 불가

예시

const obj = {0: 'a', 1: 'b', length: 2};
console.log(obj[0]); // 'a'
console.log(obj.length); // 2
// [...obj] // Error! 유사 배열은 스프레드 불가

변환 방법

Array.from(obj); // ['a','b']

주의할 점

• 유사 배열과 이터러블을 헷갈리기 쉬움
• 유사 배열이면서 이터러블인 경우도 존재
  • 예: arguments, NodeList, HTMLCollection 등
  • 이런 경우는 for...of나 스프레드(...) 사용 가능

관계 정리

이터러블(Iterable)
 └─ Symbol.iterator 메서드 존재
      └─ 반환 → 이터레이터(Iterator)
             └─ next() 호출로 실제 반복 수행
                 └─ { value, done } 반환

유사 배열(array-like)
 └─ 인덱스 + length만 존재
      └─ Symbol.iterator 없으면 for...of/스프레드 불가
      └─ Symbol.iterator 있으면 이터러블처럼 사용 가능 (예: arguments, NodeList)

정리

• 이터러블(Iterable): “반복할 수 있는 객체” (배열, 문자열, Set, Map 등)
• 이터레이터(Iterator): “실제로 반복을 수행하는 도구” (next() 사용)
• 관계: 이터러블은 Symbol.iterator를 구현해야 하고, 이 메서드가 이터레이터를 반환
• 강점: 일관된 반복 프로토콜, 다양한 구조 지원, 유연한 순회
• 한계: 대규모 데이터에서 성능·메모리 부담
• 보완: 제너레이터와 lazy evaluation 활용

TOAST UI - 터치와 클릭 이벤트 글에서 생긴 의문을 정리하기 위한 글입니다.

터치 이벤트를 달았는데 왜 클릭 이벤트까지 발생하나요?

• 터치가 발생하면 내가 별도로 클릭 이벤트를 달지 않았어도 click 이벤트가 중복으로 발생해 버립니다.
  왜 이런 동작이 일어나는 걸까요?
• 웹은 오랫동안 마우스 클릭 중심으로 설계되고 발전했습니다.
• 지금까지 많은 사이트가 오직 click 이벤트만 듣고 동작하도록 만들어져 있기 때문에, 모바일 브라우저는 호환성 유지를 위해 터치 시 자동으로 click 이벤트도 함께 발생시키도록 설계돼 있습니다. 그렇기에 터치스크린 환경에서도 기존 마우스 중심 사이트들이 별도 수정 없이 동작할 수 있습니다.

터치 이벤트 후 click 이벤트가 발생하는 게 왜 편의일까요?

• 여러 자료에서 이걸 편의라고 하던데 표현이 너무 포괄적으로 느껴져서 그런지 처음에는 이해가 되지 않았습니다. 아래는 제가 찾아본 후 이해한 내용입니다!
  
  • 브라우저는 이 사이트가 터치/클릭 둘 다 지원하는지, 어떤 식으로 의도했는지 알 방법이 없습니다.
  • 그래서 일괄적으로, 터치가 발생하면 반드시 click 이벤트도 같이 발생하도록 만들었습니다.
  • 브라우저는 저희가 만든 사이트만 띄우는 것이 아니라 아주 많은 사이트를 동시에 지원해야 합니다. 모바일 도입 초기엔 대부분 오직 클릭 이벤트만 사용했기 때문에, 터치 이벤트만 발생시 클릭 이벤트가 발생하지 않으면 옛날 사이트들이 모바일에서 먹통이 될 수 있다고 판단했습니다. 그래서 터치 시 자동으로 클릭 이벤트도 발생시키도록 설계되었고 기존 클릭 기반 사이트와의 호환성도 보장합니다.

React 등에서도 클릭 이벤트가 발생할까요?

• 많이 사용하는 React 기준으로 여기서도 브라우저의 이벤트 위임 메커니즘을 그대로 따랐습니다. 브라우저의 네이티브 이벤트 시스템을 그대로 활용했기 때문에 동일한 동작이 발생해요.
• 브라우저가 터치 이벤트 후 자동으로 마우스와 클릭 이벤트를 생성하는건 React 이전 단계에서 일어납니다.
• React는 브라우저의 네이티브 이벤트를 감싸는 SyntheticEvent를 사용하고 있어요. 하지만 브라우저의 기본 이벤트 동작은 변경하지 않습니다.
• 그리고 이벤트 위임을 사용하지만 이건 이벤트 처리 방식을 최적화하는 것이지 브라우저의 기본 이벤트 동작을 바꾸는게 아닙니다.
• 관련 토론인 GitHub 이슈 #9809를 정리해보면,
  
  • preventDefault() 무효화: React의 합성 이벤트에서 e.prevnetDefault()가 클릭 이벤트 방지에 실패
  • 네이티브 DOM API는 작동: addEventListener로 직접 등록하면 preventDefault()가 정상 동작
  • 브라우저별 차이: Chrome, Firefox, Safari에서 각각 다르게 동작 (추가 확인이 필요)
• 위의 내용은 관련 이슈를 직접 보고 상세 내용과 이유를 확인해 보는걸 추천드립니다!
• 이슈에서 제시된 해결책들도 짧게라도 정리해 보겟습니다.

// 방법 1: 네이티브 DOM API 사용
componentDidMount() {
  this.elem.addEventListener('touchstart', e => {
    e.preventDefault(); // 이건 작동함
  });
}

// 방법 2: 플래그 사용
handleTouchStart(event) {
  this.hasBeenTouchedRecently = true;
  setTimeout(() => { 
    this.hasBeenTouchedRecently = false; 
  }, 500);
}

handleMouseDown(event) {
  if(this.hasBeenTouchedRecently) {
    return; // 터치 후 마우스 이벤트 무시
  }
}

 <meta name="viewport" content="width=device-width">

오늘은 별도 컨텍스트를 가진 새 창을 띄우는 개발을 하며 알게된 내용을 정리해보려 합니다.

왜 아직도 window.open이 필요한가?

시작전에 팝업과 모달의 본질적 차이부터 알아보겠습니다.

팝업창

• 브라우저가 완전히 분리된 새 창(또는 탭)으로 동작
• 브라우저의 팝업 차단 기능에 영향을 받고
• 부모 페이지와 별도의 브라우저 컨텍스트를 갖습니다.
• 창의 위치, 크기, 스크롤바 등 다양한 속성을 제어할 수 있습니다.
• 부모 창이 새로고침되거나 이동해도 팝업은 유지됩니다.
• 브라우저 팝업 차단 기능에 의해 사용자가 팝업을 못 볼 수 있으므로, 반드시 필요한 경우에만 사용하는게 좋습니다. 그 외에는 모달이 권장됩니다.

모달창

• 기존 페이지 위에 오버레이 레이어로 구현
• 부모 페이지에 종속되어 있습니다.
• 브라우저의 팝업 차단 기능과 무관합니다.
• 부모 페이지가 이동 또는 새로고침되면 모달도 사라집니다.
• 별도의 브라우저 컨텍스트가 아니므로, 외부 도메인 페이지를 직접 포함할 수 없습니다. 이때 iframe을 생각하실 수 있는데 보안상 제약이 많아 불편합니다.

React에서는 상태(state)를 활용한 조건부 렌더링으로 팝업을 구현하거나, Toss의 오버레이 키트(Overlay Kit)같은 라이브러리를 사용하는 경우가 많습니다.

그런데도 여전히 window.open()이 편리하거나 필요한 상황이 있습니다.

1. 외부 도메인과의 연동: OAuth 인증, 결제 시스템 연동 등 다른 도메인의 페이지를 열어야 할 때
   
   • OAuth 인증이나 외부 결제 시스템 연동 시, 보안이나 사용자 인증 후 콜백등의 UX 적인 이유로 별도 창이 필요합니다.
   • 이때 window.open()을 사용하면 부모-자식 창 간 통신이나 창 닫힘 감지 등의 처리가 쉬워져요.
   • 모달로는 외부 도메인 페이지를 iframe으로 띄우는 것이 CORS, X-Frame-Options 또는 Content-Security-Policy 등의 보안 정책등의 이유로 불편합니다.
2. 프린트 기능: 특정 콘텐츠만 프린트하기 위한 별도 창이 필요할 때
   • 새 창에 해당 콘텐츠만 렌더링하고 window.print()를 호출하는 방식이 많이 사용됐습니다.
   • 모달이나 오버레이로는 전체 페이지의 일부만 깔끔하게 인쇄하는 인쇄 범위 제어가 어려워 기존 페이지 전체가 인쇄됩니다.
   • 따라서 새 창이 가장 간단하고 확실한 방법이라 생각합니다.
3. 멀티태스킹 UX: 사용자가 두 화면을 동시에 보며 작업해야 할 때
   • 두 개의 창을 동시에 화면에 띄워 상호 비교 작업하려면 창 분리가 필요합니다.
   • 모달은 항상 부모 창 위에 떠 있기 때문에 두 화면을 동시에 볼 수 없습니다.
   • 따라서 새 창을 띄우는 것이 유일한 방법입니다.
4. 레거시 시스템 통합: 기존 시스템과의 호환성을 위해 필요한 경우
   • 기존 시스템에서 팝업 창을 통한 데이터 교환이나 인증 등의 구조가 이미 window.open()에 맞춰져 있다면, 이를 모달로 대체하는 경우 호환성 이슈가 발생할 수 있습니다.
5. 별도 윈도우 기능: 부모 창의 새로고침이나 이동에도 유지되어야 하는 독립적 기능
   • 모달이나 SPA 컴포넌트로는 구현이 불가능합니다.
   • 새로운 팝업창만이 완전히 별도의 브라우저 컨텍스트를 제공합니다.

이런 경우에는 window.open()을 사용해야 하는데, 안전하고 올바른 방법을 알아보겠습니다.

window.open('javascript:focus()', 'myPopup', 'width=800,height=600');

겉보기엔 잘 작동할 수 있지만, 이 방식은 보안상 문제가 있으며 공식적으로 권장되지 않는 방식입니다.

이번 글에선 그 이유에 대해 적어보려합니다! 또한 어떤 방식이 안전하고 표준에 부합하는지도 알아보겠습니다.

javascript:focus() 방식의 위험성

이 방식은 javascript: URL 스킴을 이용해 새 창을 열면서 focus() 함수를 실행하려는 의도입니다. 하지만 이런 방식은 보안상 취약합니다.

MDN 공식 문서에서는 다음과 같이 명확히 경고하고 있습니다.

"Use of javascript: URLs on the web is discouraged as it may lead to execution of arbitrary code, similar to the ramifications of using eval()."

또한, ESLint에서도 no-script-url 규칙을 통해 javascript: URL 스킴 사용을 금지하거나 경고하고 있습니다. 이는 코드가 외부 입력에 의해 조작되거나 악용될 수 있기 때문입니다.

요약하자면

• 보안상 위험 (임의 코드 실행 가능성)
• XSS(크로스 사이트 스크립팅) 공격의 벡터가 될 수 있음
• 최신 브라우저 및 린터 차단 대상
• 유지보수와 의도 파악이 어려움

표준적이고 안전한 방법: about:blank 또는 빈 문자열

팝업을 안전하게 열고 싶다면, 권장되는 방식은 다음과 같습니다.

const popup = window.open('about:blank', 'myPopup', 'width=800,height=600');
if (popup) {
  popup.location.href = '/your-target-page';
  popup.focus(); // 필요 시 포커스 이동
}

또는 아예 빈 문자열도 사용할 수 있습니다.

const popup = window.open('', 'myPopup', 'width=800,height=600');

이 방식은 다음과 같은 장점이 있습니다.

• 보안상 안전함
• 표준 웹 API 사용법을 준수
• 코드 의도가 명확함
• 공식 문서(MDN, W3C 등)에서도 권장하는 방식

javascript:focus()의 목적과 오해

많은 개발자들이 javascript:focus()를 초기 URL로 넣는 이유는 다음과 같습니다.

• 빈 창을 열 때 팝업이 차단되는 현상을 우회하려고
• 창을 연 직후 자동으로 포커스를 주려고

하지만 최신 브라우저는 다음과 같은 특성이 있습니다.

1. 사용자 클릭 이벤트 내부에서 window.open()을 호출하면 대부분 차단하지 않습니다
2. 포커스가 필요하다면 popup.focus()를 명시적으로 호출하는 것이 훨씬 더 명확하고 안전합니다
3. 일부 최신 브라우저에서는 보안 정책으로 인해 javascript: URL이 작동하지 않을 수 있습니다

즉, javascript:focus()는 과거에는 통했을지 몰라도, 현대 웹 보안 환경에서는 적절하지 않은 방식입니다.

URL 객체와 javascript: URL은 완전히 다릅니다

혹시 URL이라는 단어 때문에 다음과 같은 문법을 떠올리신 분도 계실 텐데요?!

const url = new URL(window.location.href);
const tag = url.searchParams.get('tag');

이건 URL 정보를 분석하고 조작하기 위한 객체로, 주소 파싱을 위해 아주 유용하게 쓰입니다. 예를 들어 쿼리 파라미터 추출, 경로 조작 등에 자주 사용됩니다.

반면 'javascript:...'는 브라우저에 자바스크립트를 직접 실행하라고 명령하는 스킴이기 때문에, 목적도 쓰임도 완전히 다릅니다.

항목설명 - 사용 용도

부모-자식 창 관계와 제어

window.open()으로 열린 팝업은 부모 페이지와 밀접한 관계를 가집니다. 이를 활용하거나 주의해야 할 점이 있습니다.

부모 페이지에서 자식 창 제어하기

팝업을 연 부모 페이지는 반환된 참조를 통해 자식 창을 완전히 제어할 수 있습니다.

const popup = window.open('about:blank', 'myPopup');
// 자식 창 내용 변경
popup.document.body.innerHTML = '<h1>부모가 변경한 내용</h1>';
// 자식 창 크기/위치 조정
popup.resizeTo(500, 300);
popup.moveTo(100, 100);
// 자식 창 종료
popup.close();

자식 창 종료 시나리오

여러 상황에서 자식 창이 자동으로 종료될 수 있습니다.

1. 부모 페이지 이동 또는 새로고침 시

   // 페이지 이동 전에 자식 창 닫기
   window.addEventListener('beforeunload', () => {
     if (popup && !popup.closed) {
       popup.close();
     }
   });

    

2. 다른 SPA 라우트로 이동 시
    

   // React Router 등의 라우트 변경 이벤트에 연결
   router.beforeEach((to, from, next) => {
     if (window.myPopup && !window.myPopup.closed) {
       window.myPopup.close();
     }
     next();
   });

자식 창이 부모 페이지 감지하기

자식 창에서는 부모 창의 존재와 상태를 확인할 수 있습니다.

// 자식 창에서 부모 창 확인 및 대응하기
if (window.opener && !window.opener.closed) {
  // 부모 창이 존재하고 열려있음
  console.log('부모 창 URL:', window.opener.location.href);
} else {
  // 부모 창이 닫혔거나 없음
  console.log('독립적으로 실행 중');
}

브라우저 호환성과 추가 고려사항

최신 브라우저들은 window.open()에 대해 점점 더 엄격한 정책을 적용하고 있습니다.

• Chrome, Safari: 사용자 제스처(클릭 등) 없이 window.open()을 호출하면 차단됩니다
• Firefox: 팝업 차단 설정에 따라 동작이 달라집니다
• 모바일 브라우저: 많은 모바일 브라우저에서 팝업 자체를 제한적으로 지원합니다

따라서 팝업 대신 모달이나 인라인 콘텐츠를 고려하는 것도 좋은 대안이 될 수 있습니다:

// 특별한 이유가 없다면 팝업 대신 모달을 고려해보세요
document.getElementById('openModal').addEventListener('click', () => {
  document.getElementById('myModal').style.display = 'block';
});

요약 및 결론

• 모던 프레임워크가 주류인 지금도 OAuth, 결제 연동, 프린트 기능 등을 위해 window.open()이 필요한 상황이 있습니다.
• javascript:focus() 방식은 보안상 위험하고, MDN 및 ESLint에서도 사용을 권장하지 않습니다.
• 팝업을 열 때는 about:blank나 빈 문자열을 사용하고, 그 이후에 popup.location.href와 popup.focus()를 사용하는 방식이 가장 표준적이고 안전합니다.
• 부모 페이지에서는 팝업 창을 완전히 제어할 수 있으며, 페이지 전환 시 팝업 창을 적절히 관리(종료)해야 합니다.
• React 같은 프레임워크에서는 useRef와 useEffect를 활용해 팝업의 생명주기를 컴포넌트와 연동할 수 있습니다.
• URL 객체와 javascript: URL은 개념이 완전히 다르므로 혼동하지 마세요.

특정 상황에서는 window.open이 여전히 적절한 선택일 수 있습니다. 이런 경우에도 더 안전한 방식으로 코딩해 보시는 건 어떨까요?!

궁금하신 점이 있다면 언제든지 댓글로 남겨주세요! 

시간이 지난 후, 코드를 리팩토링 하는 과정에서 작업 이유에 대해 찾아보기 위해 TIL 카테고리를 만들었습니다!

오늘은 Vanilla JavaScript로 웹 컴포넌트를 만들던 중 마우스 다운(mousedown) 이벤트와 마우스 업(mouseup) 이벤트, 그리고 클릭(click) 이벤트 간의 충돌이 발생해, 각 이벤트의 동작이 서로 독립적으로 실행될 수 있도록 조정한 내용을 간단히 기록하려합니다.

문제 상황: 두 경우의 이벤트 핸들링

사용자가 상품 버튼을 클릭했을 때, 다음과 같은 시나리오를 생각했습니다:

1. 잔액이 부족한 경우
2. 잔액이 충분한 경우
3. 마우스 다운/업 이벤트와 클릭 이벤트의 상호작용

이러한 상황에서 마우스 업 이벤트의 동작에 가려져 클릭 이벤트가 동작하지 않는 상황이 발생했어요.

해결 방법: 조건부 이벤트 등록

먼저 기존 코드입니다.

  setEvent() {
    const { onSelect, onMouseDown, onMouseUp } = this.props;

    if (onSelect) {
      this.addEvent('click', '.product-button', (e) => {
        const button = e.target.closest('.product-button');
        if (!button) return;
        const productId = Number(button.dataset.id);
        onSelect(productId);
      });
    }

    if (onMouseDown) {
      this.addEvent('mousedown', '.product-button', onMouseDown);
    }

    if (onMouseUp) {
      this.addEvent('mouseup', '.product-button', onMouseUp);
    }
  }

변경된 코드입니다.

setEvent() {
  const { onSelect, onMouseDown, onMouseUp, product } = this.props;

  // 가격이 부족할 때만 mousedown/mouseup 이벤트 등록
  if (onMouseDown && this.state.balance < product.price) {
    this.addEvent('mousedown', '.product-button', () => {
      onMouseDown(product);
    });
    this.addEvent('mouseup', '.product-button', () => {
      onMouseUp();
    });
  } else {
    // 가격이 충분하거나 조건에 맞지 않으면 click 이벤트만 등록
    this.addEvent('click', '.product-button', (e) => {
      const button = e.target.closest('.product-button');
      if (!button) return;
      const productId = Number(button.dataset.id);
      onSelect(productId);
    });
  }
}

핵심 접근 방식

1. 조건부 이벤트 등록: 현재 상태에 따라 적절한 이벤트를 동적으로 바인딩합니다.
2. 이벤트 위임: closest() 메서드를 활용해 이벤트 버블링을 효율적으로 처리합니다. (글에는 없지만 component.js에서 처리)
3. 상태 기반 로직: balance와 product.price를 비교하여 이벤트 흐름을 제어합니다.