[FU-345] base schedule

[eujin-shin]

체크리스트

• 불필요한 주석 처리가 없는가?

작업 내역

• 기본 스케줄 및 예약 오픈 시간 단위 설정
  예약 오픈 시간 단위 변경, 요일별 운영 시간표 확인 및 수정, 휴무일로 변경

고민한 사항

• 시간값 관리

TypeScript에서 제공하는 Date 객체의 경우 날짜에 대한 정보 없이 시간을 정의하는 게 불가능해서, 특정 날짜에 종속적이지 않은 운영 스케줄을 어떻게 관리할지 고민이 있었습니다. 직접 타입을 정의하는 것도 고려해 봤으나, 운영 시간의 유효성 검증 / 날짜별 스케줄 및 예약 시간 설정시 비교 필요 등 시간에 관한 연산 혹은 비교 기능이 다수 필요해질 것으로 예상되었습니다. 관련 라이브러리 중 시간만 독립적으로 관리할 수 있는 luxon을 추가해 사용하게 되었습니다.

추가로, luxon을 통해 정의한 DateTime을 어느 범위까지 사용하고, 어느 범위에서 해당 값을 포맷팅한 string을 들고 있을지 고민이 있었습니다. 현재는 시간 값을 직접 수정하는 컴포넌트에서만 DateTime 객체를 변환해서 사용하고 있는데, 이후에 의존성과 복잡성을 좀 더 고려해 보고 네이티브 Date + 직접 정의한 유틸 함수를 이용하던 부분까지 일관적으로 DateTime을 사용하게 리팩토링해 보는 것도 괜찮을 것 같다는 생각이 들었습니다 ㅎ.ㅎ…

• 컴포넌트 설계 관련

개발을 잠깐 쉬었더니 컴포넌트를 적당히 쪼개고 책임을 분리하는 데도 고민이 좀 있었습니다. 예약 시간 단위를 선택하는 경우, 변경 전 보여 주는 모달에서 변경할 시간 단위 값을 가지고 있어야 했는데, 처음에는 다음과 같이 구현했습니다.

상위 컴포넌트에서 "사용자가 변경하려고 하는 시간 단위"를 상태로 관리하며 하위 컴포넌트(모달)에 전달
사용자가 시간 단위 클릭시 해당 단위로 상태를 변경하고, 변경을 취소했을 때는 (모달을 닫는 등) null 값을 갖고 있음

단 이 경우 모달에서 null 값에 대한 예외 처리가 필요하고, 시간 단위는 추후에 여러 개의 옵션으로 늘어날 가능성이 낮을 것으로 예상되어 불필요한 리렌더링을 감수하며 상태로 관리할 필요가 없다는 생각이 들었습니다. 결과적으로 현재의 시간 단위를 기준으로 변경 가능한 시간 단위를 판단해 하위 컴포넌트에 내려 주는 방식으로 리팩토링했습니다 😌

리뷰 요청사항

• api 호출

src/services/client/photographer/mypage/schedule.ts: 기본 스케줄 & 시간 단위 수정
src/services/server/photographer/mypage/schedule.ts: 기본 스케줄 & 시간 단위 조회

(+ 둘 다 페이지에서 페칭한 뒤 하위로 내려 주고 있습니다. 날짜별 스케줄의 경우 (지난 예약 건 조회처럼!) Suspense를 포함한 클라이언트 사이드 데이터 페칭으로 생각 중입니다.)

• UI/UX 관련
  기존 디자인과 차이가 커서 UI가 어색하거나 직관적이지 않은 부분 있다면 피드백 부탁드려요! 😓 아래는 개인적으로 고민됐던 부분들입니다

• 각 요일을 클릭해서 휴무일 / 영업일 변경하는 것 직관적인지
• 예약 시간 변경 요청시 안내하는 내용에 더 추가할 부분 없는지
• 시간 선택창의 경우 따로 닫기 버튼을 넣기에는 버튼이 너무 많아지는 것 같아 제외했는데 (열린 상태에서 바깥 아무데나 누르면 닫힘) 괜찮은지
• 시작 시간은 현재 설정한 종료 시간 이전으로만, 종료 시간은 현재 설정한 시작 시간 이후로만 선택할 수 있게 제한하고 있는데 이런 방식이 오히려 더 불편하게 느껴지지는 않을지

• 시급도: 높음
  스케줄 관련 기본 세팅을 해서 이후 티켓 작업에 전부 엮이는 부분이 있을 것 같습니다!

스크린샷

(* 30분 / 1시간 변경시 모달 화면, 30분 옵션 사용할 경우 시간 선택창)

[yuseok0215]

