Spread operator 위와 같은 코드는 어떤 출력을 할까? 사실 이 코드는 타입 에러를 발생시킨다. obj는 iterable하지 않기 때문이다. spread operator는 배열이나, 문자열 등 iterable한 객체에서 사용할 수 있다. 최신 자바스크립트에서는 다음과 같은 객체 리터럴에서도 spread operator를 사용할 수 있는 기능을 추가했다. 위의 예시에서는 key-value 형태로 index: item인 object가 만들어진다. 다음과 같은 문법을 이용하면 새로운 obj에 속성들을 열거할 수 있는 것이다. 😥 의문점 내가 가진 의문은 다음과 같다. HOC에 대한 예시를 작성하던 중 {...props} 부분이 눈에 거슬렸다. 당연하게 사용했던 것인데 어떻게 저런 문법이 가능한 건지 이해가 되지 않는다. JSX에서 중괄호는 일반적인 자바스크립트 문법을 사용하기 위함이라고 들었다. 그런데 props는 iterable하지

🙄 고차 컴포넌트(HOC)? > 고차 컴포넌트(HOC, Higher Order Component)는 컴포넌트 로직을 재사용하기 위한 React의 고급 기술입니다. 고차 컴포넌트(HOC)는 React API의 일부가 아니며, React의 구성적 특성에서 나오는 패턴입니다. 고차 컴포넌트(Higher Order Component)는 컴포넌트를 반환하는 '함수'이다. 컴포넌트를 인자로 받아 그것을 반환하기도 한다. 고차 컴포넌트를 사용하는 기본적인 이유는 추상화이다. 특정 기능이 여러 컴포넌트에 중복되어 나타날 경우 그것을 고차 컴포넌트로 한번 wrapping하면 추상화 계층을 제공할 수 있다. 예를 들어 유저가 페이지에 접근할 때 해당 유저가 로그인 중인지 여부, 혹은 특정 게시글이나 댓글의 작성자인지 확인하는 작업의 해결책 중 하나로 고차 컴포넌트를 사용할 수 있다. 🎅 예시(유저 권한 확인) 만약 특정 컴포넌트에서 유저의 권한을 확인할 필요가 있다면 다음과

Props Drilling 다음과 같은 코드가 있다. 조금 이상하지만 상상력을 발휘해서 살을 붙여보자. num은 First에서 관리하고, First와 Fourth에서 사용한다. 하지만 쓸데없이 num을 Second, Third에도 전달해야한다. 컴포넌트 계층이 그렇게 되어있기 때문이다. 이러한 현상이 props drilling이다. 오직 전달만을 위한 props들이 하위 컴포넌트들에 다수 존재한다면 앱의 규모가 커질수록 좋지 않은 영향도 커질 것이다. Component Composition 컴포넌트 합성을 통해 props drilling을 해결할 수도 있다. 위의 코드를 컴포넌트 합성으로 해결한 형태는 다음과 같다. 전달만을 위한 props는 더이상 없고 상위 컴포넌트에서 바로 필요한 속성을 주입시켜줬다. 컴포넌트 합성으로만 해결할 수 있다면 굳이 Context를 사용하지 않아도 된다. 하지만 로그인 여부, 현재 테마 등 하나의 컴포넌트 트리가 아

언제 사용했을까 useRef는 은근히 많이 사용한다. 현재까지 내가 사용했던 것은 다음과 같다. 렌더링 된 DOM 요소에 접근할 때 -> input에 focus하거나 value 값에 접근할 때 간편하다. 컴포넌트 내부에서 기억해야 할 가변 변수를 사용할 때 -> 이 값이 변해도 리렌더링은 일어나지 않음 일반적으로 컴포넌트가 리렌더링 될 경우는 그 컴포넌트 함수가 다시 실행된다. 그 말은 내부에서 지역 변수를 선언해도 다시 초기화된다는 말이다. 이때 state를 통해 값을 변경하는 건 너무 과하다. 그 값을 기억할 때마다 리렌더링이 발생하기 때문이다. 값을 기억해야하지만 리렌더링은 원치 않을 때, 그때 ref 객체를 사용한다. DOM에 접근하기 사실 ref를 가장 많이 사용하는 것은 렌더링 된 DOM 요소에 접근할 때일 것이다. 의문이 생긴다. 그냥 querySelector로 접근해도 되지 않나? 틀린 말은 아니다. 이미 렌더링된 요소라면 똑같이

리덕스는 재미없었지만 리덕스 툴킷 덕분에 조금 재밌어졌다. 정말 다행이다. 😀 🔨 설치 설치부터 간편하다. 과거엔 redux, react-redux 또 필요하다면(거의 필수적) devtools, saga, thunk, actions 등등 다양한 커스터마이징이 가능했다. 처음 사용해본다면 필히 어지러움을 느낀다. 이런 작업들이 모두 간편해졌다니 정말 감사하다. 🙉 사용법 리덕스 툴킷은 내부적으로 thunk와 devtools를 제공한다. 1. store 선언 기존의 사용법과 마찬가지로 store를 만들어야한다. 이때 createStore가 아닌 configureStore를 사용했는데 사용법이 조금 다르다. 기존에는 combineReducers로 통합해 하나의 reducer만 제공했다면 이제는 reducer 객체에 그냥 추가하기만 하면 된다. 그리고 기본적으로 devtools를 내장하고 있다. 2. createSlice 기존

