회의록 - To-Letter/To-Letter-front GitHub Wiki

회의록 작성 시 최신 회의록이 위로 오게 해주세요~~

프론트 마이그레이션 이후로 회의 일정 미룸

-> .

가.

가.

가.

편지함 구조 변경(기존의 MailBox.tsx)

1. 레이아웃 구성 (layout.tsx)
Tab으로 구성된 메뉴 탭 리스트 구현
받은 편지함/보낸 편지함 분리

2. 주요 컴포넌트 구조
   ├── ReceiveLetters.tsx (받은 편지함)
   ├── SendLetters.tsx (보낸 편지함)
   └── LetterList.tsx
       └── LetterItem.tsx (개별 편지 아이템)

3. 파일 구조 정규화
/letter/letterbox/receive - 받은 편지함 경로
/letter/letterbox/send - 보낸 편지함 경로

4. 컴포넌트 모듈화
편지 목록과 개별 편지 아이템을 분리하여 재사용성 향상
Tab 메뉴를 통한 직관적인 네비게이션 구현

이러한 구조 변경을 통해 편지함 기능의 사용성 개선 및 유지보수성 향상을 목표로 함.

1. 버전 확인 요청  
현재 패키지가
 "next": "15.0.3",
 "react": "^18.3.1",
 "react-dom": "^18.3.1",
와 같이 설정 되어 있는데, 해당 버전 설치할 경우 제 쪽에서는 recoil 버전 충돌이 생기는 상황입니다.
18.3 버전에 대한 대응이 안된다는 정보를 알게 되어 아래와 같이 변경하였고 문제 없이 돌아가는 것을 확인하였습니당
 "next": "13.5.5",
 "react": "^18.2.0",
 "react-dom": "^18.2.0",

제 쪽에서만 이렇게 뜨는 건지 교차 검증이 필요할 것 같아 회의록 남깁니다! 확인 부탁드립니다!
-> 답변 : 저는 위의 첫 번째 버전(그니까 recoil 버전 충돌이 나는 버전)으로 되어있고 아직 웹에 띄어보지 않아서
모르겠지만 혹시 실행해 보고 충돌 나면 바꾸겠습니다.

2. 윤미 - 끄적이는거...
menuTab에 대해서 authMenu, myPageMune 이렇게 다 따로 있으면 ... 재활용 측면에서 너무 별로 아닌가 싶어서
상수(탭 타이틀, 경로 및 탭 옵션과 어디 쪽 메뉴인지) 파일을 따로 생성하여 공통적인 menuTab 하나의 컴포넌트로
사용하게 만들고 싶었습니다..
1. layout에서 불러온 상수가 menuTab props로 넘기기만 하면 undefined
2. 파일을 분리한 것이 문제인가 싶어 layout 자체에서 선언하여 사용했으나 undefined
3. layout에서 쓰는 것 자체가 문제라는 판단 하에 그냥 MenuTab에서 상수 데이터를 불러와 처리하였습니다!

1. 편지삭제, 편지 삭제 모달 구조 및 편지삭제 모달 기능 구조
    -> 기존 address 모달과 비슷한 형태(props로 관리되는 자식 컴포넌트)로, 
      도메인 처리하기로 함(기존 편지 삭제 모달과 병렬Parallel Routes로 떠야함)
    -> /letter/deleteLetter/1
       // 1은 해당 letter id

2. accountAtom type 존재 의의
    -> 분기를 위한 값 저장은 불필요할 것 같다는 의견, recoil state는 최대한 간결하게 가자
    -> 삭제

3. 컴포넌트 주석 어떻게 달 것인가
    -> 컴포넌트 변수 //처리
    -> 컴포넌트 내부 함수 /** 주석 */

4. 코드 이식 디자인패턴 폴더 구조
    -> 페이지 코드가 organisms 폴더에 바로 들어갈 수 있도록 하여 수정 간편화

Login 컴포넌트 쪼개고 이를 page.tsx에 넣는 중인데, Routes 구조 관련하여 논의하고 싶은 내용이 생겨 회의록 남깁니다!
논의점에 기재되어야 함이 맞지만 마이그레이션 부분은 따로 기재하기로 했던 것 때문에
데이터가 여기저기 분산되어있으면 찾기 힘들 것 같아 그냥 냅다 회의록에 넣었습니다!