굳굳! 피그마에서 봤었던 ui보다 훨씬 직관적이어서 설정하기 편한 것 같아! 30분 단위일 때 시간 변경하는 ui도 좋고! 한 가지 드는 생각은 예약시간을 변경할 때 기존에 진행중인 예약건에 대해서는 반영되지 않음을 인지해달라는 문구를 하나 넣으면 어떨까 싶어!
ex) 기존에 10:00 ~ 20:00로 설정해둬서 고객이 18:00~20:00으로 예약해서 진행중인데, 10:00~16:00 이렇게 변경하는 경우
이건 사실 사진작가가 이미 인지하고 있는 부분이기도 하고 서비스 오류에 의해 발생되는 부분도 아니어서 꼭 넣을 필요는 없을 것 같은데 혹시 꼭 반영하고 싶으면 하고 아니라면 넘어가도 좋을 것 같아!

나머지 UI는 너무 좋다! 고생했어👍 (어프루브는 미리 해둘게!)

[eujin-shin]

굳굳! 피그마에서 봤었던 ui보다 훨씬 직관적이어서 설정하기 편한 것 같아! 30분 단위일 때 시간 변경하는 ui도 좋고! 한 가지 드는 생각은 예약시간을 변경할 때 기존에 진행중인 예약건에 대해서는 반영되지 않음을 인지해달라는 문구를 하나 넣으면 어떨까 싶어! ex) 기존에 10:00 ~ 20:00로 설정해둬서 고객이 18:00~20:00으로 예약해서 진행중인데, 10:00~16:00 이렇게 변경하는 경우 이건 사실 사진작가가 이미 인지하고 있는 부분이기도 하고 서비스 오류에 의해 발생되는 부분도 아니어서 꼭 넣을 필요는 없을 것 같은데 혹시 꼭 반영하고 싶으면 하고 아니라면 넘어가도 좋을 것 같아!

나머지 UI는 너무 좋다! 고생했어👍 (어프루브는 미리 해둘게!)

코멘트 읽고 보니까 스케줄 변경 전에 한 번 확인시켜 주면 좋을 것 같아서 아래처럼 추가했어! 설명이 그렇게 깔끔하게 되진 않은 것 같은데 이 부분은 업데이트 전에 검토하면서 더 좋은 표현으로 다듬어 봐도 좋을 듯,, 의견 고마워 🙌

[rheeri]

생각보다 리뷰가 늦어져서 미안해😣!
디자인이 따로 없어서 힘들었을텐데 깔끔하게 너무 잘만들었다 고생많았어!!

• 각 요일을 클릭해서 휴무일/영업일 변경하는게 UI 상 깔끔해서 좋은데, 사용자가 요일을 클릭하면 휴무일로 설정할 수 있단걸 알아차릴 수 있을까 하는 생각은 잠깐 들었어! 그냥 요일의 기본 디자인이 저렇게 생겼고 클릭해도 별다른 변화가 없을 것처럼 느껴질 것 같기도 해서 ㅎㅎ 근데 이건 그냥 내 관점이라 편하게 고민해봐줘!
• ‘오픈 시간을 30분으로 설정하시면’, ‘오픈 시간을 변경할 경우’ 이 문장에서 ‘오픈 시간’이라는 표현 대신 ‘시간 단위’ 등으로 언급하면 어떨까 ?_?
• 시간 선택창에서 닫기 버튼 따로 없어도 자연스럽고 불편함 없을거같아 👍
• 시작시간 이후 시간부터 종료시간을 설정할 수 있게 제한하는것도 좋은거같아 👍

[eujin-shin]

생각보다 리뷰가 늦어져서 미안해😣! 디자인이 따로 없어서 힘들었을텐데 깔끔하게 너무 잘만들었다 고생많았어!!

• 각 요일을 클릭해서 휴무일/영업일 변경하는게 UI 상 깔끔해서 좋은데, 사용자가 요일을 클릭하면 휴무일로 설정할 수 있단걸 알아차릴 수 있을까 하는 생각은 잠깐 들었어! 그냥 요일의 기본 디자인이 저렇게 생겼고 클릭해도 별다른 변화가 없을 것처럼 느껴질 것 같기도 해서 ㅎㅎ 근데 이건 그냥 내 관점이라 편하게 고민해봐줘!
• ‘오픈 시간을 30분으로 설정하시면’, ‘오픈 시간을 변경할 경우’ 이 문장에서 ‘오픈 시간’이라는 표현 대신 ‘시간 단위’ 등으로 언급하면 어떨까 ?_?
• 시간 선택창에서 닫기 버튼 따로 없어도 자연스럽고 불편함 없을거같아 👍
• 시작시간 이후 시간부터 종료시간을 설정할 수 있게 제한하는것도 좋은거같아 👍

나도 휴무일 변경이 눈치채기 힘들 것 같아서 계속 좀 신경 쓰였는데 ^_ㅜ 안내 텍스트를 따로 추가하는 것 말고는 마땅한 방법이 안 떠올라서 일단 그렇게 보완해 봤어! 시간 단위 변경할 때 메시지도 수정했어 👍

[rheeri]

나도 휴무일 변경이 눈치채기 힘들 것 같아서 계속 좀 신경 쓰였는데 ^_ㅜ 안내 텍스트를 따로 추가하는 것 말고는 마땅한 방법이 안 떠올라서 일단 그렇게 보완해 봤어! 시간 단위 변경할 때 메시지도 수정했어 👍

확인했어 고마워!