[Main Project 3주차] 9.11 ~ 9.17 | 기능 구현 (팀찾기/팀원찾기 게시판 CRUD, 댓글, 검색/필터)

[Main Project 3주차]  9.11 ~ 9.17
기능 구현 (팀찾기/팀원찾기 게시판 CRUD, 댓글, 검색/필터) 

💬 프로젝트가 끝난 후에 데일리로 정리했던 기록을 보며 프로젝트 전체 과정을 정리하여 4주차로 나누어 작성했습니다.

🔗 1주차

🔗 2주차

3주차: 현재글

🔗 4주차

🔗 데모데이 & 프로젝트 전체 회고

 

👩🏻‍💻 Github Repository https://github.com/sw2377/smoothie

🚀 SUMMARY

 9.11 MON 
- 팀찾기/팀원찾기 게시판 CRUD API Call 테스트 완료

 9.12 TUE 
- front-end 2차 merge

 9.13 WED 
1. 전날 merge 후 발생했던 authInstance 관련 에러 해결
2. 댓글 기능 구현 중!
3. 프론트엔드 임시 배포 (S3)

 9.14 THU 
1. 🧙🏻 3차 멘토링 세션
2. 서버: 탄력전 주소 IP 적용

 9.15 FRY 
1. 팀찾기/팀원찾기 게시판 수정작업
2. 댓글 케이스별 CSS 작업

 9.16 ~ 17 SAT, SUN 
➡️ 프로젝트 마감일이 코앞이라 마무리 작업 진입
1. 팀찾기/팀원찾기 게시판 및 댓글 기능 구현
2. 게시판 검색/필터 기능 구현
3. 기술스택 아이콘 추가

 

📙 3주차 회고

📖 목차

더미데이터 → 실제 데이터를 사용한 기능 구현

댓글로 팀원 수락하고 알림 보내기
  ◾️ 댓글 케이스별 CSS 작업

  ◾️ 댓글 수락하기 버튼 클릭시 알람 구현

AWS S3 프론트 배포

🧙🏻 3차 멘토링 세션

에러 파티의 시작

마무리 작업을 하고 싶었지만…

📝 3주차, 작업하며 나는 무엇을 배웠을까? (What I Learned)

  1. react-quill 사용하기

 

더미데이터 → 실제 데이터를 사용한 기능 구현

 내가 담당했던 두 개의 게시판을 더미 데이터로만 작업하다가, API Call을 통해 실제 데이터를 받아 작업을 하기 시작했다. 포스트맨과 브라우저를 번갈아 가며 HTTP 요청과 테스트를 반복했고, 게시글 조회를 제외한 작성과 수정, 삭제, 댓글은 모두 로그인이 된 상태에서 이루어져야 했기 때문에 테스트 계정을 만들어 테스트를 하기 시작했다. 실제로 내가 작업할 페이지에서는 게시물을 삭제하는 행위는 할 수 없었기 때문에 (삭제는 다른 프론트 팀원분이 작업하는 마이페이지에서만 가능했다) 삭제 기능은 동작을 하는지만 확인했다.

 처음 사용해보는 Redux Toolkit의 createAsyncThunk와 auth를 담당한 팀원분께서 만든 Axios Instance를 사용해 비동기 로직을 작성했다. 사실 이번에 작성한 Redux Toolkit 코드는 강의를 선 수강 후에 강의와 최대한 비슷한 형태로 우리 프로젝트에 적용한거라, 다시 작성해보라고 하면 아마 또 참고코드를 열심히 파헤쳐봐야할 것 같다. 게다가 thunk와 slice를 따로 구분하여, slice의 extraReducers에서 pending, fulfilled, rejected 시에 어떤 행동을 하라고 매번 코드를 작성하는게 맞는 방법인지 의문이 들었다. Redux Toolkit에서 어떠한 방식으로 data를 fetch하는지 더 찾아볼 필요성이 있다고 느꼈다.

projectsThunks.ts, projectsSlice.ts

 

댓글로 팀원 수락하고 알림 보내기

 팀원찾기 게시판에는 댓글기능이 있었기 때문에 댓글 기능도 구현을 해야 했다. 기획 회의에서 프로젝트 칸반을 통해 프로젝트를 관리(팀원 수락 등을 포함)하는 기능을 없애는 대신 댓글으로 대체하자고 했기 때문에 댓글 기능 또한 필수였는데, 간단할 줄 알았던 댓글도 생각보다 할 일이 많았다.

 

◾️ 댓글 케이스별 CSS 작업

댓글 UI 구현중

 

 우선 첫번째로, 댓글의 contents 케이스별로 CSS 작업이 이루어져야 했다. 댓글을 통해 팀원 수락과 거절을 할 수 있도록 구현하기 위해 프로젝트를 지원하기 위한 ‘지원댓글’과 일반적으로 댓글을 작성하는 ‘일반댓글’로 나뉘어졌다.

