React Hydration Hydration는 , HTML 코드와 JS 코드를 서로 매칭시켜 동적인 웹사이트를 브라우저에 렌더링하는 기술이다. Next.js는 React에서 v16부터 제공하는 hydrate 기능을 사용해서 이러한 솔루션을 성공적으로 제공했다. 다른 말로는 서버 측에서 제공된 HTML을 재사용하고 해당 DOM 요소에 이벤트 리스너를 연결하는 작업이라고 할 수 있다. 는 ReactDOM의 함수인데 리액트 프로젝트 구축 시, 초반에 꼭 작성해주는 render 함수와 잠깐 비교해보면 는 을 수행하지 않지만 를 사용하여 을 수행할 수 있다. 는 와 동일하게 동작하지만 서버 측에서 전달받은 HTML을 사용한다. React Helmet React는 싱글 페이지 애플리케이션(Single Page Application, SPA)이라, React로 구축된 웹 사이트의 경우 크롤러들이 단 하나의 파일 만을 읽게 된다. 이처럼 싱글 페이지 애플리케이션의 경우 는 단점이 있다. 이러…

우선 Memoization이란? 기존에 수행한 연산의 결과값을 어딘가에 저장해두고 동일한 입력이 들어오면 재활용하는 프로그래밍 기법 이다. 을 절적히 적용하면 중복 연산을 피할 수 있기 때문에 메모리를 조금 더 쓰더라도 애플리케이션의 성능을 최적화할 수 있습니다. 그리고 React에서 컴포넌트를 다시 실행하는 경우는 아래와 같다. 부모 컴포넌트가 재실행될 때 props가 변경될 때 state가 변경되었을 때 React.memo란? React.memo는 High Order Components(HOC) 이다. 일반 컴포넌트는 인자로 받은 props를 UI에 활용하는 반면, HOC는 인자로 받은 컴포넌트를 새로운 별도의 컴포넌트로 만든다. HOC는 리액트의 API가 아니라, 리액트가 컴포넌트를 구성하는 데 있어서 일종의 패턴이다. 만약 React.memo를 사용하여 을 하여, 불필요한 렌더링을 방지할 수 있다. React.memo는 한다. 하지만, 함수형 컴포넌트가 함수 내부에서 us…

React에서 렌더링이란? 컴포넌트가 현재 props와 state의 상태에 기초하여 UI를 어떻게 구성할지 컴포넌트에게 요청하는 작업을 의미한다. 아래는 URL은 리엑트 렌더링을 이해하는데 도움이 되는 내글 React란? 그리고 사용하는 이유와 단점 Props와 State에 대해서 React는 왜 불변성을 유지해야되나? 렌더링을 만드는 방법 최초 렌더링이 끝난 이후에, 리액트가 리렌더링을 queueing 하는 방법에는 여러가지가 있다. 클래스 컴포넌트 this.setState() this.forceUpdate() 함수형 컴포넌트 useState()의 setter useReducer()의 dispatches 일반적인 렌더링 동작 리액트의 기본적인 동작은 부모 컴포넌트가 렌더링되면, 리액트는 모든 자식 컴포넌트를 순차적으로 리렌더링 한다는 것이다. 풀어서 말하면 컴포넌트를 렌더링 하는 작업은, 기본적으로, 하위에 있는 모든 컴포넌트 또한 렌더링 하게 된다. 일반적인 렌더링의 경우, 리…