setState는 비동기적으로 작동한다. 이유 그 이유는 이전 state와 다음 state를 비교하며 리렌더링을 하는 게 비용이 큰 작업이기 때문이다. setState를 통해 새로운 state로 업데이트하는 작업을 연달아 3번 발생시켰다고 가정해보자. 이런 작업에서 리액트는 재조정을 통한 리렌더링을 3번 발생시키지 않는다. 리액트는 똑똑한 라이브러리이기 때문이다. 최후의 작업만 리렌더링하는 게 비용이 적다는 걸 알고 있다. 문제는 개발자의 의도와는 다른 결과를 불러올 수 있다는 위험성이다. 위의 예시에서 count는 기존의 count에서 +3된 값이 아닌 +1로만 state가 설정된다. 해결책 다음과 같이 함수를 전달해주면 간단하게 해결할 수 있다. 물론 애초에 setState를 여러 번 호출할 일이 없도록 하는게 더 좋다. 주관적인 의견 setState가 비동기적으로 발생하는 원리에 대해 조금 조사해봤다. 일단 공식문서에는 setState

프론트엔드를 최적화하는 방법에는 여러가지가 있다. 크게 둘로 나누면 로드 최적화, 렌더링 최적화부터 세세한 부분까지 들어가면 이미지 스프라이트, 웹 폰트 최적화, 트리 쉐이킹, 레이아웃 스레싱 방지 등 굉장히 복잡하다. 이런 부분은 조금 더 숙련되고 난 뒤 다뤄보도록 하고 리액트에서 중점이되는 memoization을 이용한 최적화를 알아보자. 🛴 재조정 리액트에 DOM의 업데이트 여부를 결정하는 재조정 과정은 두 가지 가정을 기반으로 이루어진다. 다른 타입의 두 엘리먼트는 서로 다른 트리를 만든다. 개발자가 key를 통해 여러 자식 엘리먼트 중 어떤 것이 재조정되어야 하는지 알려준다.(리스트와 Key in React 참조) 1번도 세부적으로 들어가면 3가지 경우가 나온다. 두 개의 루트 엘리먼트가 있다고 가정하고

출처: https://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/ 리액트 컴포넌트는 각각의 생명주기를 갖는다. 1. Mount React Element가 생성되고 DOM에 삽입될 때 constructor, render, componentDidMount 순으로 호출 2. Update props 혹은 state가 변해 다시 렌더링될 때 shouldComponentUpdate, render, componentDidUpdate 순으로 호출 3. Unmount React Element를 DOM에서 제거할 때 componentWillUnmount 크게 살펴보면 다음과 같다. 리액트에서 각각의 단계를 어떻게 활용하는지 알아보자. 🎃 예시(클래스형 컴포넌트) ![](https:/

🔨 커스텀 훅 커스텀 훅은 리액트 hooks들을 한데 모은 것이다. 즉 사용자가 원하는 로직을 실행시키는 함수와 비슷하다. 단지 그 동작들을 리액트 hooks가 해줄 뿐이다. 커스텀 훅을 왜 사용할까? 그냥 컴포넌트 내부에서 useState나 useEffect 등을 사용해도 차이가 없을 텐데 말이다. 맞는 말이다. 결국 같은 동작을 할 테지만 좋은 프로그래밍은 결과만으로 이루어질 수 없다. 코드의 재사용성을 높이고 추상화 계층을 제공하여 내가 봐도 좋고 남들이 봐도 직관적인 코드를 구현해야한다. 종합하자면 커스텀 훅은 반복되는 코드를 재사용할 수 있도록 바꾸고, 구체적인 구현은 숨기고 추상화된 인터페이스를 제공하여 프로그래밍을 용이하게 하는데 그 목적이 있다고 생각한다. 🔨 예시 다

리스트 렌더링 하기 다음과 같은 컴포넌트가 있다. 렌더링은 정상적으로 이루어지지만 콘솔은 오류를 뱉어낸다. list의 각 child는 고유한 key prop이 있어야한다. 이게 무슨 소리일까? 일단 공식 문서부터 찾아보자. Key > Key는 React가 어떤 항목을 변경, 추가 또는 삭제할지 식별하는 것을 돕습니다. key는 엘리먼트에 안정적인 고유성을 부여하기 위해 배열 내부의 엘리먼트에 지정해야 합니다. Key는 고유성을 부여하는 속성이다. 그렇기 떄문에 엘리먼트를 식별하는 값으로 지정하는 게 좋다.

