인생은 반복문

React는 세 단계로 화면을 그린다. 1. trigger: render를 수행시킨다. 초기 렌더링, 컴포넌트의 상태 변경이 trigger에 해당한다. 2. render: React는 상태 갱신이 발생한 컴포넌트들을 호출(랜더링)한다. 호출된 컴포넌트의 하위 컴포넌트들도 React가 호출한다. 끝자락 컴포넌트에 도달할 때까지 React는 컴포넌트들을 계속 호출한다. 이를 통해 React가 화면에 다시 그려야할 컴포넌트들을 파악한다. 3. commit: React는 대상 컴포넌트들을 랜더링 한 후, DOM에 변경된 컴포넌트들만 반영한다.(이전 렌더링 결과와의 차이에 대해서만 DOM에 반영) *React가 DOM을 갱신하면 브라우저가 화면을 다시 그린다. 출처: https://react.dev/learn/..

Choosing the State Structure 1. Group related state: 항상 같이 갱신되어야하는 상태가 2개 이상 존재한다면 object, array 등으로 묶어 한꺼번에 관리하는 것을 고려하자. 2. Avoid contracdictions in state: 모순되는 상태 관계를 구축하지 마라. 예를들어 로딩 단계에 대해 isLoading, isDone 로 상태를 2개 두어 관리한다고 해보자. 코드 작성 과정에서 한 개의 상태라도 갱신을 빠트리는 경우, state 간의 모순이 생길 수 있다. 이런 경우는 loadingState(init | loading | done) 처럼 하나의 상태만을 두어 관리하는 것이 안전하다. 3. Avoid redundant state: 불필요한 상태를 ..

redux-saga에서 yield call을 통해 정의해놓은 클래스 인스턴스의 멤버 함수를 호출하려고 보니, 멤버 함수 속 this가 null을 참조하고 있었다. 처음에는 클래스 생성자로 인스턴스를 생성할 때 인수 전달이 제대로 안되었나보다 하고 console.log를 찍어가며 디버깅 해보았지만 값은 잘 들어가고 있었다. 혹시 몰라 yield call 대신 함수 직접 호출을 해보니 동작이 잘 되었다. 이유가 궁금하여 찾았더니 아래 스택 오버 플로우 글을 찾았다. 링크: https://stackoverflow.com/questions/58397875/reference-to-this-is-null-in-function-called-by-redux-saga-call Reference to "this" is n..

정의: 리액트 컴포넌트 여러 개가 같은 값을 바라보며 동일하게 갱신되어야하는 경우, 제일 가까운 공통 부모 컴포넌트로 state를 끌어올린다. 이것을 "state lifting up"라고 한다. 깨달음: 컴포넌트를 설계할 때 필요한 데이터를 prop으로 받을 지 state로 정의할 지 고민을 하게 되는 경우가 잦았는데, 결정의 근거로 state lifting up 가능성을 고려해야겠다. state vs prop 고민에서 선택의 근거가 좀 더 명확해질거 같다. "편하게 넘겨주는거 쓰는게 좋으니까 prop으로 결정하자! => 주변 컴포넌트와의 관계를 봤을 때 state lifting up을 가능성이 매우 높으니 prop으로 전달받자!"

회사에서 라우팅 관련 모듈을 구현하는 중에 팀장님께 리뷰를 받았다. "context도 모듈 내에 두세요, 왜 context는 밖에서 정의했나요?" 라우팅 모듈을 전역적으로 리액트 컴포넌트들에 전파시키기 위해 context api를 모듈 바깥에서 선언한 부분에 대해 리뷰 받은 내용이다. 모듈은 모듈 관련 코드만 두어야한다는 일차원적인 생각이었는데 context도 결국은 '라우팅'이라는 도메인이 엮이는 순간 같은 곳에 묶여도 되는 것이다. 오히려 react에서 사용하려는 의도를 가지고 만든 모듈인만큼 context 정도는 내부에서 구현해놓아도 되는 것이었다. 생각의 틀이 한계를 벗어나 조금 더 확장되는 경험이었다.

리액트로 개발을 할 때 아래 에러를 자주 만나게 됩니다. --- list의 child에 key를 넣으라는 내용입니다. 저 빨간 경고문이 거슬려서 일단 map에서 제공해주는 index 값을 key에 전달해서 해결해 오긴 했는데... *아래 코드는 보통 해결하고 넘어갈 때의 코드 모습 const fruits = ['apple', 'banana', 'melon']; {fruits.map((fruit, index) => {fruit} )} 왜 key를 넣어주어야하는 것인지, index를 넣어주어도 괜찮은건지 궁금해서 공식 문서를 뒤져봤습니다. 결과적으로 index를 key로 전달하지 않으면 리액트가 알아서 index를 key에 넣어준다는 것과, index를 key로 넣어줘도 상관이 없다는 것이 제가 알아낸 사실..

쭉 읽어보니 평소에 useEffect를 사용할 때 놓쳤던 부분들을 많이 발견할 수 있었습니다. 친절하게도 마지막에 다시 한 번 wrap 해주는 부분이 있어서 원문으로 가져왔습니다. 아래에 원문을 의역해서 다시 정리해보았습니다. 원문 Unlike events, effects are caused by rendering itself rather than a particular interaction. Effects let you synchronize a component with some external system (third-party API, network, etc). By default, effects run after every render (including the initial one). React..

*fact 기반이 아닌 개인적인 생각 정리 글입니다. 이 점 참고해주세요. 1. Relay를 활용하면 Suspense를 사용할 수 있게 됩니다. 즉, 컴포넌트 내부에서는 data fetch에 대한 비동기 상황은 고려하지 않고 코드를 짤 수 있게 된다는 것이죠. 외부에 비동기 상황에서의 대처를 위임할 수 있게 되니까요. 2. Suspense는 React-Query, SWR 등에서도 사용 가능합니다. 그렇다면 Suspense 이외에서 Relay의 장점은 무엇일까요? 바로 선언적인 data fetching이 가능하다는 것입니다. Relay를 통해 데이터 fetching을 하려면 컴포넌트 내부에서 query를 적어야합니다. 이때 이 query 내용에 해당 컴포넌트가 필요한 데이터를 '명시'하는 방식입니다. 정리..