5월 21일 토요일 15시 40분부터 약 40분 정도의 발표(현재 진행상황) 및 현업 개발자분들의 피드백 시간이 있었습니다.
발표를 하느라 정신이 없었는데 팀원 분께서 피드백 내용을 잘 정리해주셨습니다👍

👨‍💻발표 요약

※ 백엔드 부분도 같이 발표하였으나, 편의상 FE 부분만 정리해서 올립니다

✅ Service Architecture

✅ 기술 선정 및 도입 이유

📍JavaScript → TypeScript

프론트에서는 javascript를 기반으로 React를 사용하였지만 팀원과의 협의 끝에 TypeScript로 마이그레이션을 완료했고 작업을 진행 중에 있습니다.

프로젝트 기간 중 타입스크립트를 공부해야하는 리스크가 있지만, 협업에 있어서 코드의 목적을 명시하고 사전에 오류를 방지할 수 있다는 점에서 굉장히 이점이 있을 거라고 생각하였습니다.

📍Redux Toolkit

상태관리는 리덕스를 도입하였습니다.
요즘 뜨고 있는 주스탄드나 리코일, 리액트 쿼리를 공부해서 진행을 할까 했지만,

기본에 충실하자 생각을 했고 아직도 가장 많이 쓰이는 상태관리 툴인 리덕스를 사용하기로 하였습니다.

📍Tailwind CSS

CSS는 tailwind를 사용하였습니다. 무난하게 스타일드 컴포넌트를 사용할까 했지만, 요즘 뜨고 있는 tailwind에 눈을 돌리게 되었습니다.

테일윈드 또한 약간의 러닝커브가 있지만, 익숙해지면 어떤 방식보다 편하게 코드를 작성하게 될 수 있을거라 생각하였고
어떤식으로 생산적인 클래스를 생성할지, 클래스명을 지을지 고민하는 시간도 줄거라 생각해서 도입하게되었습니다.

✅ Trouble Shooting

기본적으로 typescript를 처음 접해봤기 때문에 타입 선언에 익숙치 않은 기본적인 문제가 있었으나, 지금은 어느정도 다 해결이 된 상황입니다.

문제정의

리덕스툴킷 내 라우팅 처리시 A non-serializable value was detected in an action 오류가 발생

사실수집

useNavigate객체를 리덕스의 액션함수의 매개변수로 전송. 넘겨받은 useNavigate함수로 라우팅
진행시 A non-serializable value was detected in an action 오류가 발생 확인

원인추론

Promises, Symbols, functions, class와같은 직렬화 불가능한 값을 Redux에 전송해서 생긴 에러

조치방안

미들웨어에 serializableCheck를 false로 설정.

✅ 추후 개발 및 기술적인 도전 계획

📍PWA 도입

초기 기획 자체를 모바일 친화적으로 잡았습니다.
PWA를 이용하여 사용자들에게 더욱 친숙한 경험을 줄 예정입니다.

📍카카오톡 공유하기 기능

카카오톡 API를 이용해 공유하기를 넣고, 사용자를 유치할 예정입니다.

📍UI&UX 개선

프론트엔드 개발의 가장 중요한 점의 하나가 UI&UX 개선이라고 생각합니다.
프론트엔드 개발자만이 할 수 있는 기술적인 세밀한 부분을 개선해 나갈 예정입니다.

📍코드 리팩토링

오늘 적은 코드가 내일 보았을 때 형편 없을지라도 그게 오늘의 최선이었다고 생각합니다.

추후 더욱 발전 시켜나갈 예정입니다.

⚒️ FE 피드백

✅ useNavigation 리덕스 액션함수 매개변수로 보낸 것에대한 멘토 피드백

우선 serializableCheck: false 로 한 것은 문제해결된 것이 아님. 애초에 class, promise, symbol, function 같은 것이 들어가서는 안 됨.

상호작용이 많은 페이지를 사회에서 요구됨에 따라 상태관리의 중요성 높아지고, 이를 잘 활용할 수 있는 것이 리액트.

리액트나 뷰, 앵귤러가 상태관리를 잘 활용할 수 있는 것이 큰 장점. 상태관리에서 기본적으로 직렬화가 불가능한 값을 받는 것을 금지하고있는데, 지금 useNavigation을 액션함수에 넣고있는 구조는 상태관리 방식이 잘못된 것이라 생각.

props로 다른 곳에 보내거나, export를 사용해서 다른 방식으로 사용하는 방법을 생각해내야함.

✅ 리액트 네이티브에 대한 멘토의 생각

모바일환경을 고려했으면 왜 리액트 네이티브로 프로젝트를 진행을 안 했나. 리액트 네이티브도 프론트엔드 개발자들이 하는 역할 중 하나가 될 것.

✅ 왜 로그인을 JWT토큰을 쓰나

일반적으로 쿠키나 세션을 이용해서 로그인을 구현하는 방법이 있음. JWT토큰을 굳이 쓸 필요가 없어보이는데 억지로 쓰는 듯한 느낌을 받음(1조 ~ 8조 전부).

✅ 육각형 그래프 구현에 대한 멘토의 생각

데이터 시각화는 프론트엔드 개발자의 핵심. 다양한 그래프를 활용해보는 것은 좋음.

✅ 테일윈드에 대한 멘토의 생각

테일윈드는 정말 좋은 라이브러리이지만, 사실 현재 우리들한테는 적합하지않음. CSS경험에 대한 기회를 박탈당하게됨. 다음 프로젝트를 한다면 테일윈드는 안 쓰는게 좋음.

✅ 아토믹디자인을 사용한 것에 대한 멘토의 생각

굉장히 긍정적으로 생각함. 현업에서도 많이 사용하는 디자인패턴. 다만 현재까지 아토믹디자인으로서 부족함. molecules를 지나가면서 컴포넌트로 이루어져있는데, 아직도 html, jsx 이런 부분들이 남아있음. 경로 지정도 tsconfig에 작성하여 미리 지정할 수 있음. 아톰 구조를 좀 더 강화시키면 좋은 구조의 프로젝트 될 것이라 생각함.

✅ 커피취향 질문 6가지는 전부 라우팅처리한 것에 대한 멘토생각

만약 질문 100개면 라우팅처리 100개 할 것인가. 페이지 하나에 질문 내용만 바뀌는 건데, 페이지 하나에 라우트처리가 다 되야함. dispatch로해서 리덕스 상태관리를 이용해서 처리해야함. 결국 질문들안에, 그 상태에 따라 페이지 안에 내용만 바뀌면 됨. 구현이 어렵지않음. 현재 라우팅처리를 많이 하는 것은 굉장히 안 좋은 방향임. 필수 리펙토링 항목이라 생각.

🔥중간 발표를 마치며

미처 생각치 못했던 문제를 지적해주신 것도 있었고, 안일하게 넘어갔던 부분도 콕콕 찝어주셔서 굉장히 도움이 되는 시간이었습니다.
중간 발표가 끝나고 팀원 분과 이야기를 나눈 결과 우선적으로 다음주 화요일까지 기능구현을 끝내고, 코드 리팩토링에 힘을 실을 생각입니다.
이제 최종 제출일 까지 약 일주일 정도 남았는데 더욱 힘내도록 하겠습니다!!