파이널프로젝트 중간회고 피드백:)

 

 

이번 파이널 프로젝트에서 담당한 부분이 로그인과 회원가입 부분이였습니다. 처음해보는 파트라 

항해를 시작하며 처음 접하게 된 상태관리 라이브러리가 Redux였기에 redux를 전 프로젝트부터 사용하던 도중, 

 아주 작은 기능이여도 리덕스로 구현하는 순간 몇 개의 파일(액션등을 미리 만들어놔야함)들을 필수로 만들어야하여 코드량이 늘어나고, FE 상태와 BE 상태는 실제로 동기화되지 않고,

 Redux 를 활용해 프로젝트에서 전역 상태 (state) 를 관리를 할 때 서버 데이터를 활용하려면 반드시 Redux-saga, Redux-Thunk 혹은

 RTK-Query 같은 또 다른 미들웨어를 사용해야 하기 때문에 이에 대한 처리는 직접 처리해야 한다는 불편함을 느꼈기에 더 좋은 방법을 찾아보던 도중 React-Query 는 

기본적으로 데이터를 fetching 해온 후 데이터를 캐싱 하게 되며, 해당 데이터가 stale 하다고 판단될 때 데이터를 refetching 해오게 됩니다.

결국 서버 데이터를 패칭해 온 데이터를 캐싱했어도, 사용자가 화면을 바라보고 있을 때는 그 시점에 있어서 가장 최신의 데이터를 바라보고 있는 상황이며, 

페이지가 전환이 되었을 경우에도 해당 데이터의 상태가 stale 하다고 판단하여 리패칭 하며, 페이지에서 어떤 이벤트가 발생했을 경우엔 개발자가 트리거 를 심어줌으로 써 데이터를 리패칭 할 수 있습니다.

즉, 위와 같은 React-Query 의 컨셉으로 인해서 사용자는 항상 신선한 (fresh) 데이터를 바라볼 수 있습니다.

이와 같은 이유로 서버 스테이트와 전역 스테이트를 분리하기 위해 리덕스를 사용한 코드들을 리코일과 리액트 쿼리로 분리하려 하고 있습니다.

Recoil 은 Client 에서 전역 상태를 관리하고자 사용하는 라이브러리 입니다. React-Query 를 활용한다면 전자의 라이브러리들이 본연의 역할에만 집중할 수 있도록 할 수 있습니다. 즉 서버 데이터와, 클라이언트 데이터를 분리 하는 것입니다.

 

그 외 받은 피드백 받은 유의사항입니다.

 

  1.  리액트 상태관리 할때 하나로 통일하면 좋습니다.

     ex) 앱>라우트>컴포넌트>내부 컴포넌트

 

  2. 페이지에서 기능단으로 나오고 컴포넌트에서 ui적용하는게 나을듯합니다.

      그 위에 컴포넌트 애들이 하는게 없고 기능에 맞게 분리하는것이 좋습니다.

 

  3. 기능구현을 할 때 의존성체크가 쉽지않고 라이브러리사용하거나 오픈소스사용시 직접만들어 구현하는것이 좋다.

 

  4. 코드만 보고도 말이 되게 만들어야되고, 코드에서도 전달되는 정보가 명확히 보여야합니다.

      기능과 ui가 분리되어야하고, 코드가독성이 중요합니다. 코드만 보고도 ui예측되어야합니다.

      일반적이지않은케이스에만 주석달아야하고 그 외에는 안달아도 됩니다.

 

 

위 의 점들을 고려하여 3주동안 리팩토링을 거치면 좋은 프로젝트가 될거같습니다! 파이널 프로젝트 화이팅!!!