그 일단 
`Intercepting Routes는 특정 경로에서 기존 UI를 유지하면서 추가 콘텐츠(예: 모달)를 렌더링하려는 경우 유용합니다.
이는 사용자가 새 페이지로 완전히 이동하지 않고, 현재 페이지의 상태를 유지한 채로 추가 인터페이스를 띄우고 싶을 때 필요합니다.`
이 부분에 대해서 생각해보았는데, 
기존 UI를 유지하면서 추가 인터페이스가 필요할 때를 의미한다는 부분에서 제가 판단을 잘못한게 아닌가라는 생각이 들었습니다.. 
저는 이걸 백그라운드에 깔린 저희 방을 유지하면서 우리 모달을 켠다! 라는 느낌으로 받아들였는데 
다시 찾고 읽으면 읽을수록... 뭔가 
Intercepting Routes는 기존 UI가 유지되어야 하고, 그 위에 새로운 콘텐츠가 기존 UI와 연관된 형태로 렌더링될 때
유용하다고 느껴졌습니다..
(pc버전 인스타에서 보고있는 게시글을 배경으로 두고 모달로 한 번 더 띄우는 그런 상황에 적합할 것 같은 느낌이죠..!)

저희의 경우 등장하는 모달들이 전부 ThreeJs UI와 별개로 동작하니까 굳이 Intercepting Routes를 사용할 필요가 없지 않을까요..??
Intercepting Routes를 배제할 경우 폴더 구조 측면에서 더 간단하다는 이득도 있다고 생각합니다..!
그리고 오빠가 좀 ,,, 덜,,, 빡세지지 않을까,,, 하는....
의견 부탁드립니다!

답변
저도 사실 구현하면서 패러렐 라우트는 우리한테 유용한거 같은데 인터셉터 라우터 정확히 (.)얘는 중간에 기존 페이지를 유지하면서
url을 가로채야할때(모달, 팝업 등) 활용하는것이라고 해서 쓰긴 했는데 말 들어보니 우리 프로젝트는 백그라운드가 다 three.js로
동작하니까 필요 없을거 같다는 생각도 드네요.. 그럼 한번 인터셉터 라우트는 삭제하는 방향으로 가보겠습니다.
그리고 저도 마이그레이션하면서 몇개 문제가 생겨서 남겨놓겠습니다..
1. errorpage.tsx를 폴더 어디에다가 넣어야 하나(임시로 commonui에 넣음)
2. Desk.tsx에 newletteralram 이거 어떤식으로 동작하는지 이해를 못하겠어서 못고침
3. components/Scenery에 파일들중 useEffect 의존성배열 부분에 노란줄이 뜨는곳이 다수가 있으나 내 판단하에 추가하는것은
아닌거 같아서 내비둠 한번 봐보길 바람

답변
확인 감사합니다~!~! 당장 auth 폴더는 지금 만드는 것 때문에 폴더명에서 (.) 이 부분 지우고 가겠습니다!
아래는 말해준 내용 답변임다
1. errorpage.tsx가 nextjs 상에서는 app/error.tsx에 들어가는 친구 맞져..?? 
   버튼 텍스트 박스 조합이라 나중에 template화 해서 거기다 넣어두고 error.tsx에서 랜더링할 수 있도록 처리하겠습니다
2. desk에서 불러오는 컴포넌트는 맞는데 newletteralram 편지더미가 뜨는 시점이 좀... 달라서 헷갈리실 것 같습니다!
   sse 통신을 열고 새로운 스레드가 들어오면 편지 더미를 띄우는 형식인데, 이부분 어차피 완성된게 아니라서 
   넘어가셔도 될 것 같아요
3. 풍경 useEffect 의존성배열 확인하겠습니다! 

• html 요소: https://developer.mozilla.org/ko/docs/Web/HTML/Element
  
• 시맨틱 태그: https://velog.io/@remon/%EC%8B%9C%EB%A7%A8%ED%8B%B1-%ED%83%9C%EA%B7%B8Semantic-Tag%EB%9E%80
  

주제: nextJs 마이그레이션 3차  
1. 주제: 윤미 작업사항 중 논의점 
주소 검색 현재 
  onChangheAddress: (address: string) => void // 완성된 주소(address)를 return 하는 형식으로 사용 중
  onClickOpenModal: () => void // 모달 켜고 끄는 함수
위와 같은 props를 받아 처리되고 있는데, @modal로 관리 안하고 지금 형태 그대로 가도 될 지
사용 시맨틱 태그 협의 및 css 대응 필요하여 멈춤
-> 처리 완료, 라우팅 시스템으로 편입 
-> params로 넘기기로(기존 입력 폼이 유지되는지 확인 필요)
-> 컴포넌트 자르기 맨 마지막 순서로

menuTab은 만들면서 확인의 필요성(하단 컨텐츠 부분과 유기적으로 사용)을 느껴서 뒷배경 완성 필요
->  npm run dev 성공을 목표로~! 작업

2. 재윤 작업 사항 중 논의점
작업 효율성을 위해 아래와 같은 역할 분담 제안
- 재윤 기존 코드를 이용하여 도메인 폴더 정리 및 이식
- 윤미 디자인 패턴을 적용한 컴포넌트 쪼개기

3. 시맨틱 태그 협의
모달 창 - div 태그
메뉴 탭 - header>nav
하단 콘텐츠 - main> 각각의 내용 section 