You might be wondering: why is useState not named createState instead? “Create” wouldn’t be quite accurate because the state is only created the first time our component renders. During the next renders, useState gives us the current state. 출처: React docs, Using the state hook 현재 컴포넌트의 상태 값을 설정하는 useState 훅과 사이드 이펙트를 발생시키는 useEffect 훅은 흔히 사용한다. 이런 훅들은 어떤 흐름으로 동작할까? 이번 포스트에서 그 부분에 대해 다뤄보도록 하겠다. 💊 실험 다음과 같은 두 개의 컴포넌트가 있다. App 컴포넌트

Less to Learn You don't need to learn and configure many build tools. Instant reloads help you focus on development. When it's time to deploy, your bundles are optimized automatically. 출처: create react app 🧛‍♀️ CRA가 없다면? 리액트를 비롯해 대부분의 다른 프레임워크, 라이브러리는 순수한 js만으로 이루어져있지 않다. 하지만 브라우저는 순수한 js, html, css만을 읽을 수 있다. 이럴 때 우리는 작업했던 파일들을 브라우저가 읽을 수 있는 형태로 변환해야 한다. 번들러를 사용한다면 babel-loader와 필요한 플러그인들을 통해 이런 과정을 수행할 수 있고, 혹은 babel을 직접 실행시켜 변환할 수도 있다. 하지만 직접 번들러의

initialState의 사용 위와 같은 useState 훅의 사용법은 아주 흔한 방식이다. 하지만 initialState가 다음과 같다면 어떨까? localStorage에 접근하는 등 복잡한 연산을 initialState에 사용해야 할 때가 있다. 하지만 다음과 같은 사용은 문제를 발생시킨다. 보이는 것과 같이 리렌더링이 발생하면 initialState를 구성하는 함수가 다시 호출된다. 비용이 큰 로직이라면 이것은 굉장히 비효율적이다. 해결책 다행히 리액트는 이런 상황을 고려했는지 해결책을 마련해놨다. 간단하게 함수 호출이 아닌 함수 그 자체를 전달해주면 된다. 혹은 로직에 따라 이렇게 화살표 함수를 이용할 수도 있다. 그렇다면 모든 initialState를 함

리액트를 배우면 자주 듣는 말이 있다. 리액트는 변화한 부분만 감지해서 그 부분만 업데이트 해준다는 것이다. 그렇기 때문에 효율적이라는 건데 말로만 들어서는 잘 와닿지 않는다. 이 내용을 한번 확인해보자. React Element? 리액트 엘리먼트는 리액트 앱을 구성하는 가장 작은 단위이다. 다음과 같은 jsx 문법을 통해 만들어진 요소가 엘리먼트라고 할 수 있겠다. 얼핏 보면 HTML 태그처럼 보이지만 이건 DOM 요소가 아닌 리액트 엘리먼트다. 그렇기 때문에 리액트에서 제공하는 렌더링 함수를 거쳐야한다. 과거에는 ReactDOM.render로 호출했다. 하지만 리액트 18 버전부터는 createRoot를 통해 root 엘리먼트를 지정하고 그 root 엘리먼트를 통해 render 함수를 호출해야한다. 여기까지만 보면 바닐라 js와 딱히 다른 게 없어 보인다. 본격적인 차이점을 알아보자. 바닐라 JS, 리액트 리렌더링 비교 ![](https

다시 한번 말하지만 리덕스는 별로 재미가 없다. 구체적으로 말하자면 리덕스를 배우는 과정이 재미 없다. 하지만 한번 배워 놓고 사용해보면 리덕스는 참 든든하다. 좋은 친구 리덕스를 리액트 환경에서 사용하는 법을 알아보자. 시작하기 일반 js 환경과 CRA 환경에서 리덕스를 다루는 건 큰 차이가 없다. 전체적인 맥락도 같다. 오히려 CRA에서 더 편하게 느껴지는 부분도 있다. 우선 두 개의 패키지를 설치해야한다. redux는 이전 포스트에서 설명했던 것처럼 redux core에 해당하는 패키지이고, react-redux는 리액트 환경에서 리덕스를 더 편리하게 사용할 수 있게 도와주는 패키지이다. react-redux는 store를 제공하는 고차 컴포넌트와 redux-hooks 등을 제공해준다. 모듈 설정 ![](https://velog.velcdn.com/images/ja960508/post/b82d234a-d29a-4bc9-9bf1-b3c28ef5d57

나는 리액트를 배우고 있다. 별다른 이유는 없다. 제일 많이 사용되는 트렌디한 라이브러리이고 그럼 나도 배워야겠다고 생각했기 때문이다. 이게 내 솔직한 심경이지만 남들이 물어봤을 때 이런 식으로 대답이 나온다면 그건 상대도, 자신도 참 곤란한 상황일 것 같다. 그런 불상사를 방지하기 위해 하나하나 살펴보자. JS 프론트엔드 프레임워크 사용량(출처: StateOfJS(2021)) 리액트? 리액트가 뭐야? <img src ="https://velog.velcdn.com/images/ja960508/post/625a6b7e-663