[milly] 6주차 미션 PR - 1

vvvpiano commented 2 years ago

:heavy_check_mark: 체크 리스트(PR 올리기 전 아래 내용을 확인해 주세요)

merge할 브랜치의 위치를 확인해 주세요 (master/main :x:)
리뷰가 필요한 경우 'review' 라벨을 달아주고, 리뷰어를 지정해 주세요
리뷰는 화요일, 목요일 오후 3시전에 올려주세요
코드리뷰는 다음날 오전 10시 전 까지 받을 수 있습니다.
Approve된 PR은 리뷰어가 머지를 하고, 수정 요청이 온 경우 수정 후 다시 push 를 합니다.
동작데모, 설계내용등을 포함해도 좋습니다.
리뷰받고 싶은 포인트나 고민꺼리를 남기셔도 좋습니다.

:pencil2: PR 내용
구현영상

https://user-images.githubusercontent.com/48192106/152927992-be3af208-dc85-4dbe-955b-6c0ae027ce46.mov

상태관리 위주로 다양한 시도를 해보았습니다.

useFetch custom hook

루카스의 예시를 참고하여 useFetch를 만들고 서버 데이터를 fetch하는 곳에 사용했습니다. 그러나 후에 recoil을 도입하는 부분에서 자체적으로 error, loading, hasValue 등의 기능을 제공하길래 이 부분은 단순 fetch로 데이터를 가져오게 되었고, useFetch는 현재 쓰이고 있지 않습니다.

useReducer

issueTable 컴포넌트에서 row들을 체크하는 기능을 구현하기 위해 useReducer를 사용했습니다. 그러면서 겪었던 어려움이 몇가지 있습니다.

fetch해온 issues 데이터의 길이와 같은 길이를 가지는 boolean[] 을 initialState로 가지도록 하고싶었는데, issues 데이터가 useRecoilValueLoadable로 가져와지는 동안은 issues 데이터의 길이가 0이었고, 그렇게 한 번 길이 0의 배열로 초기화된 reducer는 데이터 로딩 후 다시 원하는 길이의 배열로 초기화되지 않았습니다. 즉, state의 값이 바뀌어도 useReducer의 선언부는 리렌더링 되지 않는 것처럼 보였습니다. 그래서 action들의 payload에 issues의 length를 포함시키고, 나중에 리듀서 안에서 현재 비열 길이를 체크하여 길이가 0인 경우 원하는 길이의 배열을 다시 만들도록 했는데, 이 방식이 마음에 들지 않습니다.
issueTable 컴포넌트 파일 안에서 reducer 관련 선언부와 type 선언부가 길어져서 reducer 폴더안에 다른 파일로 분리해내려고 했습니다. 이건 제가 tyepscript에 미숙해서 생기는 이슈인 것 같긴 한데, 같은 코드를 별개의 파일로 분리해내자 useRecuer가 리턴하는 dispatch의 타입 또한 달라졌습니다. dispatch without action 타입의 dispatch를 리턴하는 바람에 dispatch가 잘 동작하지 않았습니다. 구글링을 열심히 해보긴 했는데 해결되지 않아 그냥 그대로 issueTable 파일 안에 두었습니다.

recoil

처음으로 recoil을 써봤는데, 아직 많은 기능을 써보지는 않았지만 정말 만족하면서 쓰고 있습니다. 일단 전역상태관리라 파일 여기저기서 사용하기 편하고, 마치 reducer에서 action type에 따라 다르게 데이터 필터링을 하듯이, state 값에 따라 필터링하는 selector를 정의해서 사용하여 구현할 수 있는 것도 신기했습니다.

어느 곳에서는 state(loading, hasError, hasValue)에 따라 if문으로 리턴하는 tsx가 다르도록 처리했고, 어떤 곳에서는 React.Suspense의 fallback을 통해 처리하는 등 필요에 따라 코드를 짰는데, 이런 에러핸들링 방식을 통일해야할지 고민입니다.

그 외

간단한 서버 작업
그때그때 필요한 컴포넌트 뷰 구현하며 진행하는 중

:guitar: 기타 링크 및 참고사항

crongro commented 2 years ago

구현영상

이정도 구현된 데모면 실무도 잘 하실 듯.

crongro commented 2 years ago

recoil을 도입하는 부분에서 자체적으로 error, loading, hasValue 등의 기능을 제공하길래

맞아요.

crongro commented 2 years ago

fetch해온 issues 데이터의 길이와 같은 길이를 가지는 boolean[] 을 initialState로 가지도록 하고싶었는데, issues 데이터가 useRecoilValueLoadable로 가져와지는 동안은 issues 데이터의 길이가 0이었고, 그렇게 한 번 길이 0의 배열로 초기화된 reducer는 데이터 로딩 후 다시 원하는 길이의 배열로 초기화되지 않았습니다. 즉, state의 값이 바뀌어도 useReducer의 선언부는 리렌더링 되지 않는 것처럼 보였습니다. 그래서 action들의 payload에 issues의 length를 포함시키고, 나중에 리듀서 안에서 현재 비열 길이를 체크하여 길이가 0인 경우 원하는 길이의 배열을 다시 만들도록 했는데, 이 방식이 마음에 들지 않습니다.

네 이상해요 ㅎ loading중에 reducer 로 결과값을 반영하는 것이 이상합니다. loaded 시점에서 값을 반영하는 식으로 하셔야 할 것 같은데요.

crongro commented 2 years ago

React.Suspense의 fallback을 통해 처리하는 등 필요에 따라 코드를 짰는데, 이런 에러핸들링 방식을 통일해야할지 고민입니다.

코드를 보시면 알겠지만 suspense 방식이 상당히 깔끔하다고 생각합니다.

2022NewKrew / fe-w4-issue-tracker