4. 할일 정리
재윤: 기존 코드를 이용하여 도메인 폴더 정리 및 이식 (요청사항: 배경,,, 짜주세여,,, 방, 책상, 침대,, 풍경 기타 등등)
윤미: 디자인 패턴을 적용한 컴포넌트 쪼개기(요청사항: 시맨틱 태그 신경써주세요)

주제: nextJs 마이그레이션 2차  
1. 주제: 아토믹 디자인 패턴 적용(컴포넌트 재사용성을 높이자!)
현재 상의하고 있는 공통 컴포넌트(box, Text, Button)이 다른 공통 컴포넌트에서 사용되고 
또, 해당 공통컴포넌트가 또 더 큰 컴포넌트에서 사용된다는 점을 고려하여 아토믹 디자인패턴 사용 협의

  (1) 원자 - 모달박스, 버튼, 텍스트(can't login에만 onClick추가), 탭, 리스트 박스
  (2) 분자 - 토스트메세지, 인풋라벨, 메뉴탭, 서머리(서머리랩, 팁박스), 메일리스트아이템
  (3) 유기체(여기서부터 시캔틱 태그 신경쓰기) - 검색창, 메일리스트 (+ 메일함, 메일삭제함 버튼)
  (4) 탬플릿(동일) - 주소검색창

2. 주제: 네이밍
변수명, 함수, 객체 ->카멜케이스
폴더 -> 소문자
네이밍 = 명사+동사

3. 탭 부분 세부
탭부분
탭 원자 -> 옵션으로 선택된 탭은 밑줄이나 음영효과에 선택 주기
탭을 합친거는 분자

4. 편지함
받은, 보낸 편지 데이터 받는거 분리

5. 내일까지
윤미 - 탭, 메뉴탭, 서머리(서머리랩, 팁박스), 주소검색창
재윤 - 라우팅 처리 (가능하면+ 리스트 박스, 메일리스트아이템, 메일리스트)
++ 추가: 말하는걸 잊었는데 유기체폴더에 들어가는 것부터는 시맨틱 태그 써야하니까 
프로젝트 [perf]seo 향상 부분 이슈화해서 커밋메시지 푸터(이슈번호) 2개 다는게 좋을 것 같아요!

-> 프론트 3, 4번 이전 선행 작업이 필요하다고 판단

-> 토큰 받아오는 링크 프론트에서 처리하기로 함

https://gifted-nation-dc1.notion.site/next-js-1464c589856f804cad88d8c278b26ae8?pvs=4
https://temporal-mantis-680.notion.site/nextJS-15396fbf72b0806ba5d7f4806c17486f?pvs=4
-> 바꿀 내용 정리본을 바탕으로 논의 시작(할일목록 브리핑 참조)

도메인 폴더 구조 협의(모달창 - parellel routes + intercepting routes)
모달창 중 겹치는 디자인을 바탕으로 공통 컴포넌트 자를거 협의(Box, Text, Button, InputForm 제작)
프론트 따로 회의 잡기로

가. nextjs 변환 작업(0)
나. 프론트 배포(1) - 차후
다. 로그인 에러 처리, jwt 토큰 수정(2) - 차후

가. https 변경
나. 실시간 검색

가. nextjs 변환 작업(0)
나. 프론트 배포(1) - 차후
다. 실시간 편지 도착 + 안 읽은 편지함 추가(3) - 차후

백엔드 api 통신 구조 논의 3차 
주제: 보안을,,, 챙겨보자...
1. 회의 주제: 
(jwt 토큰 리프레시 토큰 저장소 -> 헤더 -> 쿠키 변경 중)
보안상의 이유로 세션스토리지에 토큰 저장하는 방식 폐기
엑세스 토큰 axios 기본 헤더 처리

사이드 이펙트
-> 로그인 유무 처리: 삭제하려했으나 토큰 재발급시 로그아웃 처리 대응이 어렵다는 결론으로
   세션 스토리지에 토큰 저장 안하고 "isLogin<bool>" 처리
	-> 세션 스토리지서비스 코드 변경
	-> sendApi -> 헤더 기본 설정 삭제
	-> 외부api 헤더설정 자르기

2. 회의 주제: 
(jwt 토큰 리프레시 토큰 저장소 -> 헤더 -> 쿠키 변경 중)

[백엔드 논의 요청 사항]
(1) 리이슈 체크 만드는가?
(2) 토큰 재발급 방식
요청->response 재발급(현재)

체크->요청api
체크->재발급
- 투레터에는 무거운 요청 api가 없어서 굳이 필요할까 싶지만 논의사항으로 기재

(3) 헤더에 리프레시 토큰 존재성


#### 기타 과제: 오프라인 회의 때 nextjs 마이그레이션을 위한 큰그림 그려오기

-> AccessToken은 지금처럼 header에, RefreshToken은 Cookie에 저장하기
-> 해당 방법이 보안적인 측면에서 균형적이라고 생각함.

-> next.js 공부해옴

-> 실시간 메일 온 거 알람이 뜨고도 메일을 읽지 않으면 안 읽은 메일을 쌓아두기로 한 UI를 구현하기 위해 해당 api 구현해놓음
-> 지금 현재 편지함에 읽은 편지, 안 읽은 편지를 확인(아이콘)할 수 있도록 수정할 예정
-> 안 읽은 메일함을 따로 만드는게 아니라 실시간 알림과 병합하여 UI 기능 추가하도록 정리함
-> 읽은 메일함 api 삭제

가. 작업 분량 UI 수정
나. jwt 토큰 수정
다. 받은 편지함 읽음 처리 수정하기

가. 실시간 검색 api 추가
나. jwt 토큰 수정

가. 실시간 편지 도착 + 안 읽은 편지함 추가
나. pr contributor 확인하기

-> 지금 받은, 보낸 편지 데이터를 한번에 받아와서 그 데이터로 개별 편지 열람까지 하고 있어서.. 혹시 이거 말고 필요한 상황이 있나 모르겠어서 적어둡니다..

필요 없음. 백엔드에서 해당 api삭제하기로

-> 공유하기 만들고 있는데 브리핑에 보인 사진처럼 기본 공유하기 기능에서 그칠것인지 아니면 여기에 각종 SNS들 버튼을 넣어서 만들건지 ex)카톡, 인스타 등(참고로 SNS버튼 넣어서 만드려면 SNS API 다 가져오고 공유하기 모달창 커스텀해야함^^..)

