0618
chat 개발하면서 느낀 것
- 최고의 개발은 요구사항을 잘 소화해서 최대한 개발하지 않는 쪽으로 방법을 찾는 것
- 달리고 있는 차의 바퀴를 교체해야할 땐 최대한 간결하게 필수적인 것만 교체할 생각을 하자
Polymorphic컴포넌트를 만들 수 있게 되었다useRef는 선언한 위치의 DOM 노드를 사용하는 것이 아니라 JSX 엘리먼트 중ref={ref}로 주입해주는 타겟 노드의 DOM 노드를 사용할 수 있는 것이다(e.g.<MyInput ref={ref}/>= Page.tsx의 ref가 아닌 MyInput의 ref를 사용 가능)
시간 데이터를 다루면서 느낀 것
- 프론트-서버 간 데이터를 주고 받을 때는 뭐가 됐건 딱 하나의 유일한 포맷으로 소통해야 혼선이 덜하다
- 배경
- 기존엔 연월일까지만 다루다가 처음으로 시분초까지 시간 개념을 확장하게 됨
- 시분초가 추가되니 프론트에서 입력한 시간이 UTC 시간으로 변환된 채로 서버에 저장됨(e.g. 2024-05-24T03:00:00 → 2024-05-23T18:00:00)
- 서버에선 여태껏 시분초를 신경쓰지 않았으니 날짜를 로컬 타임으로 가지고 있었음(내 추측)
- 그래서 프론트에서 다시 GET으로 꺼내 쓸 때 9시간이 부족한 현상이 발생
- 이 당시 논의에서는 클라에서 선택한 시간대로 서버에 전송하고, 서버에서도 로컬타임으로 보내주기로 약속
- 이후 이슈 발생(오늘)
- DB에는 이 값이 그대로 박힘 (ex: 2024-05-24 18:00:00.00000)
- 서버에서 GET api를 통해 프론트로 보내줄때 여기에 Z값만 붙여서 보냄 (ex: 2024-05-24T18:00:00.000Z
- 이걸 프론트에서 받으면, 브라우저가 로컬 타임으로 변환해서 자동으로 9시간을 더함
- 결론(해결)
- 클라에서 시간 데이터를 서버에 전송할 때 UTC 형식으로 보내기로 변경(시간이 DB에 어느 한 로컬로 박혀있으면 확장성 문제가 발생)
- 다만 사용자에게 보여줄 때는 로컬라이징하여 사용자의 브라우저 로컬타임에 맞게 변환해 보여주기로 함
- 서버에는 다시 UTC 기준으로 저장되게 하고, 클라로 보내주는 시간에 Z를 붙여 보내주기로 약속
- 배경