- 글쓰기 페이지 API 관련 ⇒ 유저스토리, API, 서비스 정책 문서 확인 필요
- 프론트 논의 결과
- 글 쓰기 페이지에 접근할 때 내가 속한 팀을 조회할 내 팀 조회 API가 있으면 좋을 것 같다. 페이지 진입 시 내 팀을 조회하고 내가 팀장으로 있는 팀을 필터링해서 보여주면 될 것 같다.
- 공고 신청 페이지에서도 팀 선택하는 기능이 있는데 이때도 API 재사용 할 수 있을 듯?
- 전체 논의 결과
- 기획 때 팀장만 글을 작성하고 대결을 신청할 수 있다고 얘기했다고 한다. 그래서 API는 내가 리더로 있는 팀 목록을 불러오는 걸로 정함.
백엔드 의견: 글쓰기 페이지에서 글 작성 API 하나만으로 해결이 가능한지?
글쓰기에서 전체적인 흐름이 헷갈린다
- 공통 (스타일)컴포넌트 컨벤션
- 왠만하면 모든 상황에 대응되게 하고 추후에 범위를 좁히거나 쓰지 않는 코드는 버리자
- 이게 맞는 방법인가?
- 린트 룰 추가는 개인 작업에 포함하고 PR에 설명하기
- 스타일드 컴포넌트 오브젝트 스타일 고려
- 스타일드 컴포넌트를 함수 컴포넌트로 감싸지 않고 바로 사용하는 방법
- 파일의 위치는 어디가 적절할까
- 타입 문제 해결 방법
- document.addEventListener 에 핸들러를 설정하는 상황
const handleClick = (e: MouseEvent) => { } document.addEventListener('click', handleClick)
React.MouseEvent
를 import 했었는데 그 값을 가져오다보니 계속 타입에러가 발생했음. ⇒ 네이티브 이벤트와 리액트 합성 이벤트를 잘 구분하자- 테마를 사용하는 이유
- 여러가지 테마를 정해두고 테마에 맞는 디자인을 쉽게 입히기 위해 사용한다
- 현재는 테마가 하나이다
- ThemeProvider의 의미가 줄어든다
- 상수로 관리하는 것이 오히려 나을 수 있다
- 확장가능성을 고려해 테마를 사용하는 것도 좋다
- 테마가 여러 개더라도 공통된 부분이 있을 것이다
- 공통 부분 또한 테마로 주입할 수도 있다
- 상수로 관리할 수도 있다
- 쿠키 저장 방식
- 따로 백엔드 서버가 있다면 노 상관
- 없다 그러면 next에서 설정을 해주어야 한다
- next를 프록시 처럼 사용할 수도 있지만 백엔드 서버가 있는데 굳이?
- 인증이 있고 없고를 떠나서 쿠키를 받거나 전송할 때 프론트에서 credential 옵션이 필요하다
- 이유는?
- same site 옵션
- 정확한 설명은 안 된다 ㅠ
- cors 와 마찬가지로 쿠키 저장을 위해서 필요한 옵션이다

