날짜 기능이 있는 게시판 만들기 with datepicker (1) - 요구사항

• 달력기능이 추가된 게시판이다.
• 이번에 이 기능을 만들면서 그리고 이 글을 쓰는 와중에도 끊임없이 계속 버그를 픽스하는데 꽤나 요구사항과 기능들이 복잡했기 때문이다.(라이브러리를 써서 그런 것 일지도 모른다..)
• 우선 요구사항만으로 이번 포스팅을 마무리 해본다.

요구사항

• 게시판을 만든다.
• 게시판에는 이벤트들이 목록으로 나오고, 각 이벤트에는 날짜가 지정되어 있다.
  • YYYY-MM-DD HH:mm AM - HH:mm AM
• 이벤트를 등록할 수 있는데 이 게시판은 달력을 이용해 날짜를 지정해야 한다.
  • input창 3개 1개는 클릭하면 달력이 나와야한다.
  • 2개는 시간이 나와야한다.
  • 처음에 날짜를 오늘로 했다면 처음 시간 input에는 현재시간 이전은 선택하면 안된다.
  • 시작시간을 정하기전에는 끝시간을 정할 수 없으며 시작시간이 정해지면 그 시간 이전시간들은 비활성화 된다.
• 이벤트를 등록할 시 쿠폰을 같이 등록할 수 있다.
  • 이때 쿠폰을 여러개 추가할 수 있으며
  • 이때 추가하고 저장한 쿠폰을 수정할 수 있다.
  • 이때 추가하고 저장한 쿠폰을 삭제할 수 있다.
• 쿠폰을 추가할 때
  • 이벤트는 딱 하루 하기에 날짜 시작시간 끝시간 이었다면
  • 쿠폰은 시작날짜 끝날짜 시작시간 끝시간이다.
  • 만약 이벤트 날짜를 지정했다면 기본적으로 날짜와 시간이 지정되어 있다.
  • 지정했다면 시작시간 = 끝시간 = 이벤트 날짜 이다.
  • 이벤트와 마찬가지로 시작날짜를 지정하지 않으면 시작시간을 지정 못하며
  • 따라서 유저는 무조건 시작날짜 시작시간 끝날짜 끝시간 순서로 작성하게 된다.
  • 저장시 만약 끝날짜가 시작시간보다 빠르다면 에러메시지를 내보낸다.
• 쿠폰을 수정할 때
  • 쿠폰 저장시의 날짜가 그대로 input창에 등록되어 있어야 한다.
  • 날짜와 시간을 바꿀 수 있지만 끝날짜와 끝시간은 무조건 시작날짜와 시작시간 이전이 비활성화 되어 있어 선택하지 못한다.
  • 그럼에도 끝날짜가 시작날짜보다 빨리 되었다면 저장시 에러메시지를 내보낸다.
• 쿠폰 삭제는 index를 사용한다.
• 쿠폰목록은 YYYY-MM-DD HH:mm AM - YYYY-MM-DD HH:mm AM로 보여준다.
• 이벤트 저장시 날짜들은 전부 YYYY-MM-DD HH:mm 형태로 보내야 한다.
  • datepicker는 입력된 값을 date객체형식으로 저장한다.
• 이벤트를 읽어올때(이벤트 수정시) 날짜는 tz형식이다.
  • YYYY-MM-DDTHH:mm:ss.00Z
  • 읽어올때 해외(GMT)로 9시간 더해져 있기 때문에 9시간을 빼주어야한다.
  • datepicker는 date객체만 읽기에 date객체로 변경해주어야 한다.
  • date객체로 변경한 후 useState의 기본값에 넣어 유저가 보았을때 전에 저장한 날짜가 이미 입력된 것으로 인식시켜야 한다.
  • 이후 날짜를 수정하지 않아도, 수정해도 YYYY-MM-DD HH:mm 형태로 서버에 보낸다.
  • 즉, tz로 받아서 → - 9시간 → date로 보여주고 수정하고 → YYYY-MM-DD HH:mm로 보낸다.
• 쿠폰의 경우 수정시에는
  • 저장된 쿠폰 읽기
  • 저장된 쿠폰 수정하기
  • 새로운 쿠폰 저장하기
  • 새로운 쿠폰 수정하기
  • 쿠폰 삭제하기를 고려해야한다.
• 여기서 까다로워 지는 이유는 서버에서 tz형식으로 읽어오기 때문이다.
• 쿠폰수정의 경우 목록에서 읽을 때
  • 기존 쿠폰 → tz로 받음 → YYYY-MM-DD HH:mm AM - YYYY-MM-DD HH:mm AM 로 보여줌
  • 신규 쿠폰 → YYYY-MM-DD HH:mm 받음(이벤트 저장시의 형식) → YYYY-MM-DD HH:mm AM - YYYY-MM-DD HH:mm AM 로 보여줌
  • 즉, 기존과 신규의 날짜 형식이 다르다.
  • 따라서 쿠폰의 수정의 경우에는 따로 tz형식으로 저장을 해서 통일을 시켜주어야 한다.
  • 이 부분이 어려웠던 이유는 날짜의 형식이 tz, date, 문자열(YYYY-MM-DD HH:mm)이 계속해서 바뀌었고 이 바뀐 데이터를 바로 유저에게 렌더링해서 보여줘야 했는데 이 부분이 useEffect와 useState의 깊숙한 부분을 건드리며 각각의 순간들(저장된 쿠폰 읽기, 저장된 쿠폰 수정하기, 새로운 쿠폰 저장하기, 새로운 쿠폰 수정하기)마다 서버와 api비동기 통신을 해서 데이터를 렌더링하기에 비동기 통신에 대한 넓은 이해와 적용이 필요했기 때문이다.
  • 특히 비동기 통신, 형식 바꾸기, 바로 렌더링하기의 순서를 맞춰주는것이 나에게는 꽤나 힘든과정이었다.
  • 수정시 모든 쿠폰들(저장된 쿠폰, 저장됐지만 수정된 쿠폰, 새로 저장한 쿠폰, 새로 저장했지만 수정한 쿠폰)은 하나의 전역저장소에서 모여 보내져야 한다.
  • 지금 생각해보면 따로 제출용 전역저장소 객체를 만들고 렌더링용도 만들어 뒀으면 훨씬 편했겠구나 생각이 든다.
    • 즉, 저장이나 수정시 제출용에 하나 저장, 렌더링용에 하나 저장의 방식으로
    • 다시 생각해보면 복잡해질 것 같기도 하고.. 장단점이 있는 것 같다.