연구

내가 프론트엔드 공부를 처음 시작했을때부터 지금까지 꾸준히 고민하고 있는 문제가 둘 있다. 하나는 다음 포스트에서 풀어볼 'Button과 Link가 같은 스타일을 가질 때 어떻게 처리할 것인가'이고, 다른 하나는 input의 type을 text와 password로 바꿔주는 기능을 어떻게 처리할 것인지에 대한 것이다. 회원가입/로그인 폼을 생각해보면 거기에는 늘 비밀번호 입력을 감출 수 있는 눈동자 버튼이 있다. 이 눈동자 버튼을 누르면 input의 type이 password에서 text로 바뀌고, 다시 누르면 그 반대로 바뀌게 된다. 리액트를 배우고 한 시간 정도면 아마 누구라도 구현할 수 있을 지 모른다.그런데 이 눈동자가 토글된 상태는 어느 컴포넌트에 위치시키고, 눈동자 버튼은 어디에 배치해야 하며,..

나는 다른 라이브러리나 프레임워크의 공식 문서를 보면서 좋은 코드에 대한 아이디어를 얻는 편이다. 그리고 어제는 SolidJS를 살펴보다가 굉장히 재미있는 아이디어 하나를 캐치할 수 있었다.기존에 나는 특정 조건에 따라 컴포넌트를 다르게 처리함에 있어 아래와 같은 방식으로 코드를 작성했다. 아주 일반적인 방법이지만 컴포넌트와 JS 로직이 뒤섞여서 전체적인 코드의 통일감을 해친다는 인상을 받았다.export default function Comp() { const [count, setCount] = useState(0) const list = [1, 2, 3, 4, 5] return ( {count > 5 ? "숫자가 5보다 커요" : "숫자가 5와 같거나 작아요"} ..

생각보다 많은 사람들이 context API를 유사 전역상태관리 도구로 여기고 있고, 사실 나 역시도 처음에는 그렇게 알고 있었다. 그러나 잠깐 생각해보면 context API(이하 컨텍스트)의 존재 이유가 전역 상태 관리와는 전혀 상관이 없다는 걸 금방 알 수 있다. 아마 리액트 개발자라면 누구라도 이렇게 대답할 것이다. "컨텍스트를 사용하면 prop drilling을 방지할 수 있다."그렇다면 어째서 대부분의 사람들 ─ 혹은 리액트 1~3년차들 ─ 은 무의식 중에 컨텍스트를 유사 전역상태관리 도구라 여기고 있는 것일까? 여기에는 크게 두 가지 이유가 있다고 본다. 하나는 컨텍스트를 활용하는 예시가 대체로 state와 setState에 치중되어있기 때문이다. 심지어는 이를 새로운 커스텀 훅으로 감싸 진..

구조 분해 할당은 모던 자바스크립트 문법으로서 변수 선언 시 사용되며, 객체나 배열의 특정 요소를 선택적으로 변수에 할당하여 쉽게 사용할 수 있게 한다. 이를 통해 코드를 더 간결하고 읽기 쉽게 만들 수 있다.어느정도 숙련된 자바스크립트/타입스크립트 사용자라면 숨쉬듯이 사용하는 문법이기도 하다. 그런데 이 문법을 메모리 주소와 연관지어 생각해본 적은 한 번도 없었다. 적어도 오늘 어떤 일이 있기 전까지는.  나는 NestJs로 백엔드 작업을 하며 유저 기능을 위한 커스텀 가드를 만들고 있었다. 아주 간단한 작업이었으며, 나는 별 생각 없이 코드를 마무리지었다. 그리고 코드를 한번 쓱 보는데 뭔가 이상하다는 생각이 들었다. validateRequest 함수 내에서 this.authService.verify..

지난 포스트를 통해 Hydration Error에 대해 알아보고, 리액트 쿼리가 어떤 식으로 서버와 클라이언트의 랜더링 불일치를 방지하는지 알아보았다. 나는 이를 통해 어플리케이션이 시도하는 CRUD 중 Read에 대한 전략을 확정할 수 있었다. 몇 달 전의 프로젝트에 처음 도입해보았고, 이후로 조금씩 발전시키고 있다. 아직 완성 단계는 아니지만 어느 정도 틀은 잡혀있다. 이하의 내용은 페이지라우터에서 유효하다.  토큰 관리와 AXIOS액세스토큰과 리프레시토큰을 어디에 저장하고, 어떻게 가져다 쓰는지는 프론트엔드 개발자라면 누구나 늘 하는 고민일 것이다. 프론트 단독으로 결정할 수는 없고, 결국은 백엔드의 처리 방식에 따라 조금씩 다르겠지만, 일반적으로는 아래의 세 가지 방법 정도로 간추려지는 듯하다. ..

─리액트로 CSR 페이지를 만들다가 NextJs로 넘어오면, 마주했을 때 가장 당황스러운 개념 중 하나가 바로 Hydration Error(이하 HE)일 것이다. 일반적으로 이 HE를 설명할 때 "서버에서 랜더링 된 HTML과 클라이언트에서 React가 다시 렌더링할 때의 HTML이 다를 경우" 발생한다는 식으로 이야기하곤 한다.그런데 여기서 말하는 '다를 경우'라는 게 구체적으로 어떻게 다른 걸 의미하는지 오랫동안 제대로 이해하지 못했다. 정확히는 이해할 생각조차 하지 않았다고 하는 게 맞겠다. 서버와 클라이언트가 동일하면 HE는 발생하지 않을 거고, 그 외에는 크게 중요하지 않은 것처럼 느껴졌다. 이번 주에 나는 엑세스토큰과 리프레시토큰을 어떻게 관리하고, 어떻게 사용하는 게 best practice..

실행 컨텍스트자바스크립트 엔진(이하 JSE)은 코드를 실행하기에 앞서 코드를 평가하는 과정을 거친다. 이를 '실행 컨텍스트 평가'라고 부르고, 이후 선언문을 제외한 소스코드가 실행된다. 사실 클로저를 지원하는 대부분의 언어에서 이와 유사하거나 동일한 개념이 적용되어있다.실행 컨텍스트 평가 과정을 통해 JSE는 실행할 코드에 제공할 환경 정보들을 모아놓은 객체를 생성하게 된다. 이 객체가 바로 실행 컨텍스트(이하 컨텍스트)이다. 컨텍스트가 구성되면 JSE는 이를 콜 스택에 쌓아 올렸다가, 가장 위에 쌓여있는 컨텍스트와 관련 있는 코드를 하나씩 실행하는 식으로 전체 코드의 환경과 순서를 보장한다.하나의 컨텍스트를 구성할 수 있는 방법으로는 전역 공간, eval 함수, 함수 실행 등이 있다. 자바스크립트 파일..