- 프로젝트 관련된 사항이라면 모든 것 공유(화이트 보드, 문서) 좀요.. 기억 문제를 완화할 수 있어요..
- 페이지 url 설정에도 원칙이 있나?
- 정책 관련의 경우 의견 통일이 필요해서 무조건 협의 후 결정
- 차트랑 아이콘 library 도입할 때 파파 없어서 임의로 결정 후에 올렸는데 이런거 급한 거 아니면 저도 얘기하고 협의 후에 하도록 하겠습니다~!
TROUBLE SHOOTING으로 이관 필요
- Review Group
- svg import 하면서 any eslint rule error로 인해 작업이 오래걸렸습니다. 추후 icon 컴포넌트 작업하게되면 비슷한 오류를 겪을 수도 있을 것 같습니다. 해당 내용 공유가 필요할 수도 있을 것 같아 참고한 링크 남겨둡니다. svgr/webpack, url-loader 설치했습니다.
- 타입스크립트 타입 관련 에러가 발생 했을 때
- 정말 필요한 린트 에러일 수도 있지만
- 일시적인 오류? 로 타입 추론을 못하는 상황일 수도 있다.
- 이 경우 vscode 재시작, 코드 최신화를 진행하면서 문제가 해결 될 수 있음. ⇒ 내 경우는 리베이스 하는 것만으로 문제가 해결됨.
- 팀 뱃지 이슈
- 색깔 초록색 그라데이션 ⇒ 각 팀별로 팀 컬러 정할 수 있게 해서 보여줄 수 있으면 좋을 듯
const Color: ColorProps = { 1: '#14A452', 2: '#62D2A2', 3: '#1FAB89', 4: '#14A452', 5: '#59B9A1', 6: '#16785F', };
각 아이콘 별로 이름을 prop으로 넘겨주는 방식의 라이브러리가 아닌가보네요?
이 부분도 지금 당장 고칠 필요가 있지는 않아 보이지만 개선 사항으로는 기록해두면 좋겠네요
soccer: <MdSportsSoccer size='21px' />, baseball: <MdSportsBaseball size='21px' />, basketball: <MdSportsBasketball size='21px' />, tableTennis: <FaTableTennis size='21px' />, bowling: <FaBowlingBall size='21px' />, badminton: <GiShuttlecock size='21px' />, tennis: <MdSportsTennis size='21px' />,
- 팀 차트 이슈
- 2018년 자료 1등꺼로 개발함 ⇒ 2022 최신화 자료상 chart.js가 맨 위이므로 @nivo Core, @nivo Pie라이브러리 걷어내고 다시 개발 필요성 있음
- 이런 거 도입할 때 자료 꼼꼼히 확인해야겠어요.
- storybook처럼 커스텀 할 수 있어서 썼는데 그래도 많은 사람들이 쓰는 걸 쓰면 더 좋으니까요~!
- Git 'fatal: Unable to write new index file 에러
- 변경 사항 add 하려는데 add가 안된다! 삭제도 안된다! 답답해 죽는 줄 알았는데 내 컴퓨터 디스크 용량이 부족한 거였다. 필요없는 파일 삭제하면 해결됨.
- Next.js Duplicate atom key 에러
- 결론부터 말하면 무시하면 된다
- 기능적으로 아무 이상이 없음
- 이를 보기 싫다면 interrupt-stdout모듈을 사용해서 에러메시지 무시를 하거나
- uuid 같은 난수생성기를 이용해 atom key를 생성하면 된다고 한다
- try catch 문에서의 axios error 타입
- 아직은 이해 안되지만 아래 문서를 참고하면 타입을 지정할 수 있다.
- 이해되면 다시 정리하자
- 글보고 똑같이 따라했는데(
error as unknown as AxiosError
) 아래 오류가 뜸 - 그래서
error as AxiosError
로 작성하니까 오류가 사라짐?! ⇒ 뭐지

위 오류가 뭔지도 찾아봐야겠다 ⇒ 찾으면 정리 예정
- 드롭다운 닫히는 클릭 영역에 대한 고민
- UX 측면에서 외부 영역 클릭에 대해서 닫히게 하는 것이 좋을까
- ⇒ 상황마다 다를 것 같다
- ⇒ 그렇다면 모든 상황에 대응되도록 외부 영역을 기능 범위에 넣는게 좋은가?
- ⇒ 대부분의 상황에서 좋다? ⇒ 알 수 없다 ⇒ UX 지식이 부족하고 경험도 부족
- ⇒ 직관적으로 보았을 때 상황 대응 범위가 넓어 좋다고 생각
- ⇒ 드롭다운에만 해당하는 이야기는 아닌 것 같다
- Heading 구현 중 이슈
- 해당 path를 가져와 각 키에 해당하는 값을 출력하는 형태로 구현 중인데 routing이 되어 있지 않아서 미리 했으면 좋겠습니다! 일단 임시로 API 문서에 있는 것 기반으로 해뒀는데 프론트 페이지 라우팅 관련해서도 얘기할 필요성이 있어보여요!
현재까지 구현사항


export const HeadingTitle: HeadingTitleProps = { '/signup': '회원가입', '/signin': '로그인', '/town': '내 동네 설정', '/team/create': '팀 생성', '/invitation': '팀원 초대', '/alarm': '알림', '/teams/:id': '팀 프로필', '/users/:id': '프로필', '/users/:id/본인': '내 정보', '/': `송파동`, '/post': '글쓰기', '/posts/:id': '상세 페이지', '/matches/:id/result': '경기 결과', '/matches/:id/review': '후기 작성', '/proposals': '신청하기', '/chats': `유저 닉네임`, '/chatList': '채팅', }; //페이지 구현 다 하고 수정하는 걸로
- 화이트보드를 날짜로 구분해서 작성하면 좋을 것 같다. 그럼 언제 작성했는지 파악하기 쉬울 것 같다는 생각!
2022.0x.0x 이런 느낌쓰?
- 유효성 검사를 어떻게 진행해야 할 지
- 중복 검사의 경우 아이디/닉네임 중복 검사 api를 따로 만들어준다고 하셨다 백엔드에서
- ⇒ 중복 검사를 하려면 일단 형식에 맞는 아이디/닉네임이어야 한다.
- ⇒ 그럼 프론트에서 검증을 해서 보내야하나? 아니면 백엔드에서 유효성 검사 통과 못 할 경우 응답값을 주나? 이건 내일 물어봐야겟다 ⇒ 그냥 지금 물어봣음 답변은 내일 올 듯? ⇒ 내 생각은 프론트에서 검증하는 게 맞는듯 ⇒ 프론트에서 검증 하는걸로
- 만약 프론트에서 유효성 검사를 한다면 어디까지 해야하나?
- 아이디
- 닉네임
- 비밀번호
- 그냥 다하면 되겠구먼 ⇒ useForm 훅이 있으면 좋을 것 같다.
- 이벤트 핸들러는 React.EventHandler 쪽이 더 나은 듯 하다
꿀기술 마지막 링크 참고
- 무한 스크롤 구현 실패 ⇒ 구현은 성공인데 버그 생김
- 맨 마지막 공고 다음에 옵저버 컴포넌트를 두고 intersection observer를 사용해서 구현하려 했음.
- API 호출이 너무 많이 일어남
- 로딩 상태인지 확인하고 호출하는게 필요할 것 같다
- 예전에는 쉽게 구현 했던 것 같은데 이번엔 왜 안되지…
- 더보기 버튼으로 구현하게 되면 UI 변경이 필요하다
- 더보기 버튼과 글쓰기 버튼이 겹침 ⇒ 일단은 글쓰기 버튼을 오른쪽으로 옮기자

