왜 이 글을 작성하게 되었나?평소 React 개발하며 Hook을 코드 분리와 책임 분리 등을 위해 자연스럽게 사용해 왔습니다. Hook이라는 기능이 생긴 후로 정말 편리하게 활용해왔는데요, 최근 면접에서 "useABC 같은 Custom Hook이 어떻게 동작하는 건지, 자바스크립트의 어떤 원리로 가능한 건지" 질문을 받았을 때 제대로 답변하지 못했습니다. 😂사용하기만 해봤지 내부 동작 원리는 깊이 생각해보지 못했던 것 같습니다. 그래서 이번 기회에 어떤 원리로 동작하는지 정리해보겠습니다.Hook이란?Custom Hook의 동작 원리를 이해하기 전에, 먼저 Hook이 무엇인지 간단히 살펴보겠습니다. React Hook은 2019년 React 16.8에서 도입된 기능으로, 함수형 컴포넌트에서도 상태와 생명..

유령 의존성이란?개발 하다 보면, 어떤 패키지는 package.json에 명시적으로 추가한 적이 없는데도 프로젝트에 사용할 수 있는 경우가 있습니다. 또는 npm install을 했을 때 예상보다 더 많은 패키지가 설치되는 경우가 있습니다. 이런 현상을 유령 의존성이라고 부릅니다.📌 유령 의존성이 발생하는 주요 원인직접 설치하지 않은 패키지가, 하위 패키지를 통해 설치되면서 마치 직접 의존하는 것처럼 보이는 경우패키지 매니저에 따라 의존성 트리가 다르게 구성되는 경우=> npm은 90개의 하위 폴더, pnpm은 9개의 하위 폴더가 생김 📌 예제 재현mkdir npm-test && cd npm-testnpm init -ynpm install react react-dom typescript eslintm..

여러분은 언제 주석을 작성하시나요? 🤔 이전에 회사에서 후임 개발자분께서 이런 질문을 한 적이 있습니다. "코드에 함수마다 주석이 달려 있는데, 어떤 함수에는 설명이 있고, 어떤 함수에는 없어요. 언제 주석을 작성해야 하는 거죠?"라는 질문이었죠.// 회사 컨벤션/****/function abc () {...}/*** 이건 글쓰는 함수 입니다.*/function abc () {...}당시에는 회사 코드 컨벤션에 따라 주석을 작성해 왔고, '여기에는 주석이 있으면 좋겠다'라는 주관적인 기준에 의존하고 있었기 때문에, 명확히 대답하기 어려웠습니다. 결국 "조건이 3개 이상일 때 작성하는 것 같다"는 애매한 답변을 했던 기억이 납니다. 😂이 질문 덕분에 주석을 언제 작성해야 하는지 더 깊이 고민해 볼 기회..

웹접근성과 웹 표준을 지키며 개발하는 것은 모든 사용자에게 동등한 웹 경험을 제공하기 위해 필수적입니다. 이러한 원칙을 따르면서도, 간격 조정과 같은 디자인 목적으로 빈 태그(나 등)를 사용하는 경우가 종종 있습니다. 하지만 이런 실천은 웹접근성과 웹 표준을 저해할 수 있으며, 다음과 같은 이유로 권장되지 않습니다. 웹접근성 저해웹접근성은 모든 사용자가 웹 콘텐츠와 상호작용할 수 있게 하는 것을 목표로 합니다. 스크린 리더와 같은 보조 기술을 사용하는 사용자는 빈 태그로 인해 혼란을 겪을 수 있습니다. 이러한 태그들은 시각적으로는 보이지 않지만, DOM에는 존재하기 때문에 보조 기술이 불필요한 정보를 인식하게 만들 수 있습니다. 따라서, 빈 태그 사용은 중요한 정보의 전달을 방해하며 웹접근성을 저해할 ..

Non-null Assertion Operator란 무엇인가?TypeScript에서 Non-null assertion operator (!)는 컴파일러에게 어떤 값이 null이나 undefined가 아님을 단언하는 방식입니다. 이 연산자는 변수 뒤에 !를 붙여 사용하며, 이를 통해 TypeScript의 엄격한 null 검사(strict null checks)를 우회할 수 있습니다. 이는 개발자가 해당 변수가 절대 null이나 undefined가 아닐 것이라는 확신이 있을 때 유용합니다. 간단한 사용예시let myVar: string | null = "Hello, TypeScript!";// myVar이 null이 아님을 단언하고 사용console.log(myVar!.toUpperCase()); 위 예제에..

문제 제기똑똑한 컴포넌트가 어디까지 똑똑해야 할지는 소프트웨어 개발의 중심 문제 중 하나입니다. 특히 MSA 환경에서 이 질문은 더욱 중요한데, 서비스를 가능한 잘게 쪼개는 전략이 효율적인 작업을 위한 핵심이 되기 때문입니다. 최소한의 컴포넌트로 기능을 분리하려는 시도는 깔끔하고 독립적인 코드베이스를 유지하는 데 도움이 됩니다. 그러나, 이러한 접근이 항상 만능은 아니라는 것을 실제 경험을 통해 깨달았습니다. 실전 경험예를 들어, 사용자의 이름을 표시하는 Username 컴포넌트를 개발하는 과정에서, 각각의 컴포넌트가 자체적으로 API를 호출하도록 설계했습니다. 이론적으로는 재사용성을 극대화하는 좋은 전략처럼 보였습니다.// Username 컴포넌트 예시function Username({ userId }..