Suspense란? 컴포넌트의 랜더링을 어떤 작업이 끝날 때까지 할 수 있다. (아직 개발적인 경험은 작지만, 페이지를 렌더링할때, 외부로 부터 데이터를 받아올때 보여주게 처리하여 빈 화면이 출력되지 않게 사용한 경험이 있음) 쉽게 말해 어떤 컴포넌트를 읽어야 하는데, 데이터가 아직 준비되지 않았다고 리엑트에게 알려주는 새로운 매커니즘이다. 사용방법은 아래와 같다. React.lazy()란? React.lazy 함수를 사용하면 동적으로 컴포넌트를 import하여 렌더링 할 수 있다. 이를 사용하면 초기 렌더링 지연시간을 어느정도 줄일 수 있다. 또 이 방법을 사용한다면 렌더링 관련 최적화를 진행할 수 있다. 만약 서비스를 구성하는 컴포넌트에서 import를 그냥 하게되면 코드가 실행되는 시점에서 모든 import 요소를 읽기 때문인데 불필요하게 읽지 않아도 되는 import 요소를 읽게 된다. 하지만 인 **React.lazy()**를 이용한다면 필요한 시점에 import 요소를…

이벤트 위임이란? 상위 요소에서 하위 요소의 이벤트를 제어하는 방식 을 하면 강력한 이벤트 핸들링 패턴인 을 이벤트 위임을 이용해 요소마다 핸들러를 할당하지 않고, 에 이벤트 핸들러를 공통 조상에 할당한 핸들러에서 하면 사용자의 인터랙션을 통해 추가되는, 아직 만들어지지 않은 요소에 이벤트 핸들러를 할당해야 하는 경우 사용한다. 장점과 단점 장점 많은 핸들러를 할당하지 않아도 되기 때문에 초기화가 단순해지고 메모리가 절약된다. 요소를 추가하거나 제거할 때 해당 요소에 할당된 핸들러를 추가하거나 제거할 필요가 없기 때문에 코드가 짧아진다. 이나 유사한 기능을 하는 스크립트로 요소 덩어리를 더하거나 뺄 수 있기 때문에 DOM 수정이 쉬워진다. 단점 이벤트 위임을 사용하려면 이벤트가 반드시 버블링 되어야 합니다. 하지만 몇몇 이벤트는 버블링 되지 않습니다. 그리고 낮은 레벨에 할당한 핸들러엔 를 쓸 수 없다. 컨테이너 수준에 할당된 핸들러가 응답할 필요가 있는 이벤트이든 아니든 …