- 회원제 vs 일부 회원제
- 흐름을 정리할 필요가 있다
- 시작 페이지 있어야 하나?
- 로그인 상태일 때는 로그인 페이지 이동이 불가능해야하지 않을까


메인 디자인 관련: 중간 divider 짤리는게 너무 거슬려서 요렇게 바꾸는건 어떠신지 궁금합니다.
gap 적용, Button style 변경 등 UI 수정사항은 DK-338에서 처리했습니다.
- 스크롤바 관련
- 지금은 스크롤바가 페이지 전체임.
- 이걸 스크롤이 필요한 영역만 스크롤이 생기게 하는 게 좋을 것 같음

- 공고 상세 페이지 관련해서 UX 적으로 화살표 이슈가 있음
- 공고 상세 페이지에서 매칭 신청에 대한 정보가 필요
- 회원가입 시에 무조건 동네 설정할 수 있게 해야 함
- 로그인 흐름 처리
- 로그인 되지 않은 사용자는
/
,/signin
,/signup
페이지 제외 접근할 수 없음 - 접근 시 useEffect에서 시작 페이지(
/
) 로 리다이렉트 - 로그인 된 사용자는
/
,/signin
,/signup
페이지에 접근할 수 없음 - 접근 시 useEffect에서 이전 페이지로 리다이렉트 (router.back())
- 로그인이 자동으로 풀리는 경우는?
- 액세스 토큰 만료 && 리프레시 토큰 만료인 경우
- 이 때는 애초에 브라우저에 저장된 토큰이 없기 때문에 403 반환
- 그럼 API 요청 했을 때 응답이 403으로 오면 전역에 저장된 유저 정보 삭제하고 로그인 페이지로 리다이렉트 하면 될 것 같음.
- 로그아웃 처리 관련해서 나중에 확인하면 좋을 것 같은 글
- 이 외에 처리해야 할 흐름은?
API try catch 할 때 error 지금 log만 찍어놨잖아요. 아래 처럼
try {} catch (e) { console.log(e); }
그러면 로그 에러 뜨는게 싫어서 현재는 이런식으로 처리하고 있는데 이렇게 하면 문제가 있다고 생각이 돼서 여쭤봅니다. 왜냐하면 error 로그는 프론트 개발자인 저희랑 백 개발자만 알아야 하는데 이렇게 Error를 던지게 되면 만약 네트워크 에러가 있어서 문제가 생길때 어떤 문제인지 다 파악이 가능할 것 같아요.
단순히 thorw Error(error)로 처리를 하고 log를 찍는다? 이것도 말이 안되고, 에러 메시지를 상태관리한다?
그렇다면 이걸 어떤 방식으로 처리를 해야할지가 궁금합니다.
그리고 해당하는 API가 제대로 호출 되면 들어가는 값을 상태 관리할 필요성이 없을 것 같은데 요것에 대해서도 의견을 주시면 감사하겠습니다.
try () {} catch (e) { if (axios.isAxiosError(e)) { const error = e as AxiosError<ServerError>; if (error && error.response) { setState({ ...state, values: [] }); throw Error(error.response.data.message); } } }
⇒ 결론
개발자를 위한 것은 console.error(e) 만 찍어주면 된다.
//분기 처리가 필요 없으면 뭔가 잘못되었습니다!띄울 것 catch (e) { console.error(e); alert('뭔가 잘못되었습니다!'); }
export interface ServerError { code: string; message: string; }
// 분기 처리가 필요하면 분기를 한다 // 401 => 토큰이 만료되었습니다. // 403 => 권한이 없는거, 접근이 불가능합니다! // 404 => 보여줄 것이 없습니다. if (axios.isAxiosError(e)) { const error = e as AxiosError<ServerError>; if (error.status === '401') { // recoil 상태 삭제 setUser({}); router.push('/'); } }