공유하기 기능으로 링크복사랑 카톡 공유 버튼 만들기 UI 이벤트 위치는 게시판 사진 위치 바꿔서 공유하기 버튼으로 하기

무한스크롤 api 제작하기로 결정

프론트 둘 다 공부해오기~

-> 삭제가 한 번에 되었음 좋겠습니다!

현재 한개만 개별로 삭제되어서 전체, 부분 삭제 api 백엔드에서 만들어주기로
-> 검색 api가 가능했으면 좋겠어요!
백엔드에서 실시간 검색과 무한 스크롤 대응 api만들어주기
-> 편지 데이터가 많아질 때의 처리 방안 필요
편지 데이터가 많아지면 프론트에서 처리하기 힘들어질수도 있음, 그래서 실시간 검색과 무한 스크롤을 대응해서 백엔드에서 api새로 제작하기로

윤미가 공통 컴포넌트화를 시작하기로

-> 터미널에 뜨는, 에러는 아니지만 워닝 표시인 것들 확인
-> seo 효율 처리 작업
-> 재사용 컴포넌트 논의 후 리팩토링(계정/마이페이지 모달 및 편지함 관련)
-> 변수명 규칙 재정립

이거는 seo처리할때 같이 처리하기로

가. Header(현재 방식)
헤더의 경우 XSS 공격에 취약하며, 지금 AccessToken, RefreshToken 둘 다 웹 사이트에서 볼 수 있어서 토큰 탈취 가능

나. Cookie
쿠키의 경우 CSRF 공격에 취약함. 단 HTTPOnly 및 Secure 속성 설정, CSRF 토큰 등으로 쿠키의 안전한 사용 보장이 가능함.
단, 백엔드가 쿠키를 관리하다보니 서버에 부담이 된다고 함.

프론트, 백엔드 공통 과제 알아보고 의견 가져오기

12월에 next.js로 코드 전환 작업 하고 공용 컴포넌트로 만들기

가. 공유기능(카카오톡을 첨가한)
나. 무한 스크롤 구현(백엔드 수정 완료시)
다. 공통 과제(프론트, JWT토큰 방식)

가. 편지 삭제, 실시간 검색, 무한 스크롤(페이징) api 수정 및 생성
나. 카카오톡 공유기능 구현
다. 공통과제(JWT토큰 보안 처리 관련)

가. 편지지 팝업 UI 공통 컴포넌트화
나. 편지 삭제 보낸, 받은 구분
다. 편지 삭제 api 수정(백엔드 완료되는대로)
라. 공통 과제(프론트, JWT토큰 방식)

1. 휴지통 모델 추가
-> 편지를 삭제할 수 있도록 창이 뜨고 거기서 체크하여 삭제
-> 무슨 기능을 넣을 것인가?
-> 다소 UX가 떨어지더라도 사이트 컨셉을 살려서 편지는 읽어보고 삭제하는 구조로
a. 체크 표시(검색하면서 전체 체크 버튼 클릭 시 검색된 애들만..!)
b. 편지지마다 휴지통 아이콘

2. 편지함에서 삭제(탈락)

1번에서 회의

피드백 완료

• 실제 운영을 해본다는 전제 하에
  • 1. ver2 개발 작업을 이어가면서 동시에 ver1을 운영한다(main 브랜치 기준으로 배포)
  • 2. ver2 개발 시 ver1 운영 종료(이 경우 사용자들에게 백업을 위한 공지사항 안내창 개발 및 편지 pdf화 다운로드 기능 개발 추가)