1. 일반댓글 ➡️ width 100%
2. 지원댓글 ➡️ width 조절 필요
  1) 수락/거절 전: 수락하기 거절하기 버튼 노출
  2) 수락/거절 후: 수락 또는 거절 멘트 노출

 

 또한 댓글 작성자만 댓글을 수정/삭제가 가능했고, 지원댓글이 수락된 후에는 작성자도 수정/삭제가 불가했다. 이에 맞춰 케이스 작업을 하는게 꽤 번거로웠다.

 

DetailComments.tsx

 결국 300줄이 넘게 된 댓글 컴포넌트 또한 추후 리팩토링할 생각을 가지고, 우선은 기능 구현에만 매진했다.

 

◾️ 댓글 수락하기 버튼 클릭시 알람 구현

 두번째로 댓글의 수락하기 버튼을 누르면 작성자에게 알림이 가는 알람시스템도 구현하고자 했기 때문에 이에 맞는 API 요청도 보내주어야 했다.

 이와 관련해서도 백엔드 팀원과 이야기를 몇 번 나누었었는데, 처음에는 복잡했던 API Call이 멘토링 세션 후 정말 간단하게 변경되기도 했었다.

✏️ 백엔드 팀원과 회의를 할 때 기억해야 할 부분들을 메모해두었다.

# 알람
- alermType : 팀원 수락에 대한 거면 0(ACCEPT)
  (다른 알람이 있을 수도 있어서 확장성을 위해 추가한 타입)
- targetId : 댓글 작성자의 ID
- memberId : 멤버보드의 ID

- 멤버보드(팀원찾기게시판) 생성할 때 /projects 로 (post req: accountId 작성자아이디, memberBoardId 게시글아이디)
▶︎ 백엔드에서 처리됨.

- 수락버튼 클릭했을 때
  - /projects 로 (post req: accountId 댓글작성자아이디, memberBoardId 게시글아이디)
  - /alerms 로 (post req: alermType 알람타입, accountId 댓글작성자아이디, memberBoardId 게시글아이디)
  - /replys/{replyId} 로 (patch req: acceptType)
  ▶︎ 수락/거절 확인 후에는 수정/삭제 안되도록.

⬇︎ 변경

- 댓글수정은 content만 보내는걸로 변경 (acceptType 제외)
- reply/accept/{replyId} → 수락버튼 클릭했을 때
- 프로젝트 수락은 acceptType 1 프로젝트 거절은 acceptType 2

 

 처음에는 댓글의 “수락하기” 버튼을 눌렀을 때 서버 측의 각 다른 엔드포인트로 3번의 요청을 보내는 방향으로 백엔드 쪽에서 설계를 하셨길래, 이렇게 3번의 요청을 보내는게 괜찮은지, 실무에서도 이러한 방식으로 사용이 되는지 궁금해서 멘토링 시간에 질문을 했었다. 백엔드 팀원분도 관련해서 백엔드 멘토링 시간에 질문을 하셨던 것 같다. 다음날 회의를 하는데 요청을 한 번으로 줄이는 방향으로 수정하고, 나머지 로직은 백엔드에서 처리를 하기로 했다고 하셨다 🥰

 이미 HTTP 통신이 잘 되는 상태에서 요청 하나만 보내면 되었기 때문에, 수월하게 해결할 수 있었다.

 

AWS S3 프론트 배포

 백엔드의 배포를 담당하신 팀원분께서 세팅해둔 AWS S3에 프론트엔드 임시 배포를 했다. 프리 프로젝트 때도 S3로 프론트 배포를 했기 때문에 이 부분은 어렵지 않게 진행할 수 있었다.

 가능하다면 Vercel로 배포를 해보고 싶었는데, Vercel로 배포시 서버측 https 이슈가 있기 때문에 서버에서도 세팅을 해주어야 한다고도 했고, 이 즈음 계속해서 프로젝트에 에러가 반복되었기 때문에 말을 꺼낼 시간이 없었다.

 여튼 S3 프론트 배포는 원활하게 잘 진행되었다.

 

