2024 10 23 논의점 - To-Letter/To-Letter-front GitHub Wiki

1. 재윤's 논의점

  1. try catch문에서 catch문에 처리할 에러 처리 방안?
    방법으로 에러 핸들링 페이지 개설 여부 어떤지?
    ex) 서버가 불안정합니다. 잠시후에 시도해주세요. 페이지

  2. media query 현재 편지지 ui는 브라우저의 높이에 따라서 1px마다 배경인 이미지가 줄어들고 늘어나는데 이것을 textarea가 1px마다 따라다니면서 맞추기는 현실적으로 불가능하다고 판단
    -> 어느정도 편지지 줄에 텍스트가 안 맞는거를 감수하고 모니터, 노트북 기준으로 2가지 상황으로 구현

가. 모니터, 노트북 화면에 full인 브라우저 크기
나. 모니터, 노트북의 화면을 브라우저 2개 창으로 반반 나눴을때의 크기

  1. 편지지 ui 추가적인 사항 여부(현재 편지지 ui의 요소들)

가. textarea(편지 내용)
나. To. 수신자
다. From. 발신자
라. 편지 전송 버튼
마. X버튼

  1. 최적화 부분 내 노트북에서만 이러는건지..?(단지 사양이 딸려서 내장그래픽으로 인해)

최적화는 많은 방안들을(gltf-pipeline, LOD (Level of Detail), Frustum Culling) 시도해봤지만 모두 로딩 시간이나 다른 부분에서 최적화가 되고 브라우저의 렉은 똑같음


2. 윤미's 논의점

작업 요청 논의

  1. Toast Message 위치 css 깨짐
  2. 없어요... 비밀번호 변경............... 기능이..!
  3. 현재 유저 탈퇴 부분에서 유저가 로컬 유저인지 소셜 유저인지 확인할 방법이 없습니다..! 따로 클릭하는 버튼 따라 나눠줄 수도 있긴 하지만 불필요한 코드가 너무 많이 추가되는 느낌이라, 괜찮으시다면 유저 정보 조회 시 소셜 로그인 유저인지, 로컬 유저인지 함께 보내주실 수 있을까요??

확인 요청 논의

  1. 인증 페이지 전체 alert를 toastMessage로 변경했는데, 괜찮을지
  2. 마이페이지 모달에서 자신의 정보를 불러오는 api를 사용하는데, 유저 정보가 자주 변경될 것 같지도 않고(외부에서 변경될 가능성도 없다고 판단하였습니다!) 자신의 닉네임이 필요한 경우가 잦을 것 같아(ex> 편지 from 부분) 커스텀 훅과 recoil을 사용하는 방식으로 채택했습니다! 이 경우 유저 정보를 불러올 때 항상 커스텀 훅을 먼저 생각해주셔야 하여, 확인 부탁드립니다! 문제 없을시 문서 처리하겠습니다!

1-1. recoil에 기본 값을 기반으로 커스텀 훅을 불러왔을 때 isLogin의 값이 false일 경우 백엔드 /users/mypage 를 통해 자신의 정보 값 저장

{
    isLogin: false,
    address: "",
    email: "",
    nickname: ""
}

1-2. recoil에 기본 값을 기반으로 커스텀 훅을 불러왔을 때 isLogin의 값이 true일 경우 기존 값 사용

{
    isLogin: ture,
    address: "서울시 양천구 오목로 ---",
    email: "[email protected]",
    nickname: "윤미1"
}

제안

  1. 랜더링 최적화 관련(요약: 모델 용량을 줄여보고자합니다..)
  2. 프로그레스 바를 삭제하지 않는다에 대한 의견을 여쭙고 싶습니다!
  3. 프론트 과제 제안: 우리 프로젝트도 검색어 노출을!
주제: 검색어 노출을 위한 기본 지식을 쌓고 그냥 공부도 하자!
검색어 노출을 위한~~~ 공부 키워드: 시맨틱마크업, ssr, csr
그냥 공부 키워드: 웹 표준, 웹 접근성, 크로스 브라우징

3. 유정's 논의점

  1. 메일 삭제 시, 받은 메일만 삭제인데 그대로 둠..?
  2. 메일 db에 저장 방식 논의
⚠️ **GitHub.com Fallback** ⚠️