-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feat/#48] 채팅 페이지 QA #49
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
고생많으셨습니다!
type AcceptRejectButtonDisplayContextType = { | ||
isVisible: boolean; | ||
show: () => void; | ||
hide: () => void; | ||
}; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
p2) provider가 많아지면서 hide를 의미하는 다양한 provider가 생긴것 같아요 이렇게 되면 컴포넌트 내에서 불러올 때 hide의 이름을 재정의 해주어야하고, 그러면 여러 컴포넌트에서 각각이 다른 이름을 사용하게 되어서 혼란을 일으킬 수 있을 것 같아요!
이부분을 Context 의미에 맞는 이름으로 변경하면 좋을 것 같아요!
hide를 각각 다르게 정의하고 사용하는 부분 코드 예시
hide: hideTextField,
focus: focusTextField,
} = useTextFieldInChatDisplayContext();
const { hide: hideAcceptRejectButtons }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
프로바이더들을 동일한 인터페이스로 맞춰 사용하기 편하게 만드려고 했는데 그런 단점도 있겠네 재훈이는 useQuery 커스텀 훅을 만드는 경우에도 아래 처럼 이름을 변경해서 반환하나?
const { customData } = useCustomQuery
<AcceptRejectButtonDisplayProvider> | ||
<ChatRoom /> | ||
</AcceptRejectButtonDisplayProvider> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
p3) 준근님만의 Provider를 도입하는 기준이 궁금해요!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
기준이 있지는 않고 복잡한 상태를 좁은 화면에서 관리해야 하는 문제가 있어서 reducer와 context를 같이 사용했어
이슈 번호
closes #48
작업한 내용
디스코드 qa냥 채널에 보고된 채팅 페이지 관련 QA
작업 결과
.
비고
시간이 없어서 티켓을 못 나누고 한 번에 작업했어 ㅜ 커밋 메시지로 변경 사항 구분해 놨으니 참고