Yuu.log

리액트 Conext API에 대해 배웠던 내용을 기록하고자 하는 포스트입니다. 해당 포스트는 다음과 같은 목차로 진행됩니다. 목차 들어가기 전 Context API는 상태관리 도구가 아니다? 의존성 주입이란? Context API로 의존성 주입하기 의존성은 교체 가능해야 한다. Context API로 암시적 종속성을 명시적으로 만들자 마무리 레퍼런스 들어가기 전 해당 포스트는 Context API의 기초적인 부분을 다루지 않기 때문에 Context API에 대해 기초적인 지식이 필요합니다. 추가적으로 리액트 쿼리에 대한 내용이 있으므로 리액트 쿼리에 대한 배경 지식도 있으면 더욱 좋습니다. 아직 Context API를 모르신다면 아래의 링크를 통해 리액트 공식문서 보며 Context API를 배워보세요🙂..

상태 관리 라이브러리의 필요성 리액트에서 컴포넌트 간 데이터를 주고 받을 때 상위 컴포넌트에서 하위 컴포넌트로 “props”를 전달받습니다. 하지만 이렇게 “props”를 전달하는 방법은 상위 컴포넌트에서 하위 컴포넌트로 데이터를 전달할 때 여러 컴포넌트를 거치게 되면서 특정 컴포넌트는 해당 데이터를 필요하지 않아 “props”를 하위 컴포넌트로 전달하는 용도로만 쓰이는 컴포넌트들이 생기게 됩니다. 이러한 현상을 “Props Drilling”이라고 합니다. 그림으로 살펴보면 더 명확하게 이해하실 수 있을 겁니다. 위의 이미지를 보면 색이 칠해져 있는 요소는 데이터가 필요한 컴포넌트입니다. 색이 칠해져 있지 않은 요소는 데이터가 필요 없는 컴포넌트입니다. 즉, 색이 칠해져 있지 않은 컴포넌트는 데이터가 필..

Context란? 리액트에서 두 개 이상의 컴포넌트 간의 데이터를 주고 받기 위해 상위 컴포넌트에서 하위 컴포넌트로 "props"를 전달해줍니다. 마찬가지로 "Context"도 "props"가 아닌 또 다른 방법으로 컴포넌트 간에 값을 전달하는 방법입니다. 즉, 컴포넌트간 값을 공유하는 여러 방법 중 하나인 셈이죠. 왜 Context를 사용하죠? "데이터를 주고 받을 때 props를 사용한다면서요...!? 그럼 왜 Context가 필요하죠? "라는 의문이 들 수도 있습니다. 아래의 이미지를 봅시다. 색이 칠해져 있는 요소는 데이터가 필요한 컴포넌트입니다. 색이 칠해져 있지 않은 요소는 데이터가 필요 없는 컴포넌트입니다. 이미지를 다시 한번 보면 색이 칠해져 있지 않은 컴포넌트는 데이터가 필요하지 않지만 ..

컴포넌트(Component)란 프로그래밍에 있어 재사용이 가능한 각각의 독립적인 모듈을 뜻한다. 프론트엔드에서 UI를 구성할 때 컴포넌트 기반으로 개발하면 마치 레고 블록을 쌓는 것처럼 이미 만들어진 컴포넌트들을 조합하여 화면을 구성할 수 있다. 컴포넌트들은 기능 구현 코드를 캡슐화하므로서 독립적으로 존재한다. 또한 재사용이 필요한 컴포넌트의 기능을 추상화하여 구현하므로서 재사용성에 매우 용이하다. 이러한 독립성과 재사용성으로 재사용을 원하는 어느곳이든 코드 충돌에 대한 걱정 없이 화면 구성이 가능하다는 큰 장점이 있다. 그 외에도 컴포넌트 기반 개발의 장점은 관심사 분리, 응집도 있는 로직 등이 있으며 독립성이 큰 장점 중 하나인 만큼 변경에 대해 엄청 유연해 유지보수 측면에서도 정말 좋다. 현대 대부..

JSX란? JavaScript XML의 줄임말로 문자열도 아니고 HTML도 아니다. 리액트에서 UI를 구성할 때 사용하는 문법으로 JavaScript를 확장한 문법이다. JSX는 JavaScript가 확장된 문법이지만 브라우저가 바로 실행할 수 있는 JavaScript 코드가 아니므로 브라우저가 이해할 수 있는 JavaScript 코드로 변환을 해주어야 한다. 이때 이용하는 것이 바로 “Babel”이다. Babel은 JSX를 브라우저가 이해할 수 있는 JavaScript로 컴파일 후 브라우저가 읽고 화면에 렌더링한다. JSX 사용하기 // 하나의 태그를 return 해주면 된다. function App() { return (Hello World!) } // 혹은 const element = Hello, ..

create-react-app(CRA)의 문제점 CRA의 가장 큰 문제점은 초기 설치해야 할 종속 요소가 많아 용량이 상당히 커져 느리다. 또한 프로젝트 규모가 커지면 개발 및 빌드 시간이 늘어나며 개발자의 생산성이 떨어진다. CRA가 느린 이유는 내부적으로 웹팩을 사용하기 때문이다. 웹팩은 제공되기 전에 전체 응용 프로그램 코드를 번들로 묶는다. 즉, 사용하지 않는 설정이나 라이브러리까지 묶는다. 또한 대규모 코드베이스를 사용하면 개발 서버를 가동하는 데 더 많은 시간이 걸리고 변경 사항을 반영하는데 오랜 시간이 걸린다. Why vite? 느린 서버 시작 시간 Vite는 먼저 애플리케이션의 모듈을 종속성과 소스 코드의 두 가지 범주로 나누어 개발서버 시작 시간을 개선한다. esbuild를 사용해 종속성..