2024 10 23 논의점 - To-Letter/To-Letter-front GitHub Wiki
-
try catch문에서 catch문에 처리할 에러 처리 방안?
방법으로 에러 핸들링 페이지 개설 여부 어떤지?
ex) 서버가 불안정합니다. 잠시후에 시도해주세요. 페이지 -
media query 현재 편지지 ui는 브라우저의 높이에 따라서 1px마다 배경인 이미지가 줄어들고 늘어나는데 이것을 textarea가 1px마다 따라다니면서 맞추기는 현실적으로 불가능하다고 판단
-> 어느정도 편지지 줄에 텍스트가 안 맞는거를 감수하고 모니터, 노트북 기준으로 2가지 상황으로 구현
가. 모니터, 노트북 화면에 full인 브라우저 크기
나. 모니터, 노트북의 화면을 브라우저 2개 창으로 반반 나눴을때의 크기
- 편지지 ui 추가적인 사항 여부(현재 편지지 ui의 요소들)
가. textarea(편지 내용)
나. To. 수신자
다. From. 발신자
라. 편지 전송 버튼
마. X버튼
- 최적화 부분 내 노트북에서만 이러는건지..?(단지 사양이 딸려서 내장그래픽으로 인해)
최적화는 많은 방안들을(gltf-pipeline, LOD (Level of Detail), Frustum Culling) 시도해봤지만 모두 로딩 시간이나 다른 부분에서 최적화가 되고 브라우저의 렉은 똑같음
- Toast Message 위치 css 깨짐
- 없어요... 비밀번호 변경............... 기능이..!
- 현재 유저 탈퇴 부분에서 유저가 로컬 유저인지 소셜 유저인지 확인할 방법이 없습니다..! 따로 클릭하는 버튼 따라 나눠줄 수도 있긴 하지만 불필요한 코드가 너무 많이 추가되는 느낌이라, 괜찮으시다면 유저 정보 조회 시 소셜 로그인 유저인지, 로컬 유저인지 함께 보내주실 수 있을까요??
- 인증 페이지 전체 alert를 toastMessage로 변경했는데, 괜찮을지
- 마이페이지 모달에서 자신의 정보를 불러오는 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"
}
- 랜더링 최적화 관련(요약: 모델 용량을 줄여보고자합니다..)
- 프로그레스 바를 삭제하지 않는다에 대한 의견을 여쭙고 싶습니다!
- 프론트 과제 제안: 우리 프로젝트도 검색어 노출을!
주제: 검색어 노출을 위한 기본 지식을 쌓고 그냥 공부도 하자!
검색어 노출을 위한~~~ 공부 키워드: 시맨틱마크업, ssr, csr
그냥 공부 키워드: 웹 표준, 웹 접근성, 크로스 브라우징
- 메일 삭제 시, 받은 메일만 삭제인데 그대로 둠..?
- 메일 db에 저장 방식 논의