Persistence

Nested Navigator 네비게이터는 own 히스토리를 갖는다. 뒤로가기를 하면 parent 네비게이터가 있더라도 nested stack 내부의 전 스크린으로 이동한다. 네비게이터는 own 옵션을 갖는다. title 옵션을 child navigator에서 지정하더라도 parent에게는 영향을 주지 않는다. 네비게이터는 own param을 갖는다. nested 네비게이터 안의 스크린에 패스된 파라미터는 parent나 child 네비게이터의 라우트 파라미터에 접근이 불가능하다. 네비게이터 액션은 현재 네비게이터에 의해 핸들링되고 만약 핸들링 불가능한 경우 버블링된다. 예를 들어 nested 네비게이터의 첫번째 페이지에 있는 경우 뒤로가기를 하면 부모 네비게이터로 이동한다. 예를 들어 아래 구조에서 Fe..

키보드가 올라와있을 때는 원래는 버튼을 클릭할 수 없다. 키보드가 올라와있을 때 화면을 터치하면 키보드를 dismiss하는 것만 가능하다. 다만 키보드가 올라와있는 상태에서 버튼을 클릭하게끔 하고 싶다면 ScrollView로 해당 컴포넌트를 감싼 다음, keyboardShouldPersistTaps를 handled로 주면 된다. handled는 ScrollView의 children에서 tap이 있을 때는 키보드를 dismiss시키지 않고 tap을 허용한다. 다만 ScrollView가 nested돼 있다면 parent ScrollView에도 해당 prop이 동일하게 적용돼있어야 정상 작동한다.

