이슈

• 글쓰기 페이지 API 관련 ⇒ 유저스토리, API, 서비스 정책 문서 확인 필요
🚨
백엔드 의견: 글쓰기 페이지에서 글 작성 API 하나만으로 해결이 가능한지? 글쓰기에서 전체적인 흐름이 헷갈린다
• 프론트 논의 결과
• 글 쓰기 페이지에 접근할 때 내가 속한 팀을 조회할 내 팀 조회 API가 있으면 좋을 것 같다. 페이지 진입 시 내 팀을 조회하고 내가 팀장으로 있는 팀을 필터링해서 보여주면 될 것 같다.
• 공고 신청 페이지에서도 팀 선택하는 기능이 있는데 이때도 API 재사용 할 수 있을 듯?
• 전체 논의 결과
• 기획 때 팀장만 글을 작성하고 대결을 신청할 수 있다고 얘기했다고 한다. 그래서 API는 내가 리더로 있는 팀 목록을 불러오는 걸로 정함.

• 공통 (스타일)컴포넌트 컨벤션
• 왠만하면 모든 상황에 대응되게 하고 추후에 범위를 좁히거나 쓰지 않는 코드는 버리자
• 이게 맞는 방법인가?

• 린트 룰 추가는 개인 작업에 포함하고 PR에 설명하기

• 스타일드 컴포넌트 오브젝트 스타일 고려

• 스타일드 컴포넌트를 함수 컴포넌트로 감싸지 않고 바로 사용하는 방법
• 파일의 위치는 어디가 적절할까

• 타입 문제 해결 방법
• document.addEventListener 에 핸들러를 설정하는 상황

const handleClick = (e: MouseEvent) => {
		
}

document.addEventListener('click', handleClick)

• handleClick 핸들러 함수의 이벤트 객체는 리액트의 합성 이벤트가 아니고, 네이티브 이벤트임. 이전에 합성 이벤트의 타입을 정의하려고 React.MouseEvent 를 import 했었는데 그 값을 가져오다보니 계속 타입에러가 발생했음. ⇒ 네이티브 이벤트와 리액트 합성 이벤트를 잘 구분하자
• 근데 그럼 네이티브 MouseEvent랑 리액트 MouseEvent랑 한 파일에서 같이 쓰는 경우는 리액트 이벤트의 경우 React.MouseEvent 로만 사용해야 하는 건가? 궁금쓰..

• 테마를 사용하는 이유
• 여러가지 테마를 정해두고 테마에 맞는 디자인을 쉽게 입히기 위해 사용한다
• 현재는 테마가 하나이다
• ThemeProvider의 의미가 줄어든다
• 상수로 관리하는 것이 오히려 나을 수 있다
• 확장가능성을 고려해 테마를 사용하는 것도 좋다
• 테마가 여러 개더라도 공통된 부분이 있을 것이다
• 공통 부분 또한 테마로 주입할 수도 있다
• 상수로 관리할 수도 있다

Best Practices

Emotion is an extremely flexible library, but this can make it intimidating, especially for new users. This guide contains several recommendations for how to use Emotion in your application. Keep in mind, these are only recommendations, not requirements! You don't get Intellisense or type checking when using CSS strings, e.g.

https://emotion.sh/docs/best-practices

• 쿠키 저장 방식
• 따로 백엔드 서버가 있다면 노 상관
• 없다 그러면 next에서 설정을 해주어야 한다
• next를 프록시 처럼 사용할 수도 있지만 백엔드 서버가 있는데 굳이?

• 인증이 있고 없고를 떠나서 쿠키를 받거나 전송할 때 프론트에서 credential 옵션이 필요하다
• 이유는?

[AXIOS] 📚 CORS 쿠키 전송하기 (withCredentials 옵션)

다음 상황을 가정해보자 프론트(react) : 3000 / 서버(express) : 3060 포트 사용한다고 가정 프론트에서 axios.post("/post", data)로 요청을 보냄 > CORS 서버 "/post"에서 req.user값이 undefined가 나옴. 서버의 인증 부분은 passport를 사용하였고 정상적인 경우라면 req.user 객체에 사용자 정보가 들어가 있어야함 문제는 클라이언트에서 요청을 보낼 때, 쿠키 값을 같이 보내주지 않았음 -> 서버에서는 세션 정보(세션 쿠기)를 찾을 수 없어서 undefined가 나왔던 것!

https://inpa.tistory.com/entry/AXIOS-%F0%9F%93%9A-CORS-%EC%BF%A0%ED%82%A4-%EC%A0%84%EC%86%A1withCredentials-%EC%98%B5%EC%85%98

