일상의 기록/🌷DAILY 회고록 : 코드스테이츠

메인 프로젝트 1차 마무리 회고

감귤밭호지차 2023. 8. 8. 22:34

드디어 메인 프로젝트 1차 완료가 끝났습니다. 

 

 

어쨌든 배포를 하고 데이터를 불러오고 원하는 기능을 구현했다는 점에서 뿌듯? 하면서도 아쉬움이 많이 남는 프로젝트였습니다. 

추가적으로도 계속 업데이트를 해나갈 예정이지만 다들 워낙 바쁘다 보니 원하는 만큼 이야기 공유가 안될 것 같은 슬픈 예감이 드는 군요.. 

 

밤도 새가면서 열정을 다 바친 첫 프로젝트라 굉장히 뿌듯하다는 생각이 듭니다. 이 프로젝트를 1차 완성한 기념으로 자체 질의응답 및 회고록 시간을 가져볼까 합니다. 

 

 

 

      기술 스택들을 선택 이유 

: React Vite TypeScript Tailwind CSS Styled-Components Twin.macro Redux-toolkit Axios

 

# React x Vite

React는 대표적인 SPA/ CSR 방식으로 구현되는 프로젝트 구현 라이브러리입니다. 저희 프로젝트의 대표적인 아이템이 " 프리랜서들의 개별 작품들을 전시하고 클라이언트와 이어질 수 있는 공간" 을 구현해주는 것이었습니다. 그렇기 때문에 저희 사이트 내에서의 작품을 검색하고 많은 포트폴리오 데이터들(사진, 영상) 등을 다뤄야 하기 때문에 변경된 부분만 컴파일해서 빌드 속도가 빠른  Vite와 CSR 방식의 React를 선택하게 되었습니다.

 

굳이 구글 이나 네이버와 같은 사이트에서 개인 작가의 작품을 검색하는 SEO 부분이 중요하다고는 생각이 되지 않아서 입니다. 저희 사이트를 들어와서 내부에서 검색하는 것이 더 효율적이라고? 생각했기 때문이죠. 

 

# TypeScript 

여러 props 를 내려줄 때 보다 정확하게 데이터를 인식하고 넘겨주고 공동 작업이기 때문에 겹치는 데이터들의 값을 정확하게 판단할 수 있기 위해 타입스크립트를 적용하였습니다. 실제로 데이터들을 넘기는 작업시 타입으로 인해 체크하기 편했다... 

하지만 물론 처음 적용할 때는 살짝 햇깔리기도 했으나 확실히 타입을 미리 설정해두니 예상치 못한 데이터 오류를 해결할 수 있었다. 

 

 

 

# TailwindCSs + StyledComponents + twin.macro

사실 TailwindCSS 를 접하고부터는 이 라이브러리의 편리함과  큰 틀에 정해진 px 단위로 인해 공동 작업을 할 때 굉장히 편리하다고 느껴졌습니다. 또한 styled-components의 CSS의 컴포넌트 단위로 조합해서 사용하는 편리함을 놓칠 수 없어서 Styled-components 라이브러리도 이용해서 tailwindCSS의 디테일한 스타일 적용이나 클래스 이름이 장황하게 나열되는 단점들을 보완할 수 있도록 했습니다. 

이때 Twin.macro 라이브러리를 함께 적용하여 보다 빌드?가 편하게 되도록 적용 하였습니다.???/ 확실하게 검색 

 

#Redux-Toolkit

 

보통은 Redux가 유명한 상태관리 라이브러리이긴 한데 Redux-Toolkit은 이 Redux를 좀 더 사용하기 편하게 간소화해준 라이브러리라 프리 프로젝트 때 한 번 쓰고는 맛 들려서 아주 알 차게 쓰고 있다. 북마크 / 로그인 상태 관리 / 태그 의 경우 전역 상태 관리를 통해 편하게 컼포넌트에서 불러와서 업데이트하거나 값을 사용할 수 있었다. 나 같은 경우는 로그인 로직과 관련해서 전역 상태관리를 이용해서 로그아웃이나 로그인 상태에 따른 기능 설정 등에 적용할 수 있었다. 계속 Redux-Toolkit만 쓰다보니 이 간소화된 로직에 익숙해졌는데 그래도 다른 라이브러리들도 한 번씩 사용해보면서 실직적인 내가 느낀 장단점에 대해서도 알아보고 싶다는 생각이 들었다. 

 

