프론트엔드 공부 블로그 프론트엔드 공부 블로그

TypeScript를 쓰다 보면 객체의 키와 값을 정확하게 제한하고 싶을 때가 많다. 예를 들어 이런 유니온 타입이 있다고 해보자.type Zombie = "dead" | "alive"; 그리고 이 Zombie 상태에 대해 boolean 값을 매핑하고 싶다.이때 흔히 떠올리는 방법은 Record를 쓰는 것이다. 방법 1 -> 타입을 직접 지정하는 방식const obj: Record = { dead: false, alive: true,};깔끔해 보이고, 얼핏 보면 문제 없어 보인다.dead, alive 외의 키는 못 들어가고값도 boolean으로 제한된다그런데 여기에는 은근히 중요한 단점이 숨어 있다.satisfies를 보고나면 알 수 있다. 방법 2 -> as const satisfies를 사용하는..

프론트엔드 개발하다 보면 가끔 이런 경험을 한다.DOM에는 분명히 버튼이 보이는데 querySelector가 안 된다CSS를 아무리 써도 스타일이 안 먹는다DevTools에는 있는데 코드로는 접근이 안 된다이런 경우엔, Shadow DOM을 의심해볼 수 있다. Shadow DOM이란? 👻Shadow DOM은 간단히 말하면DOM 안에 또 하나의 “격리된 DOM 트리”를 만드는 기술이다. 일반적인 DOM 구조가 이런 식이라면 ClickShadow DOM을 쓰면 이렇게 된다 #shadow-root Click중요한 포인트는 다음과 같다#shadow-root 내부는 외부 DOM과 격리CSS, JS 접근 모두 기본적으로 차단캡슐화된 컴포넌트를 만들기 위한 구조 왜 굳이 이런 걸 만들었을까? 🤔문제는 “..

웹이나 앱에서 문자열을 다루다 보면 가끔 이런 이상한 상황을 만난다.화면에 똑같이 보이는데 문자열 비교가 실패함파일명이 같아 보이는데 OS마다 다르게 취급됨검색이 안 되거나, 중복 체크가 통과됨이 문제의 원인은 종종 유니코드 정규화(Normalization), 그중에서도 NFC와 NFD의 차이에 있다. 유니코드 정규화란?유니코드는 같은 글자를 여러 방식으로 표현할 수 있다.예를 들어 é는 다음 두 가지 방식으로 표현 가능하다.1️⃣ NFC (Normalization Form C)하나의 코드 포인트로 결합된 형태é → U+00E92️⃣ NFD (Normalization Form D)기본 문자 + 결합 문자로 분리된 형태e + ́ → U+0065 + U+0301👉 눈에는 똑같이 보이지만, 내부 문자열은 ..

웹 개발을 하다 보면 브라우저에서 “왜 로컬에선 되는데 올라가면 안 돼?”, 혹은 “HTTPS면 예외인데 HTTP면 막힌다?” 같은 상황을 자주 만나게 된다.특히 API나 라이브러리 문제라고 생각하고 헤매다가 사실은 보안 정책 차이 때문에 기능 자체가 차단된 경우가 많다.이 글에서는 FE 개발자가 꼭 알아야 할 HTTPS vs HTTP에서 지원 여부가 갈리는 기능들을 한 번 정리해보려고 한다. 왜 이런 문제가 생길까? 🤔HTTP는 암호화가 없고 도청/변조가 쉬운 프로토콜이다.그래서 브라우저는 보안에 민감한 API들(사용자 데이터, 클립보드, 위치 등)을 “HTTPS에서만 안전하게 쓰도록” 제한한다. 즉,👉 보안 리스크가 있는 기능은 HTTPS 필수👉 HTTP에서는 아예 접근 자체를 차단된다. 다음은..

백엔드 API와 프론트엔드가 커뮤니케이션할 때, 수동으로 타입·클라이언트 코드를 만드는 건 이제 너무 비효율이다.그래서 등장한 것이 OpenAPI 스펙(OpenAPI/Swagger) 기반 코드 생성 도구다.이런 도구들은 OpenAPI 스펙을 읽어서…타입 정의 자동 생성fetch/axios 기반 API 호출 함수 생성React Query/SWR 훅 생성Mock 데이터/테스트 코드 생성까지 해준다 !즉 API 계약(contract)을 코드로 직결시키는 워크플로우를 만든다.이번 글에서는 그런 도구 중에서 대표적이고 커뮤니티 논의도 활발한 3개를 골라서 정리했다. 1️⃣ Orval — “생산성 최우선 OpenAPI TS 생성기”공식 --> https://orval.dev/Github Stars / NPM 인기 ..

### 파트 2 - chapter 5 변수의 비밀 생명주기 변수 선언 위치에 따른 작동 방식의 차이와 사용 여부스코프 아래에 있더라도, 스코프 시작 부분에서 변수의 가시성이 확보된다 -> 호이스팅function 함수 선언문의 경우 고유 특성인 함수 호이스팅이 있다.함수 선언문으로 함수가 선언되면, 함수 이름에 해당하는 식별자가 스코프 최상단에 선언되고, 함수 참조로 해당 값이 자동 초기화 됨따라서 함수 선언문은 스코프 내 어디서든 호출 가능함수 선언문 및 var를 사용한 선언 변수의 호이스팅 -> 이름 식별자가 블록 스코프가 아니라, 가장 가까운 함수 스코프에 등록됨 (함수 스코프가 없으면 전역 스코프) 함수 표현식에서는 함수 호이스팅이 적용되지 않음var로 선언한 변수는 호이스팅도 되고 여기에 더해서 ..

디버깅은 짜증나는 작업이고, 긴급 대응이고, 원인을 못 찾으면 막막하고 답답하기도 하다.하지만 많은 저명한 개발자들이 공통적으로 말하는 것이 있다.디버깅을 잘하는 개발자는 기능을 만드는 것보다 문제를 추적하는 과정에서 더 발전한다.Brian Kernighan 은 아래와 같이 말했다고 한다.“코드를 이해하는 것보다 디버깅하는 것이 더 어렵다.그러므로 디버깅할 수 있을 만큼 이해할 수 있도록 코드를 작성해야 한다.”즉 디버깅 능력 = 단순 기술이 아니라 소프트웨어를 다루는 철학이다. 이번 글에서는 FE 개발을 하고 있는 나의 관점에서 React 및 JS 웹개발의 디버깅 방법들에 대해서 좀 정리해보려고 한다. console.log — 여전히 가장 빠른, 가장 저렴한 디버깅콘솔 로그는 구식이라고 느껴지지만, 여..

### 파트 2 - chapter 4 전역 스코프 최신 JS 프로그램에서는 대부분 코드를 전역이 아닌 함수/모듈에 작성한다다만, 렉시컬 스코프를 이해하고 전역 스코프에 접근하며 사용할 줄 아는 것도 중요하다여러 파일로 분리된 JS 파일을 JS 엔진은 어떻게 실행 시점에 하나로 연결시키는가? (브라우저 기준)ES 모듈을 사용하면, 파일을 각자 하나씩 로딩함. 로딩 후 import 문으로 다른 모듈을 참조하며 이때 스코프는 공유 X 배타적으로 협력함구축 과정에 번들러가 관여하는 경우, 파일 전체가 하나로 합쳐져 브라우저및 JS엔진에 전달된다. 브라우저 및 JS 엔진은 하나의 거대한 JS 파일만 처리한다. 이 경우엔 파일 내 코드 조각끼리 참조할 때 사용할 이름 등록 등 메커니즘이 추가로 필요해진다.번들러는 ..