ver1 운영하면서 QA기간을 먼저 가지고 차후 1안으로 택(돈.........)

• 실제 운영을 하기 위한 seo 개선
  • 방법을 찾아서 검색창에 노출될 수 있는 방법을 찾고 싶어여

시맨틱 태그 처리를 합시다~

• 퍼블릭 폴더에 있는 html이랑 파비콘 관련 논의

4번의 경우 기능 및 UI 다 만들고 SEO 향상 작업이랑 nextJS 변경 작업 염두

• 400에러(2차 회원가입(닉네임, 주소)이 제대로 진행이 되지 않음.) 시 소셜 회원가입 창으로 넘어 갔음에도 responseData가 넘어오지 않아 email값이 없는 현상이 일어났습니다..!! 확인 부탁드립니다!

처리 해주시기로 했습니다~!

일단 1안으로 선택 후, 2안 더 시도 혹은 단일 파일 용량을 더 줄여보는 것으로 함.

가. 작업 분량 전체적 UI 수정 요청
나. 편지함 api 기능 올리기
다. 카카오톡 공유 기능

가. 보안 처리
나. 카카오 400 에러 처리
다. aws 요금 알아보기....

가. 비밀번호 변경 에러 코드 관련 백엔드 변경 사항 반영
나. 랜더링 최적화
다. 편지 삭제 UI 휴지통부터 기능까지

ver.2 에서는 친구 부분이 있지만 지금은 그냥 입력하기 단, 편지 쓰기 전에 받는 사람(닉네임)이 존재하는지 확인하는 창 추가하여 확인 후 편지를 쓰도록 수정하기
그 후 편지를 쓰고 보낼 때 창을 한번 더 띄워서 편지를 저장할 지와 보내는 사람 닉네임을 한번 더 보여줘 정말로 보낼지 한번 더 확인하는 창이 뜨도록 함.

에러 페이지에 메인페이지로 가기 버튼 넣기

사진처럼하되 현재 모달창 색깔배치대로 하기

체크 박스로 t/f 보내기

모달창을 커스텀하여 띄우기

오른쪽 위 x 표시 추가하기(통일)

지금 해당 에러 처리해서 머지해둠.

이메일 인증을 안하고 비밀번호 변경이 가능한 부분/ 프론트에서 막아두긴 했으나, 이메일만 알면 비밀번호를 변경할 수 있는데 보안적으로 괜찮은지
방안 : 2차 인증 후 user DB에 비밀번호 관련하여 보안 작업 처리하기

발견하면 알려주세여

비밀번호 변경 이후 어디로? 인덱스 페이지, 마이페이지? -> 메인페이지에 로그인 창 띄우기
계정 탈퇴 이후 어디로? -> 메인페이지
내 정보 변경 이후 어디로? -> 마이페이지 유지

백엔드에서 responseData로 이메일을 보내기때문에 이메일을 빼고 닉네임과 주소만 받기로 함.

각자 상황에 따라 대응하기

가. 보내는 편지 UI 및 모달창 및 팝업창 처리
나. 편지함 UI 구현

가. swagger 수정
나. 비밀번호 변경 보안 처리
다. 보안처리

가. 마이페이지 모달 라우터 처리
나. 모달창 끄기 버튼 추가
다. 랜더링 최적화
라. 에러 페이지 수정
마. 카카오 회원가입 이메일 없애기
바. 프론트 과제

pages폴더에 에러 핸들링 페이지 만들기

윤미가 시도 해보기

추가 없음

• 4-1) 코드 방식 말고 모델을 때려잡아서 진짜 용량을 줄여보는게 어떨지(논의점 추가해서 합쳤어요~~)

나무의 Geometry를 그룹화시켜서 블렌더로 모델 만들기 이것도 안되면 나무 모델을 줄이기

CSS깨짐이 아니라 의도한 애니메이션이었음. 가운데서 떠서 사라지기로 수정

setModalState와 navigate를 쓰는 요소는 alert, 나머지는 toastMessage

유저 정보를 불러올 때 항상 커스텀 훅으로 불러오는데 토큰 만료 시에 대한 커스텀 훅 사용 불가로 인터셉터안에서 recoil이 사용 가능한지 알아보고 대책 강구

추가하기로 결정

response data안에 user roll을 추가하기로 결정

검색어 노출을 위한 기본 지식을 쌓고 그냥 공부도 하자!
검색어 노출을 위한 공부 키워드: 시맨틱마크업, ssr, csr
그 외 공부 키워드: 웹 표준, 웹 접근성, 크로스 브라우징

삭제하지 않는 방향으로(사용할 일이 생기면 사용하기) 가고 로딩 스피너를 적용해보기로 결정