• same site 옵션



• 정확한 설명은 안 된다 ㅠ
• cors 와 마찬가지로 쿠키 저장을 위해서 필요한 옵션이다

• 프로젝트 관련된 사항이라면 모든 것 공유(화이트 보드, 문서) 좀요.. 기억 문제를 완화할 수 있어요..

• 페이지 url 설정에도 원칙이 있나?

• 정책 관련의 경우 의견 통일이 필요해서 무조건 협의 후 결정
• 차트랑 아이콘 library 도입할 때 파파 없어서 임의로 결정 후에 올렸는데 이런거 급한 거 아니면 저도 얘기하고 협의 후에 하도록 하겠습니다~!

TROUBLE SHOOTING으로 이관 필요

• Review Group
• svg import 하면서 any eslint rule error로 인해 작업이 오래걸렸습니다. 추후 icon 컴포넌트 작업하게되면 비슷한 오류를 겪을 수도 있을 것 같습니다. 해당 내용 공유가 필요할 수도 있을 것 같아 참고한 링크 남겨둡니다. svgr/webpack, url-loader 설치했습니다.
Problem: SVG TypeScript ESLint errors on any value
nextjs svg import
[SOLVED]-GETTING NEXTJS IMAGE COMPONENT & @SVGR/WEBPACK TO PLAY NICELY TOGETHER-REACTJS

• 타입스크립트 타입 관련 에러가 발생 했을 때
• 정말 필요한 린트 에러일 수도 있지만
• 일시적인 오류? 로 타입 추론을 못하는 상황일 수도 있다.
• 이 경우 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 타입
• 아직은 이해 안되지만 아래 문서를 참고하면 타입을 지정할 수 있다.
• 이해되면 다시 정리하자
별 건 아니지만 typescript 에러 핸들링에 대해
별건 아니지만 typescript환경에서 에러처리를 할 때, 저는 try catch를 사용합니다. catch 내부에서 사용되는 에러는 typescript에서 unknown으로 취급하기 때문에 당연하지만 다음처럼 타입을 지정해서 사용할 수 없습니다. throw 문을 이용해 에러 발생을 시킬 때 에러에는 그 어떤 타입도 들어갈 수 있기 때문에 에러 처리 함수를 만들어서 사용하려고 할 때 타입 지정을 명시적으로 할 수가 없습니다.

https://velog.io/@jay/it-is-nothing-typescript-error-handling

• 글보고 똑같이 따라했는데(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': '채팅',
};
//페이지 구현 다 하고 수정하는 걸로

• 또 다른 이슈로는 next/router는 history를 자동으로 저장하지 않아서 직접 구현해야합니다. 내일 이거부터 진행 예정
• 뒤로가기 버튼을 피그마 처럼 일부 넣어주고 일부 빼는 방식으로 하게 되면 어떻게 해야할지 고민 중
⇒ 이거는 해결됐음, list 임의로 만들어서 비교 후 조건부 렌더링
• 동적 라우팅이 되어 있는 것들은 어떻게 뿌려줘야할지..고민이 됩니다..
 

• 화이트보드를 날짜로 구분해서 작성하면 좋을 것 같다. 그럼 언제 작성했는지 파악하기 쉬울 것 같다는 생각!

2022.0x.0x 이런 느낌쓰?

• 유효성 검사를 어떻게 진행해야 할 지
• 중복 검사의 경우 아이디/닉네임 중복 검사 api를 따로 만들어준다고 하셨다 백엔드에서
• ⇒ 중복 검사를 하려면 일단 형식에 맞는 아이디/닉네임이어야 한다.
• ⇒ 그럼 프론트에서 검증을 해서 보내야하나? 아니면 백엔드에서 유효성 검사 통과 못 할 경우 응답값을 주나? 이건 내일 물어봐야겟다 ⇒ 그냥 지금 물어봣음 답변은 내일 올 듯? ⇒ 내 생각은 프론트에서 검증하는 게 맞는듯 ⇒ 프론트에서 검증 하는걸로
• 만약 프론트에서 유효성 검사를 한다면 어디까지 해야하나?
• 아이디
• 닉네임
• 비밀번호
• 그냥 다하면 되겠구먼 ⇒ useForm 훅이 있으면 좋을 것 같다.

• 이벤트 핸들러는 React.EventHandler 쪽이 더 나은 듯 하다
🍯
꿀기술 마지막 링크 참고