리렌더: 이미 스크린에 그려진 컴포넌트가 다시 렌더링되는 것 리렌더링은 언제 일어나는가? 컴포넌트의 state이 변했을 때, 해당 컴포넌트가 리렌더링됨 부모가 리렌더링됐을 때, 자식 컴포넌트도 리렌더링됨 (엣지 케이스가 있으나 일반적으로 그러함) Context Provider 값이 바뀌었을 때 그 컨텍스트를 사용하는 모든 컴포넌트가 리렌더링됨. 훅 내부에서 state 변동이 있거나 context 값 변동이 있으면 그 훅을 소비하는 컴포넌트가 리렌더링 됨. function Parent() { const [state, setState] = useState(); // state이 변하면 Parent 컴포넌트 리렌더링됨 // Parent 컴포넌트가 리렌더링되면 Child 컴포넌트도 리렌더링됨 return } 반..

export const useTodosQuery = (select) => useQuery({ queryKey: ['todos'], queryFn: fetchTodos, select }) export const useTodosCount = () => useTodosQuery((data) => data.length) function TodosCount() { const todosCount = useTodosCount() return {todosCount.data} }위 쿼리는 백그라운드에서 refetch할 때마다 두번씩 컴포넌트 리렌더링을 트리거한다. { status: 'success', data: 2, isFetching: true } { status: 'success&..

usePrevious const usePrevious = value => { const ref = useRef(); useEffect(() => { ref.current = value; }) return ref.current; } react docs에 보면 이런 코드에 대한 힌트를 얻을 수 있다. 이 훅은 전(Previous) state나 props의 값을 저장한다. 하지만 이 코드가 어떻게 전 value를 저장하는 결과를 가져오는 것일까? 첫 번째 포인트는 ref 값의 변화는 re-render를 트리거하지 않는다는 점이다. 반면 state의 변화는 re-render를 일으킨다. 예를 들어 const Counter = () => { const ref = useRef(0); const [counter, s..

상황 React Native에서 react navigation 스택을 사용함 퍼널 앞에서 호출한 쿼리를 퍼널 뒤에 새로운 화면에서 호출했는데 refetch하지 않고 기존 데이터를 재사용함. 캐시타임 내에 호출이 되어서 그런 줄 알고 cacheTime을 0으로 주고 했는데 동일한 현상 발생. 이유 일단 cacheTime은 inactive한 쿼리에 대해서만 의미가 있는데, 그 쿼리는 계속해서 active한 쿼리였다. 왜냐하면 스택 네비게이션에서는 계속해서 컴포넌트가 마운트된 상태로 쌓이기 때문이다. 챰고로 inactive 쿼리는 옵저버가 없는 쿼리를 의미하며, devtool로도 확인할 수 있고 Query Cache를 조회해서 옵저버 필드를 확인해볼 수도 있다. stale time은 디폴트가 0이므로 그 쿼리..

ISR을 알기 전 Next.js 선수지식 렌더링 CSR, SSR, SSG 렌더링이란 UI를 HTML로 나타내는 과정이다. 렌더링은 클라이언트에서 일어날 수도 있고 서버에서 일어날 수도 있다. 클라이언트에서 렌더링이 일어나는 것을 Client Side Rendering이라고 한다. 서버로부터 빈 HTML과 UI를 구성하기 위한 정보가 담긴 javascript 파일을 받아서 유저 디바이스에서 렌더링 작업을 시작한다. 이것과 대비되는 개념으로 서버에서 렌더링이 일어나는 것을 Pre-rendering이라고 한다. 클라이언트에 전송되기 전에 미리(Pre) HTML을 만들어서 전송한다는 의미이다. CSR을 사용하려면 useEffect나 useSWR을 사용해서 클라이언트에서 data fetching을 한다. Pre-..

일반적으로 mutate를 하고나서는 쿼리를 invalidate해서 refetch해오게 되는데, 이때 사용하는 것이 invalidateQuries이다. // return이 있을 때 onSuccess: () => { return queryClient.invalidateQueries(['posts', id, 'comments']) } // return이 없을 때 onSuccess: () => { queryClient.invalidateQueries(['posts', id, 'comments']) } invalidateQuries는 프로미스를 리턴하기 때문에 return을 시켜주면 해당 state가 업데이트 될떄까지 loading state가 유지된다. ..

useState, useReducer 모두 상태를 관리하는 훅이기 때문에 어떤 상황에서 어떤 것을 쓰는게 나을지 궁금했다. useState는 관리할 상태가 간단할 때 일반적으로 사용하면 좋다. useReducer는 간단하게 만들더라도 useState보다는 보일러플레이트가 길어서 verbose해보인다. 반면 관리할 상태가 여러개이고, 서로가 의존하고 있으며, 상태를 조작할 동작이 여러개일 때는 useReducer를 사용하는 것이 낫다. 상태가 변하는 로직을 reducer 한 군데 몰아넣음으로써 상태 간의 관계를 한 번에 파악하기 용이하고, reducer에 로직을 몰아넣음으로써 훅을 깔끔하게 유지할 수 있다. 액션이 여러 개일 때 위 이유와 마찬가지로 리듀서 한 군데에서 액션을 관리할 수 있다. 액션을 us..

react의 에러 바운더리는 렌더링 도중 생기는 에러가 UI 전체를 깨뜨리는 것을 막기 위한 용도이다. 그래서 처음에는 막연하게 try catch 대신 선언적으로 에러 핸들링을 도와주는 컴포넌트로 인식하고 있었다. 그런데 어느날 onClick에서 에러를 던지는데 에러 바운더리에서 핸들링이 되지 않았다. 찾아보니 에러 바운더리는 다음과 같은 에러를 잡지 않는다. 이벤트 핸들러 비동기적 코드 서버 사이드 렌더링 자식이 아닌 에러 바운더리 자체에서 발생하는 에러 이벤트 핸들러에서 발생하는 에러는 렌더링 도중에 발생하는 것이 아니므로, UI가 깨지지 않기 때문에 에러 바운더리에서 잡지 않는다고 한다. 대신 try catch를 써주라고 문서에 쓰여있다. 그리고 또 하나 의아했던 점은 비동기 코드의 에러 또한 잡지..

react query의 캐시는 in memory라서 브라우저 탭 간에 공유되지도 않고 새로고침할 때마다 새롭게 생성된다. (The cache is in-memory and only exists within the life of the javascript context for a tab.) in memory라는 단어의 사용은 솔직히 헷갈린다. 보통 인메모리 캐싱은 하드디스크 말고 메모리에 캐시를 저장하는 걸 의미하는데, 여기서의 맥락은 그런 in memory가 아닌 것 같고 그저 자바스크립트가 실행되고 있는 동안에 가지고 있는 상태라는 의미인 것 같다. (localStorage 처럼 지속 저장하는 형태가 아니라는 뜻) 리액트 쿼리에서 탭 간에 캐시가 공유되지 않다보니, invalidateQueries를 했..

Data fetching Traditioanl Approach vs Suspense 데이터 fetching과 관련해서 3가지 접근방법이 있다. Fetch-on-render 이 방법의 문제점은 'waterfall' 이라고 불린다. 이 코드를 보면, App 컴포넌트가 마운트하고나서 todos를 fetching하기 시작하고, 데이터를 받아오는 도중에는 loading jsx를 리턴한다.즉 여러개의 async 리퀘스트들이 병렬적으로 수행되지 못함으로써 UI 렌더링하는데 시간이 오래 걸리게 된다. 만약 Tasks 컴포넌트가 또 다른 async 요청을 할 예정인데, todos를 fetch하는데 5초가 걸린다면 이 Task 리퀘스트는 5초가 지난 다음에야 시작할 수 있는 것이다. 왜냐면 fetch on ..

Query 디폴트 useQuery와 useInfiniteQuery를 사용한 쿼리 인스턴스는 기본적으로 캐시 데이터를 stale로 취급한다. (staleTime이 기본적으로 0) stale query는 아래와 같은 조건에서 자동적으로 refetch 된다. 새로운 쿼리 인스턴스가 마운트했을 때 (refetchOnMount) 예를 들어 데이터를 fetch하는 컴포넌트가 있고, 이 컴포넌트가 다른 데에서도 마운트되면 캐시된 데이터를 쓰는게 아니라 그 때 또 다시 refetch한다는 뜻. 윈도우가 refocus됐을 때 (refetchOnWindowFocus) 네트워크가 다시 연결됐을 때 (refetchOnReconnect) refetch interval 설정을 해줬을 때 (refetchInterval) useQu..

React에서 form의 validation을 도와주는 라이브러리이다. 이 라이브러리는 기본적으로 uncontrolled component를 베이스로 하지만 controlled component에 대한 지원도 하고 있다. react hook form의 장점은 가볍고, 다른 디펜던시가 없으며, ref를 기반으로 하여 다른 UI 라이브러리와 호환이 잘된다는 것이다. 가장 간단한 형태 const { register, handleSubmit } = useForm(); 여기서 register는 해당 컴포넌트의 값을 트래킹하고 validation을 하기위해 react hook form 라이브러리에 등록한다는 뜻이다. input을 등록하려면 아래처럼 ref에 register을 넘겨주면 된다. 이 때 중요한 점은 반드..

Case 1 - dependency array 없이 data fetch const [data, setData] = useState(); useEffect(async () => { const result = await something; setData(result.data); }) 문제점: 데이터를 불러온 후 setData를 하고 있기 때문에 리렌더링되고, 그러면 useEffect이 또 실행되므로 무한 루프가 발생한다. Case2 - dependency array 있이 data fetch const [data, setData] = useState(); useEffect(async () => { const result = await something; setData(result.data); }, []) 개선..