받은 편지는 받은 편지함에 보관, 보낸 편지는 보낸 편지함에 선택적으로 저장(유저가 편지를 보낼 때 저장할지 말지 선택) -> 모달창 띄어서 만들기

닉네임이 변경이 되더라도 이메일(key)로 저장 + 닉네임도 보낸이와 받는이거도 저장(그 당시의 닉네임)

가. 에러 핸들링 페이지 제작
나. Toast Message수정
다. 프론트 이론과제
라. 윤미가 (가)의 할일을 끝내는대로 편지지 api작업 시작
마. 편지지 스크롤 커스터마이징

가. 비밀번호 변경 기능 추가
나. 내정보 확인에 response data user roll추가
다. 메일 db저장방식 수정 - 논의점 13번 수정 방안 선택
라. 보낸 메일함 삭제 기능X, 보낸 편지 선택적 저장 기능 추가

가. 편지지 letter ui 미디어 쿼리
나. 나무 glb모델 최적화
다. 마이페이지 토큰 만료시 내정보 처리 개선 방안
라. 마이페이지 유저 탈퇴 기능
마. 비밀번호 변경
바. 프론트 이론 과제
사. 메일 인증 alert변경하면서 카카오 로그인에 로딩 스피너 추가

저작권 표기 및 디자인 둘 다 컨펌 완료 문서 올리기

기획 및 소통 문제 => 백엔드에서 처리를 해주기로 하였습니다!

1-1. 타이머를 따로 빼서 토스트 메시지 사용이 가능한지 확인
1-2. 안될 경우 alert창 사용
2. 이메일 인증 시 로딩 스피너 사용

존중을 담아 각자 알아서

지우져~!

미디어쿼리 아래로만 나눠봅시다~!

min-width: 1280px) 
@media screen and (max-width: 1279px) and (min-width: 1024px) 
@media screen and (max-width: 1023px) 

프론트 과제 땅땅

확인 끝

> 지금의 편지는 닉네임을 통해 찾는다!
> 닉네임이! 흑역사 일 수 있다!
> 그렇다면 변경하는걸로
> 위 기능은 침대 클릭시 로그인 모달 창과 비슷한 모달 창으로 기획

가. kakao 로그인 회원가입 테스트 후 작업 분량 합치기
나. 편지지 미디어 쿼리
다. (나)가 빨리 끝나면 편지지 api 작업 초반 닦기
다. 프론트 공통과제

가. 이메일 인증 시간 초과 에러 => 이메일 보내기에도 추가 예정
나. 코드 리팩토링! 및 에러 잡기
다. 닉네임 변경 관련 파생 사항 수정
+@ 서버 열어주세요!

가. 재윤->가 끝나면 이메일 인증 페이지 (로딩스피너 올리고, 이메일 인증 토스트메시지 논의점 3,4)바꾸기
나. 랜더링 최적화
다. 마이페이지(로그아웃, 회원탈퇴, 마이페이지(유저 정보 수정))
라. 프론트 공통과제
마. 로딩 스피너 문서 올리기

브랜치 feat으로 따로 파서 정리하기
따로 이슈는 파지 않고 기존 이슈번호로 처리하기로 함

서버에서 401로 보내기 때문에 try-catch로 잡아서 에러를 처리하도록 수정함.

최적화하는 것은 공통과제로 넘겨 프론트 쪽에서 회의 후 해결하기로 함.

따로 안하고 code formatter로 맞춰서 하기로 함.

위키에 정리하기로 함.
사용하는 방식, 예시, 코드 등을 정리하기

현재 : 파란색 바
변경 안 : 로딩 스피너로 변경

가. 프론트 공통 과제 - 2024년 10월 16일 논의점 참고
나. 피드백 받은 대로 변경
다. 중복 api 처리, 카카오 회원가입(로그인) 다시 구현, 편지지 UI 적용

가. 카카오 에러 처리 추가하기
나. code refactoring 진행
다. 서버 처리

가. 프론트 공통 과제 - 2024년 10월 16일 논의점 참고
나. 백엔드 토큰 재발급 코드 리팩토링으로 인한 인터셉터 구조 변경
다. 토큰 만료시에 대한 로그아웃 대응
라. 로딩 페이지 로딩 스피너로 변경

가. 편지지체 : 이서윤체
나. 고딕체 : 본고딕

현재: user pk인 email이 kakao 로그인, local 로그인으로 이메일 중복이 됨

문제점
kakao 로그인으로 로그인 했다가 local회원가입을 시도 할 경우 DB에 primary key인 email이 중복되는 결함을 발견

논의
> 구분 되는 다른 pk를 만들어 볼까
> email 중복이면 회원가입 api처리 로직에서 막을까

해결방안
> 어떤 회원가입이든 email이 이미 가입된 중복된 email이면 이미 가입된 회원으로 처리해서 email중복 회원가입 방지

받은 편지함과 함께 탭으로 구현 예정

