블로그
최신 글과 인사이트를 둘러보세요
“추가/삭제/수정” 중 무엇을 막을지 먼저 정하고, 그에 맞는 preventExtensions → seal → freeze를 선택하면 된다.
CSS 커스텀 프로퍼티로 “값만 바꾸는 클래스”를 만들면, 스타일 조합이 늘어도 CSS는 늘지 않는다.
인스턴스마다 같은 메서드를 만들지 말고 프로토타입(prototype) 에 올려 공유하되, “외부 접근을 막아야 하는 값/초기화”는 IIFE(즉시 실행 함수) 로 스코프를 닫아라.
GET은 “URL에 싣는 방식”이 아니라 “읽기 전용 의미”다. 이 의미를 지키면 캐시·프리패치·재시도가 안전해지고, API가 예측 가능해진다. (RFC 9110)
JavaScript의 ==와 관계 연산자는 비교 전에 값을 “같은 타입처럼 보이게” 만들기 때문에, 예측 가능한 비교가 필요하면 ===/Object.is와 명시적 변환을 기본값으로 두는 편이 안전하다.
중복 제거·부분 추출·조건 검사처럼 “결과만 필요”한 작업은, 불필요한 순회/복사를 줄이는 API 조합이 핵심이다.
“없음(null/undefined)”과 “비어 있음(빈 문자열/0/false)”을 구분하려면 ??와 ?.를 쓰는 편이 안전하다. (MDN: Nullish coalescing (??))
기본은 const/let로 예측 가능성을 확보하고, var는 “의도적으로 함수 스코프/전역 브리징/재선언 허용”이 필요한 순간에만 제한적으로 쓴다.
여러 요청은 “언제 시작할지(동시성)”와 “언제/어떻게 보여줄지(출력 순서)”를 분리하면, 속도와 순서를 동시에 설계할 수 있다.
대량 데이터에서 “조건을 만족하는 결과 2개만” 뽑고 싶을 때가 있다. 이때 map → filter → map → filter → take를 각 단계마다 전체를 순회하면, 결과가 2개만 필요해도 매번 끝까지 돈다. CPU도 쓰고, 중간 배열도 계속 만든다.
프런트엔드에서 리스트를 다루는 코드는 생각보다 빨리 복잡해진다.