리액트란? Facebook에서 주도하여 개발한 으로 구축하기 위해 사용하는 라이브러리이다. 자체는 framework라 부를 수 있는 기준인 라우팅, 상태관리 기본 제공을 충족하지 못하기 때문에 다. React가 등장하게 된 이유는 이전에는 어플리케이션의 UI를 제어하기 위해서는 DOM을 선택하고 어떤 이벤트가 발생하면 변화를 주도록 설정을 해야했다. 유저와 상호작용이 많이 없는 웹 서비스에서는 상관이 크게 없었지만, 인터렉션이 자주 발생하고 변화가 많은 어플리케이션의 경우 힘들었고 코드 또한 난잡해지는 경우가 많이 생기게 되었다. React의 특징은 1. 선언적(Declarative) 대화형 UI를 작성하기에 유리하다. 데이터가 변경되었을 때 효율적으로 렌더링을 수행할 수 있도록 한다. 2. 컴포넌트 기반(Component-based) 캡슐화된 컴포넌트가 스스로 상태를 관리하고 복잡한 UI도 효과적으로 구성할 수 있다. 3. 한 번 배워서 어디에서나 사용 가능(Learn Onc…

Hooks가 등장한 이유 기존의 클래스 문법에서 사용하였던 라이프사이클 메서드 기반은 때문에 나눌 수 있고 컴포넌트를 함수 단위로 잘게 쪼갤 수 있는 가 나와 함수 컴포넌트로 작성하게 되었다. Hooks을 이용하기 위해서는 에서만 호출해야하며, 내에서 Hook을 실행하면 안 된다. 이 규칙을 따르면 컴포넌트가 렌더링될 때마다 동일한 순서로 호출되는 것을 보장할 수 있다. Hooks의 종류 useState 상태를 변수로 선언하여 관리하며, 상태의 불변성을 유지한 채 상태를 변경할 수 있도록 도와준다. [state, setState]의 인자로는 state: 상태의 되고 초기에는 사용자가 제공한 초기 상태로 설정되어 표현 setState: 상호 작용에 따라 다른 값으로 변경 useEffect 컴포넌트 내에 에 실행되는 메서드 화면에 렌더링이 완료된 후에 수행된다. useEffect(function, …dependencies?); function : useEffect가 수행될 때 실…

🤯 보완예정 Life Cycle이란? 은 페이지에 렌더링 되기 전인 준비과정에서 시작하여, 브라우저에 렌더링 및 업데이트 후 페이지에서 사라질 때 끝난다. 컴포넌트는 를 같는다. 클래스 컴포넌트는 라이플 사이클 메서드를 사용하고, 함수형 컴포넌트는 Hook을 사용한다. (라이프사이클 메소드는 클래스 컴포넌트에서만 사용. 함수형 컴포넌트 → Hooks 사용) 컴포넌트가 처음 렌더링 될 때, 어떤 작업을 처리해야하거나 컴포넌트를 업데이트하기 전후로 어떤 작업을 처리해야 할 수 도 있고, 불필요한 업데이트를 방지해야 할 수도 있다. 이러한 경우에 컴포넌트 라이프사이클 메소드를 사용한다. Life Cycle의 구성 라이프 사이클은 총 3가지 카테고리로 구성 - Mount, Update, Unmount 접두사 메소드 → 어떤 작업을 작동하기 전에 실행 접두사 메소드 → 어떤 작업을 작동한 후에 실행 클래스 컴포넌트의 Life Cycle 클래스 컴포넌트 Life Cycle Mount c…

리액트의 상태 업데이트는 항상 으로 수행되어야 한다. mutate(돌연변이한)한 값의 대상과 위치에 따라 컴포넌트가 렌더링 되지 않을 수 있다. 데이터가 실제로 업데이트 된 시기와 이유에 대해 혼란을 겪을 수 있다. 불변성이란? Immutability(불변성)는 상태나 값을 변경하지 않는 것이다. JavaScript에서 예를 들자면, JavaScript의 원시 타입의 값들은 을 갖고 있다. 데이터 타입 원시 타입(string, number, bigint, boolean, undefined, ES6 부터 추가된 symbol) 변경이 불가능한 값(읽기전용) 원시 값을 변수에 할당하면 확보된 메모리 공간(주소)에는 실제 값이 저장됨 원시 값을 갖는 변수를 다른 변수에 할당하면 원본의 원시값이 복사되어 전달된다. 참조 타입(Object, Array, Function) 변경이 가능한 값 객체를 변수에 할당하면 확보된 메모리 공간에 참조값이 저장됨 객체를 가르키는 변수를 다른 변수에 할당하면…

Flux Architecture 이미지 에서 보다 일관된 데이터 관리를 위해 고안된 아키텍처 방식 기존에 보편적으로 사용된 MVC 패턴의 사용 시, 데이터 흐름의 복잡도가 올라가는 문제가 발생하였고, 를 고안하였고, 이것이 Flux 아키텍처이다. Flux 흐름 Action은 버튼을 누르는 것과 사용자 액션에 대한 이벤트 이름이다. Dispatcher는 Action에서 발생한 이벤트 이름에 따라 처리할 값들을 Store에 보낼 수 있다. Store는 데이터가 저장되어 있는 저장소로 Disspatcher에서 받은 행동에 따라 데이터를 핸들링한다. View에서는 Store에서 핸들링한 데이터를 받는다. 그리고 Action을 통해 이벤트를 발생시키는데, 데이터는 전달하지 않는다. 참고링크 Flux: An Application Architecture for React - React Blog In-Depth Overview | Flux 참고링크

Props VS State 에 영향을 주는 정보를 가지고 있다. 는 (함수 매개변수처럼) 컴포넌트에 전달되는 반면 는 (함수 내에 선언된 변수처럼)컴포넌트 안에서 관리한다. props state 상위 구성 요소에서 초기 값을 가져올 수 있습니까? 예 예 상위 컴포넌트로 변경할 수 있습니까? 예 아니 Component 내에서 기본값을 설정할 수 있습니까? 예 예 Component 내부에서 변경할 수 있습니까? 아니 예 자식 컴포넌트의 초기값을 설정할 수 있습니까? 예 예 자식 구성 요소에서 변경할 수 있습니까? 예 아니

개요 이번에 면접을 진행하면서 질문으로 “주어진 과제에 전역상태관리로 Redux-toolkit 사용하였던데, 다른 상태관리 라이브러리도 많을 텐데 왜 Redux-toolkit을 사용했는지?”에 대한 질문을 받게 되었다. 경험해본 전역상태 관리 라이브러리에 대해서는 답변을 잘 하였지만, Jotai와 Zustand의 경우 경험해보지 못하고 사용해 본적이 없어서 거론 정도로 설명을 하고 끝나게 되어 이참에 전역상태관리에에 대한 부분을 집고 넘어가보자 이 글을 작성하게 되었다. 전체적인 공통점 React는 단방향 데이터 바인딩 방식(Flux Architecture)이라 Props와 state를 다른 컨포넌트에서 사용하기 위해서는 을 이용해야만 했다. Props drilling 방식을 이용하면 관리해야되는 컴포넌트가 많거나 하위 컴포넌트에서 사용하기 위해 불필요한 props를 전달해야되는 경우 등 불편함을 많이 느끼게 되었고, 전역적인 상태 관리의 필요성이 대두 되었다. Context AP…

잡썰.. 어떤 데이터를 가져오기 위해서 외부 API를 호출하는 경우, 일단 화면에 렌더링할 수 있는 것들을 먼저 렌더링하고 실제 데이터는 비동기로 가져오는 것을 권장한다는 글을 종종 보게 되었다. 그 이유는? 요청 즉시 1차 렌더링을 함으로써 연동하는 API가 응답이 늦어지거나 응답이 없을 경우에도 영향을 최소화 시킬 수 있어서 사용자 경험 측면에서 유리하기 때문이다. 본론 리듀서 함수는 순수함수이여야 하며, 사이드 이팩트가 없어야 한다. 그렇기 때문에 api 요청과 같은 비동기 요청 관련 로직을 리듀서에 작성할 수 없고, 적는다면 컴포넌트에서 useEffect에 로직을 작성할 수 있다. (아래의 로직은 취업을 준비를 모기 업 과제로 얼마 준비하지 않았을 때의 로직이다. 상태관리로 리코일을 이용) 위와 같이 작성할 경우 시간이 얼마 되지 않았음에도 불구하고 어디서 데이터가 호출하는지 까먹었었다. 그렇다. 외부 API 정보를 컴포넌트에서 호출하게 되면 어디서 호출하는 지 알아봐야하고…

면접에서 기술질문으로 아래와 같은 질문을 받게되었다. 나는 위와 같은 질문을 받고 와 관련된 최적화 방안에 대해 질문한 것이라고 생각은 들었지만, 알지못하여서 답변으로는 아래와 같이 말을 하게 되었다. 아직까지는 대규모 프로젝트를 진행해본 경험이 없다. 하지만 2차례의 프로젝트를 진행하면서 최적화 방안으로 사용하거나 학습한 바로는 관심사의 분리나 단일 책임원칙을 적용하여, 컴포넌트가 최대한 한개의 기능을 수행하게 작성하거나 분리를 하고 공통으로 사용되는 코드는 분리하여, 코드의 양을 줄이고 최소화는 방법을 이야기하였다. 그 후 추가적으로 와 , 에 대해 말을 하였지만 면접관의 질문에 대한 답변을 말한 것이 아니여서 이 글을 작성하게 되었다. 지금 드는 생각 단순하게 최적화를 하기위해서는 코드를 적재적소에 사용한다. 라는 생각이 들게 되었는데 이유는 작성한 코드들이 항상 사용되는 것이 아니여서 필요할 경우에만 사용하면 된다 라는 생각이 들었다. 그래서 다음 면접시, 모르는 답안이 나…