혹시라도 해킹이나 보안으로부터의 위협을 대비해서 보안 정책 수립후 적용 시킬 예정

모든 팀원들 컨펌 결과 마무리하기로 결정

현재: 지금까지 useState를 이용한 setMenu로 팝업 이동 관리

문제점
> 이메일 인증을 안 하고 나갔다가 로그인을 시도하는 유저에 대한 대책X
> 점점 이러한 문제가 발생하면서 프론트측 페이지, 팝업 이동 상태관리에 대한 code refactoring의 필요성을 느낌 

논의
> react-router-dom을 이용한 페이지 관리
> recoil을 이용한 전역 상태 관리

해결방안
> react-router-dom을 이용해서 이메일 인증을 안 한 유저들에게는 이메일 인증 페이지로 이동해서 이메일 인증을 거쳐야만 로그인이 가능하게 할 예정

공용 컴포넌트 toast message를 구현해서 적용 할 예정

공용 컴포넌트 progress bar를 구현해서 적용 할 예정

문제점: 배경에 편지지 이미지를 적용하고 그 위에 textarea를 씌우는 방식인데 줄을 맞추더라도 스크롤이 생기면 줄이 안 맞는 문제

해결방안
> 1안. 스크롤 간격 조정해보기
> 2안. 편지지 팝업 페이지를 3페이지로 나눠서 진행

가. 이메일 인증, 회원가입 팝업창에 적용 할 공용 toast message, progress bar 구현
나. 카카오 회원가입 구현(백엔드 완료시)
다. 편지지 UI 해결방안 적용해보기

가. 보낸 메일함 api구현
나. code refactoring 진행

가. 로그인 구현
나. 백엔드 토큰 재발급 코드 리팩토링으로 인한 인터셉터 구조 변경
다. 토큰 만료시에 대한 로그아웃 대응
라. account 구조 변경(setMenu삭제 후 convert react-router-dom)

폰트는 다음주에 회의때 결정하기로, 편지지는 UI작업 적용시켜보고 후보군에서 고르기

현재: 메일 읽기 api 사용 시 편지 데이터를 보냄과 동시에 "viewCheck"가 자동으로 false에서 true 처리 됨(읽은 편지로 처리)

문제점
편지 도착시 편지 읽기 버튼 클릭과 동시에 받은 편지 데이터를 사용하지 않고 폐기될 경우 
이미 읽은 편지로 취급되어 사용자가 해당 편지를 확인하지 않았음에도 이미 읽은 편지로 넘어갈 가능성 존재

논의
> 네이버 메일의 경우에도 메일함의 새로운 메일 클릭시 바로 읽음 처리되기 때문에 현재의 방식도 괜찮다
> 네이버 메일의 경우 전체 받은 메일이 한 눈에 보이는 구조이기 때문에 바로 읽음 처리가 되어도 문제가 되지 않지만 
  투레터는 책장을 클릭해야 전체 받은 메일을 확인할 수 있는 구조이기 때문에 자칫 유저가 인지하지 못한 편지가 생길 수 있다

해결방안
> 가. 받은 편지의 수를 명시하여 유저가 인지하지 못한 편지가 없도록 한다.
> 나. 읽은 편지임을 구분하는 "viewCheck"가 변경 api를 따로 분리한다.
--------> (나)를 채택
> 백엔드에서는 api 분리
> 프론트에서는 메일 도착 후 읽기 선택 시 어떤 식으로 대응할지 차후 논의(읽고 있는 도착 편지를 버린다/보관한다 등의 선택지 제시)

담당자: 불필요한 오브젝트를 삭제하여 성능업을 노려보겠습니다.

(구름) 논의 결과 3명이 공통적으로 바라는 느낌과는 좀 다른 것 같다는 결론
가. 오브젝트 변경
나. 배경 이미지를 변경해보기로
순차적 시도 예정

가. 이메일 인증 관련 정리
나. aws 로그 보는 법을 듣고 계정을 공유받았다!(level up)
다. 백엔드는 1. 논의점 관련 처리 - 1) 읽은 편지 처리 구조를 통해 일감을 얻었다!

가. 회원가입 api - 이메일 인증 포함 수정 및 구현
나. 편지지 UI 피드백 반영하여 수정

가. 메일 읽기 관련 api 수정 및 새로 구현
나. 프론트랑 실시간 논의

가. 날씨 별 풍경 논의 내용 반영하여 수정 및 느려지는 부분 수정
나. 로그인 api 올리기

가. 필기체 폰트
나. 필기체 아닌 폰트

폴더 정리 및 설계 논의

회원가입 api 올리기 -> 재윤
백엔드 통신 구조 및 로그인 api 올리기 -> 윤미

1안 : 책을 누르면 자신이 썼던 편지함, 책들 옆 책꽂이 빈공간에 편지봉투 배치 후 누르면 읽었던 편지함
2안 : 책을 다시 두꺼운 책으로 골라서 3권의 책마다 기능을 나눠서 배치
UI가 분리되어 기능이 분리되는게 유저에게 좋을 것 같아 1안 채택