🧙🏻 3차 멘토링 세션

 멘토링 세션의 질문을 적극적으로 활용한 나..

 작업을 하다보니 API 명세서에 페이지별 게시글 리스트에 대한 GET 요청과 게시글 하나에 대한 GET 요청이 따로 있는 것을 발견했다. 게시글 자체에 대한 response는 같았고, 페이지별 게시글 리스트의 GET 요청은 page에 대한 정보가 추가되어 있었다.

 이럴 경우, 예를 들어 팀원찾기 게시판의 "memberBoardId": 1의 상세페이지 데이터를 가져와야 한다면,

 

  1. 팀원찾기 게시글 리스트 response에서 "memberBoardId": 1을 찾아 상세페이지를 렌더링하는 방법이 나은지

  2. 팀원찾기 게시글 하나에 다시 요청을 보내 "memberBoardId": 1의 data를 가져오는 방법이 나은지

 

 작업을 하다가 문득 궁금해졌다. 이전에 네트워크 요청은 비용이 비싸다는 내용을 들은 적이 있어 다시 요청을 보내는 것보다는 기존에 받은 응답에서 해당 데이터를 찾는 방법이 더 낫지 않을까? 라고 생각을 했는데 정작 구현은 두번째 방법으로 했었던 나란 사람… 🫠🫠🫠

 여튼 결론은 새로 요청하는 방법이 낫다는 것이었다. (1번 방법) 왜냐하면 상세페이지로 진입하는 동안 정보가 달라질 수 있기 때문에 사용자에게 항상 업데이트된 정보를 보여줘야 한다면 매번 요청을 하는 방법을 사용해야 한다는 것이다. 즉, 중요한건 수시로 바뀌는 내용인지, 그렇지 않은지를 파악하는게 중요하다.

 

이 뿐만 아니라 다양한 부분을 배울 수 있었는데,

 

• 마이페이지의 라우팅의 경우 url을 mypage/5 대신 mypage/userid 이런식으로 유니크한 값이 오도록 구현하는 것이 바람직하다.

• 조건부 렌더링시 && 보다 삼항연산자를 선호 (isLogin ? <Hello /> : <World />)
  → 만약 코드를 잘못 작성했을 때 isLogin && <Hello /> 이런 식의 작성법은 의도치 않게 0이 화면에 표현되는 경우를 종종 볼 수 있었다고 한다.

• 최대한 작은 단위로 작성
  → 뭐라고 설명해야 딱 맞는 용어인지 모르겠는데, 예를 들면 아래와 같은 형식이다.

<ActionButton buttonType={"submit"}>
  {location.pathname.startsWith("/projectlist/edit") &&
    "카드 수정하기"}
  {location.pathname.startsWith("/projectlist/new") &&
    "카드 등록하기"}
</ActionButton>

// location.pathname.startsWith("/projectlist/edit") 
// 위 표현 대신 아래처럼,

{ EDIT_CARD ? "카드 수정하기" : "카드 등록하기" }
// 최대한 최소로 줄이는 것을 추천
// 물론 비교적 간단한 구현일 때는 가독성이 떨어지지는 않지만
// 구조가 좀 복잡해지면 가독성이 떨어질 수 있으니 이는 개인이 잘 판단하여 작업하면 될듯!

 

에러 파티의 시작

 HTTP 통신과 요청을 하고, 데이터를 주고 받으면서 더 이상 로컬에서만 작업하던 안정성이 사라지기 시작했다. 전날까지만 해도 서버와 통신이 잘 되었는데, 다음날이 되니 갑자기 에러가 나기도 하고(물론 중간에 어딘가 잘못되었겠지만), merge를 하고 나니 되던게 또 안되기도 하고… 아주 난장판이었다. 무난하게 잘 흘러가고 있어 앞으로도 그럴줄만 알았던 예상과는 달리 에러파티가 시작된 것이었다.

 이런저런 에러가 있었지만, 다른 팀원들이 작업하던 코드에서 났던 에러라 어떤 부분이 잘못되었을까 추측만 할 뿐 내가 볼 수 있는 코드가 없었다. 약간의 무력감을 느끼면서 내가 할 수 있는 다른 작업을 먼저 진행해야만 했다.

 

 

🧐 당시에는 갑자기 잘 되던 코드가 merge 후에 되지 않고, 이런저런 문제 상황에 부딪히자 어떻게 해결해야 할지 서툴렀다. 서버 쪽 코드에서 난 에러는 둘째치고, 초반에 프론트 쪽의 authInstance 관련해서도 난 에러가 있었는데, 이 부분을 다른 프론트 팀원이 작업했고, 나는 axios intersepter(? instance?)를 사용해본이 없었기 때문에 무엇이 문제인지 예측하기가 어려웠다. 내가 작업하던 부분에도 해당 에러가 영향을 미쳤기 때문에 처음에는 무엇이 문제인지 살펴보기는 했었는데, 잘 되지 않자 해야할 다른 작업도 많아서 해당 팀원분이 해결을 해주겠지, 라는 생각으로 한 발 뒤로 물러나있었던 것 같다. 우리 프론트 팀원분도 문제가 뭔지 찾기 힘들어하는 것 같기는 했었는데, 결국엔 해결을 했었다. 당시엔 내 작업하는데도 바빠서 남의 코드에서 난 에러를 볼 여유가 없었는데, 지금 생각해보니 나의 그런 대처가 올바른 방향이었을까, 라는 생각이 든다. 에러의 원인을 검색해서 찾아보는데 시간을 조금만 더 들였더라면, 조금 더 마음의 여유를 가졌더라면, 좀 더 함께 생각해 봤더라면 이라는 생각이 들었던 것 같다. 서버 쪽 코드에서 에러가 발생했을 때에도 마찬가지였다. Java로 작성된 코드를 더더욱 읽을 수가 없었기 때문에 에러는 물론이고 해결방안도 예측할 수가 없었다. 하지만 파이썬을 공부해봤던 다른 프론트 팀원분이 이런저런 방향으로 무엇이 문제일까 예측하고, 의견을 공유해주는 모습을 보면서 몇몇 생각이 들었던 것 같다. 모든 걸 다 알 수는 없겠지만, 조금만 더 넓게 공부를 하면 다양한 상황에 대해 조금 더 유연한 대처가 될 것 같다는 생각도 들었다.

 

