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 크게 살펴보면 다음과 같다. 리액트에서 각각의 단계를 어떻게 활용하는지 알아보자. 🎃 예시(클래스형 컴포넌트) ) 리액트? 리액트가 뭐야? <img src ="https://velog.velcdn.com/images/ja960508/post/625a6b7e-663