iview を例に挙げると、iview の日付セレクターは非常に使いやすいですが、その問題は確かに明白かつ致命的であり、おおよそ次のとおりです。
v-model を直接使用して値をバインドできます。レンダリングされたページの結果の日付は正しいですが、バインドされた値の日付は 8 時間短くなります。これは主にタイム ゾーン処理のレガシーな問題です。実際、彼らはこの問題を非常にうまく解決できると思います。しかし、何年も経った今でも、彼らはそれを解決するつもりはないようです。iview からの提案は、v-model で @on-change メソッドを使用することです。 iview 公式ドキュメントに示されているように、編集中にデフォルト値をエコーし、新しい値の表示 (8 時間以上) の正確性も処理します。
v-model バインディング値は Date オブジェクトであり、@on-change パラメーターは文字列であるため、より深刻な問題が発生する可能性があります。つまり、開発の場合、同じデータでも異なる型が存在することになります。フォーム検証ルールなどの明確な要件がある場合、この問題は明らかです。たとえば、データのセットを編集する場合、日付が含まれますが、日付を変更する必要はありません。保存をクリックするだけで、日付の検証。検証の結果、文字列ではないことがわかりました。デフォルトの string を読み取るときに datepicker が文字列を標準の Date オブジェクトに変換するため、当然、エラーが報告されます。フォーム検証設定のデータ型が string の場合、もちろん検証ルールを日付に変更した場合は編集時にそのまま渡せますが、日付を選択してon-changeメソッドを使うとまた文字列になってしまいますが、そしてまだ問題があります。公式がこれに対して良い解決策を提供していないことがわかります。
実際、フォームチェックを使用する場合に時刻を確認したい場合は、日付型を使用して確認する方が良いため、on-change メソッドを使用する必要がなく、メソッドを 1 つ少なく書くことができます。ただし、標準日付は 1 日少なくなります。実際には、この 1 日を要しない問題に対処するだけで済みます。サードパーティのライブラリ モーメントを使用する方がよいでしょう。これに対処する最良の方法です。この問題は、フォームの送信時に処理できます。
最初のインストールの瞬間 (cnpm を使用していない場合は、npm に変更します):
cnpm install moment --save次に、使用したメソッドを vue の例にバンドルします。
import moment from 'moment'
//moment.locale('zh-cn')
Vue.prototype.$moment = moment
次に、コンポーネント内でそれを呼び出します。
obj.model.startTime = this.$moment(obj.model.startTime).format('YYYY-MM-DD')呼び出されたコード行に注意してください。瞬間的に渡されるパラメータは Date オブジェクトであり、フォーマット後に文字列を返します。