마무리 작업을 하고 싶었지만…

 3주차에 들어오니 마음이 급해졌다. 시간이 얼마 남지 않은 것 같은데, 해야할 일이 너무 많았던 것이다. 다행히도 마지막 주말에 서버를 12시 ~ 9시까지 열어주기로 해서 그 시간동안은 서버 통신이 필요한 작업을 계속해서 할 수 있었다.

 주말동안 2개의 게시판과 댓글의 중요도 “상”인 기능은 다 구현을 마쳤고, 검색과 필터 기능도 마무리를 했다. 완벽하지는 않았지만, 기능 구현이 되는 것에 의미를 두었다.

 원래의 계획이라면 이번주에 기능 구현을 마무리하고, 팀원들과 다 함께 유저플로우를 따라 테스트를 했었어야 했는데 에러파티가 나서 계획대로 되지가 않았다. 또한 마지막까지 메인페이지 구성도 하지 않았기 때문에 메인페이지에 대한 고민도 빠르게 했었어야 했다. 에러난 김에 이를 해결할 동안 메인페이지를 어떻게 구현할지에 대한 고민을 하기로 했다.

 예상치 못한 에러로 팀 분위기도 약간 싸늘해졌다. 거의 자정을 향해가는 늦은 밤이어서 다들 더 예민해져 있었던 것 같기도 하다. 문제의 원인이 무엇인지도 잘 모르겠는데, 마감을 몇일 앞두고 갑자기 이런 문제가 발생한 것도 싸늘한 분위기에 한 몫 했던 것 같다. 시간이 널널했더라면 좀 더 여유를 가지고 차근차근 생각해볼 문제였을텐데. 그렇게 우리의 마무리 작업은 미뤄지고 있었다.

 

---

📝 3주차, 작업하며 나는 무엇을 배웠을까? (What I Learned)

1. react-quill 사용하기

GitHub - zenoamaro/react-quill: A Quill component for React.

 웹 에디터를 좀 더 빠르게 구현하기 위해 react-quill 라이브러리를 사용했다. 관련된 자료가 많아서 빠르게 세팅할 수 있었다. 다만 세팅 후에 웹 에디터에 입력된 내용을 화면에 출력하고자 할 때는 아래와 같이 입력해주어야 했다.

 

<div dangerouslySetInnerHTML={{ __html: content }} />

 → React에서는 보안 이슈가 있어 기본적으로 HTML 태그를 직접 삽입할 수 없게 설정되어 있는데, 위험하지만 dangerouslySetInnerHTML 이 속성을 사용해 HTML 문법을 사용하겠다는 것이다. 이렇게 코드를 작성하게 되면 공격자가 악의적 코드를 웹 브라우저에서 실행시키는 XSS(Cross Site Script) 공격에 취약해지는데, 이런 경우 입력 값의 보안 검사를 통해 위험성이 있을 문제를 예방해야 한다고 한다.

 이번 프로젝트에서는 보안에 관련된 사항을 적용하지 않았지만, 다시 생각해보니 매우 중요한 문제가 아닐 수 없다는 생각이 들었다. React에서는 DOMPurify와 같은 라이브러리를 사용하여 보안 검사를 할 수 있다고 한다.

 

 ⭐ react-quill 사용하기 외에도 useParams()에 타입을 지정하는 방법, createAsyncThunk에서 파라미터 2개 이상 넘기기 등 기능 구현을 하며 모르는 부분을 많이 배웠었는데, 막상 정리를 하려고 하니 내가 배운걸 알고 사용한건지 확신이 들지 않는다. 지금 생각해보니 검색해서 찾았던 방법을 적용했을 뿐, 같은 문제를 또다시 만난다면 다시 검색하게 될 것 같으니 여러번 만나서 익숙해지던지, 노트 한켠에 잘 정리해두던지 해야겠다.