각종 상태 관리 라이브러리에 대한 종합 정리는 여기다 했으니 참고하면 좋을 듯 >> 정리 예정 링크 걸 예정 !!! 

 

API 데이터 패칭에서는 Axios 를 사용. 

사실은 call 이라는 별도의 함수를 만들어서 사용했었는데 이 함수가 동일하게 요청되기 때문에 사실 쓰기는 편하지만 결국은 axios 와는 같은 역할을 수행해서 나중에는 어떤 요청에는 헤더에 토큰이 필요하고 어떤 요청에는 토큰이 필요없고 이런 경우가 있어서 이중으로 call 함수와 nexAxios 라는 함수를 쓰기도 하고 그냥 axios 요청을 하기도 해서 사실 코드가 통일화된 느낌은 없어서 굉장히 아쉬웠다. 

 

이런 경우를 위해 React-Query라고 굉장히 편리한 라이브러리가 있는 것으로 알고 있는데 시간상의 문제로 적용해보지 못해서 추후 리팩토링 과정에서 React-Query 를 이용해서 데이터를 패칭해볼 예정이다. 

 

> React-Query 에 대해서 정리 >> 정리 예정 링크 걸 예정 

 

 

 


 

 

      React 함수형 선언을 사용한 이유! 선언형이 아닌 이유

 

이번 프로젝트에서는 평소에 쓰던 선언형이 아닌 함수형 컴포넌트로 사용했다. 

 

export default function Home ( ) {

  return(   // 생략 //    )

}

 

이유 : 

 

 

 

 


 

 

      다른 질문 작성 예정 

 

 

 

 

 

 

 


 

 

      React 최적화 경험? useMemo? useCall?

 

 

 

 

 

 

 

 


 

      로그인 유저 정보를 localStorage 로 사용한 이유

- Cookie, Session 의 차이 

 

 

 

 

 


 

 

 

      아쉬운 점과 업데이트 할 예정 내역 들에 대해서 .. 

 

아쉬운 점이 없었다고 하면 그것은 거짓이다.. 후련한 반 아쉬움 반이 남는 프로젝트였다고 할 수 있겠다. 백엔드도 프론트 들도 공식적인 첫 메인 프로젝트이기 때문에 서로의 소통에서도 서툰 점도 많았고 기술적인 부분에서도 굉장히 서툰 부분들이 많았던 것 같다. 물로 그만큼 배우고 성장했던 부분도 많았지만 말이다. 

 

아쉬운 점은 아무래도 최적화 라는 부분을 크게 신경 쓰지 못하고 우선 구현하는데 급급해서 코드가 전반적으로 깔끔하지 못하고 재사용할 수 있는 부분도 많았는데 이 부분들을 많이 놓친 것 같아 아쉽다. 이외에도 추가적으로 구현하고 싶은 기능(시간 단위로 랭킹 업데이트 하는 기능 , 전체적인 UI 구조 변경 , 유저 정보 및 토큰 쿠키 저장 실패, 자체 로그인 구현 못했던 점.. ) 등 계속 나열하다 보니 어마무시하게 적게 되서 그만 적겠다.. ㅋㅋㅋㅋ

 

 

우선은 연락이 지속적으로 되는 분들과 함께 프로젝트를 업데이트 해 나가고 리팩토링 할 예정이다. 큰 목표로는 우선 다음과 같다. 

 

1. 메인 파트의 시간 단위로 랭킹 업데이트 기능 

2. UI 디자인 수정 

3. 댓글 파트의 불필요한 리랜더링 최소화 

4. 전반적인 코드 구조 정리 

5. React-Query 요청 

6. 로그인 토큰 및 정보 Cookie 혹은 Session으로 저장 

7. 자체 로그인 시도 

8. 무한 스크롤

9. any 타입 정리 

 

 

언젠간 2차 회고를 작성하며 업데이트 된 사항을 뿌듯한 마음으로 공유하고 싶다.