impl executive dashboard UI

[wjeongchoi]

요약 *

It closes #1359

단일 라벨을 사용하는 DateRangeInputWithLabel 구현 포함

스크린샷

이후 Task *

• 없음

[babycroc]

아 생각해보니까 영미가 react date library 써서 공고 쪽에서 쓴 date range 입력받는 뭐시기가 있었는데... 점차 date 입력 사용하는 곳들은 그 패키지 쓰게끔 마이그레이션 시켜야 할 것 가타여

[jooyeongmee]

흠 그러게 지금 시간 입력 부분 작동 안되는거 같은데 DateInput으로 range 설정할 수 있기도 하고(ActivityCertificateInfoSecondFrame의 dateRange 부분) 지금 화면처럼 두개의 필드로 할거면 MeetingInformationFrame 의 시작일 종료일 필드처럼 할 수 있을듯?
그리고 또 다른 의견은 앞으로 이렇게 common component 새로 만들 때 해당 컴포넌트 스토리북도 함께 만들면 어떨까? 스토리북 하나 만드는게 오래 걸리지도 않고 매번 나중에 따로 인력 투입해서 하는 것보다 그 컴포넌트 만든 사람에 한번에 해서 같은 pr에서 스크린샷이든 실행해서든 그것까지 확인해보는게 좋을 것 같다는 생각이 들어 @babycroc @wjeongchoi 어떻게 생각하나요?

[wjeongchoi]

이거 아직 백 안 나와서 UI 구현만 빠르게 한거긴 한데 range 구현 어떻게 하는게 나을지 알려주면 다음 작업에서 수정할게요 @jooyeongmee
이거보다 급한거 배포 나갈게 있는걸로 아는데 그거 배포 될때까지는 머지 안 하는게 나으려나?? @babycroc

[jooyeongmee]

이거 아직 백 안 나와서 UI 구현만 빠르게 한거긴 한데 range 구현 어떻게 하는게 나을지 알려주면 다음 작업에서 수정할게요

요거 디자인에 따라 갈릴듯 구현하기 편한건 하나의 필드로 되어 있는 전자 방식일거 같고(react Date Picker 기능을 그대로 가져다 쓰는 느낌) 디자인 이쁘고 상태관리를 우리가 다 컨트롤하는건 2개의 필드로 되어 있는 후자 방식인듯(react Date Picker의 range 기능을 사용하지 않고 각각의 필드에 대해 우리가 직접 유효성 검증해야 함)
전자로 하면 타입은 dateRange: [Date | null, Date | null]; 이렇게 되어야 하고 후자로 하면 타입은 각각 start: Date | null, end: Date | null, 이렇게 받는 느낌

흠 뭐가 더 편할지 모르겠네 뭔가 전자는 나중에 각각의 날짜에 대해 복잡한 유효성 검증이 필요하면 좀 더 컨트롤하기 어려워질거 같고 후자는 매번 그 두 필드를 묶어서 유효성 검증하는게 귀찮을거 같고