별 문제 없이 이대로 픽스

room 브랜치 merge 후 letter 브랜치 새로 파기 폴더 정리는 프론트끼리 협의 후 정리

1. 프론트에서 token 관리 기능을 공통으로 쓰는 public 기능으로 만들어서 코드 정리하기로 함
2. token 관련 논의
   가. accessToken 정상 -> 로그인 유지
   나. acccessToken 만료 -> accessToken 없이 refreshToken만 header에 넣어 /reissue로 보내면 refreshToken 검증
   
   1. refreshToken 정상 -> token 재발급 -> 로그인 유지
      
   2. refreshToken 만료 -> 재로그인 창 띄워 로그인 다시 받기
      

1. 이메일 인증 시 코드 만료 시간 정함. (5분)
2. 이메일 인증 시 코드 길이 정함. (6자리)

1안 : 겨울 나무 모델을 변경 2안 : 지금 이대로 겨울 나무 모델 사용 1안으로 일단 해보고 안되면 2안 채택

나무를 더 심으면 좋을 것 같다는 의견 나옴.
위 의견은 2차 개발로 넘김.

가. 받은 편지함 편지 UI 구현
나. 편지 팝업 UI 작업

가. swagger 정리(헤더(파라미터) 추가)
나. 실시간 메일 도착 기능 구현

가. 날씨별 풍경 구현
나. 통신 기본 구조 구현
다. 로그인, 회원가입 api 통신 기능 구현

다음 주 추석 이슈로 24.09.25(수) 20시 회의 날짜 변경

서랍장 위에 램프를 두고 밑에 공간에 책 모델을 추가로 배치

크게 한 크기로 픽스

색상은 그대로 빨간색으로, 토요일만 파란색으로 수정

가. 시도해봤으나 모델 안에 메쉬가 하나 이므로 분리해서 커스텀이 불가
나. 해결방법으로는 메쉬가 나뉘어져 있는 나무 모델을 찾아보고 안되면 고층뷰(나뭇잎만 보이는 뷰)로 만들기

나무 모델을 구해서 해결된다면 바닥에 추가적인 모델 배치 예정

바로 탈퇴(유저 정보 삭제)로 구현

2차 개발로 넘기기로

가. 서랍장 밑에 공간에 책 추가
나. 캘린더 토요일 파란색으로 수정
다. 책이 하나하나 분리가 가능하다면 책꽂이에 책 3개정도 배치
라. 연필통을 누르면 나오는 편지 쓰기 팝업창 제작
마. 받은 편지 책상 위에 편지봉투로 띄우기(된다면.. 시간이 안되서 못할 가능성 높음)

가. refresh token 구현
나. 조금 더 기능(back)을 다듬을 예정
다. Redis 구현

가. 날씨별 풍경 구현
나. 로그인 회원가입 남은 부분 UI
다. 계절별 풍경 - 나무 모델 찾아서 해결해보기(논의점에 자세히 설명)

가. room 책상 위치 이동(회의 시 해결)
나. 창문 모델 교체 요청
다. 팝업 css 수정 요청(회의 시 해결)
라. 벽지 텍스쳐 관련 해결 방안으로 조명 요청(회의 시 해결)
마. 커튼 모델 추가 요청

room branch 작업 내용 받아 확인 후 다음 주 개발 분량으로 처리

가. 카카오톡 로그인 시 받아오는 id 값이 기존에 등록된 유저 id와 겹치는 문제
나. 일반, 소셜 회원가입 둘 다 id를 삭제하고 이메일로 처리

• 관련 내용 계정(로그인, 회원가입, 아이디/패스워드 분실)

가. 창문 교체
나. 커튼 추가
다. 침대 달아주세요(2인용 1인용으로 잘라서..)
라. popup 겹침 현상 해결 및 popup component외 다른 부분 선택시 팝업 해제
마. 책상 위 촛대 삭제
바. 책상 위 캘린더 토요일, 일요일 날짜에 색상 변경 처리해주세요

가. 1-4) 로그인 및 회원가입 관련 필요 데이터 논의 부분에 따라 바뀐 부분 처리
나. 프론트에서 로그인 파트 api 올리기 시작하면 관련하여 함께 처리

가. 풍경 사이즈 변경 및 위치 이동
나. 나무 그림자 처리(해보고 안되면 아래로)
나-1. 텍스쳐 변경
나-2. obj 모델링 파일 확장자 변경 후 재 로드
다. 나무 더 심기
라. 날씨별 풍경 처리
마. 로그인, 회원가입 UI 구현
바. 로그인, 회원가입 API 올리기
다음주 수요일까지 안될 것 같아요..

지속적인 관심 부탁드립니다~~

• 팀 규칙