⏱

日付のフォーマットはフロントで扱いたい

2022/06/18に公開

JavaScript

date

tech

はじめに

バックエンドから日付のdateが返却される場合、このような形式で返却されることが多い気がします。

{
  "datePattern1": "2022-06-17T00:00:00.000Z",
  "datePattern2": "20220617T000000.00Z",
  "datePattern3": "2022-06-17T00:32:55.077022Z",
}

YYY-MM-DDTHH:mm:ss.sssZ のような形式でバックエンドから返却されると、フロントでフォーマットする必要が出てきます。
それならいっそのことフォーマットしたものをバックエンドから返却してもらえば良いのでは？と思い色々調べてみました。

結論

色々調べた結果、フロントでフォーマットをした方がメリットが便利な場面が多いと思いました。
(むしろバックエンドでフォーマットしてしまうと困りそうな場面があるかも。。。)

フロントでフォーマットしたい理由

画面によって表示したいフォーマットが違う可能性がある

画面によっては 2022年6月17日 や 2022-06-17、日時まで指定して 2022年6月17日 0時0分 まで表示したい場合など様々な場面が想定されます。
「日付まで表示しているものを時刻まで表示したい！」という仕様変更の場合に、バックエンドでフォーマットしていたらAPIの修正が必要になります。
仕様変更のたびにAPIの修正を行うのは現実的ではないです。
1つのAPIを使い回す場合の柔軟性

「でも仕様変更のたびにフロントのフォーマット変えるのも嫌じゃない？」
と言われれば確かにそうなんですが、同じAPIを各画面で使用する場合はその限りではないです。

1つのAPIのレスポンスを各画面で使用する場合は多々あると思います。
その場合に、1つの画面だけフォーマットの形式を変えたい仕様変更が発生した場合に、フロントでフォーマットできれば1画面の修正ですみます。
バックエンドでフォーマットしていた場合、日付のフォーマット変更したプロパティを追加する必要があり、レスポンスの項目が増えてしまいます。
タイムゾーンを考慮する場合

タイムゾーンは端末によっても異なるので、バックエンドからタイムゾーン付き日時を受け取ってフロントで解釈する他ない気がしています。
またタイムゾーンの違いに伴った時差やサマータイムの考慮は全てフロントの時間を扱うライブラリ(momentjsやdate-fns)に任せてしまいたいです。

以上のことから、フロントでフォーマットした方がより柔軟に仕様変更などに対応できます。

バックエンドから返却される日付の形式

冒頭で紹介した以下の形式。

{
  "datePattern1": "2022-06-17T00:00:00.000Z",
  "datePattern2": "20220617T000000.00Z",
  "datePattern3": "2022-06-17T00:32:55.077022Z",
}

この YYY-MM-DDThh:mm:ss.sssZ の形式はISO8601という規格です。

バックエンドからの日付形式はISO8601の形式で返却される。
フロントではその形式のまま日付情報を取り回して、表示する際に画面側でフォーマットする。

このようなルールが決まっていれば、フロントでフォーマットの関数を共通化しておけば柔軟に対応できそうです。

おわりに

日付の形式やどこでフォーマットするかを曖昧にしたまま実装を進めると、後で仕様変更の対応が大変そうです。
あらかじめバックエンドとフロントエンドでどのように日付を取り扱うかを決める上で、仕様の変更に柔軟に対応する上でも、日付のフォーマットはフロントで行いたいと思いました。

設計の段階でこういうとこまで考慮できるようになりたい。