Moment: 瞬間をほとんど不変にする

私の2セントは、完全な不変性を採用するか、まったく採用しないかのどちらかであるということです。 不変のメソッド（ startOf 、 add ）とそうでないメソッド（ year 、 get ）があると混乱するだけで、開発者は追跡する必要があります。どれがどれか。

また、デフォルトで不変のすべてを優先します。 ゲッターはすでに不変ではありませんか？

不変性への切り替えで私が目にする大きな問題は次のとおりです。

疑似不変性

javascriptの性質上、真の不変性を持つことはできません。

私たちができる最善のことは、コピーを作成してから、そのコピーを変更して返すことです。 すべてのパブリックメソッドを慎重にラップして、単に変更するのではなく、常にコピーして変更するようにすることができますが、それでも誰かがm._d = new Date()またはm._d.setHours(1)を実行するのを妨げることはありません。

@icambronに同意します。不変性に移行すると、完全な変更になるはずです。 ある瞬間にプロパティを変更する可能性のあるメソッドは、代わりにその瞬間のコピーを作成し、代わりにそのコピーに変更を加えます。

API表面積

疑似不変性への切り替えに関する不幸な点は、可変性を引き続きサポートする場合は、多くの新しいAPIを作成する必要があることです。

以前は、モーメントの変更からクローン作成とモーメントの変更への切り替えは、適切な場所に.clone()を追加するのと同じくらい簡単

これには、最大20のセッターメソッド、add / extract、local / utc / zone / tz、startOf / endOf、lang、およびサードパーティのプラグインで使用されるその他のメソッドが含まれます。

記憶の懸念

現在、値を変更するたびにコピーを作成しているため、メモリ使用量が増加します。 もちろん、新しい瞬間はガベージコレクションされますが、この変更に関連する追加コストは覚えておく必要があります。

他のセッターを使用する方法で大量の使い捨てクローンを作成しないように細心の注意を払う必要があります。

呼び出されているメソッドを追跡するために、この小さな関数ラッパーを使用しました。

for (var method in moment.fn) {
  moment.fn[method] = (function (fn, method) {
    return function () {
      console.log(method);
      return fn.apply(this, arguments)
    }
  })(moment.fn[method], method)
}

これで、メソッドを実行すると、プロトタイプの他のメソッドがどのように使用されるかを確認できます。 これらのメソッドのすべてがその瞬間にクローンを作成する必要があるわけではないので、クローンを作成する必要があるメソッドについてコメントを追加しました。

moment().isSame(moment(), 'year')
isSame
clone        // clone
startOf      // clone
month        // clone
date         // clone
year         // clone
date         // clone
hours        // clone
minutes      // clone
seconds      // clone
milliseconds // clone
valueOf
local        // clone
zone         // clone
startOf      // clone
month        // clone
date         // clone
year         // clone
date         // clone
hours        // clone
minutes      // clone
seconds      // clone
milliseconds // clone
valueOf

これは、作成されてすぐに破棄される21個のコピーです。 明らかに、変更可能で不変バージョンのみを公開するいくつかの内部メソッドを使用してこれを最適化できますが、クローン作成が必要な瞬間と不要な瞬間の記録を保持しようとすると、内部の複雑さが大幅に増します。

パフォーマンスの懸念

モーメントのクローン作成は、モーメントの変更よりもはるかに遅くなります。 私はこれのためにいくつかのjsperfテストを一緒に投げました。

http://jsperf.com/moment-cloning

http://jsperf.com/moment-cloning-2

2番目のテストは、疑似不変性に切り替えたときのパフォーマンスの低下をより適切に表現していると思います。 これらの結果に上記の21のクローン作成インスタンスを掛けると、実行時間ははるかに遅くなります。

クローン作成のパスを最適化できると確信していますが、同等のパフォーマンスを得るには、パスを50倍高速化する必要があります。 これは不可能だと確信しています。

概要

不変性に切り替えると、内部APIと外部APIの複雑さが大幅に増し、パフォーマンスとメモリに大きな懸念が生じます。 これらのコストは、不変性がもたらすメリットに見合う価値はないと思います。

ここにリストされているパフォーマンスの懸念は、ポイントを欠いていると思います。

一般的に、ミューテーションを実行する前に正確性を確保するには、最初の.clone（）が必要です。

現在のAPIではclone（）が必要ないように見せかけることはできません。 ここで異なる主なケースは、複数のシーケンシャルミューテーションを実行することです。 このケースは、すべてのミューテーションが単一のクローンでミューテーションとして実行されるようにビルダーAPIを作成することで対処されます。

他の一般的なユースケースがありませんか？

私の最初の問題は、具体的にはstartOfとendOfメソッドに関するものでした。 どういうわけか、私にとってこれらの名前は、「この瞬間を月の開始に設定する」ではなく、「月の開始を取得する」のようなものでした。 addやsubtractようなメソッドは、セマンティクスの意味で完全に問題ありません。 新しいオブジェクトを作成せずにオブジェクトに何かを追加することはまったく問題ありません。
私にとって、メソッドの名前をstartOfとendOfに変更して、 toStartOfとtoEndOfように（「この瞬間を月の初めに移動する」のように）解決します。問題。 私見では

@gregwebs申し訳ありませんが、上記のsetを意味します。

@soswowに同意しません。 一貫している必要があると思います。 実際、 toStartOfは、 toISOString代替プレゼンテーションを提供するように、不変性をさらに強く意味すると思います。 さらに重要なことは、「これらのメソッドでは、モーメントセッターがモーメントを変更する」や「モーメントセッターがコピーを返す」などのステートメントを作成できる必要があると思います。

@timrwoodの懸念について：

JSオブジェクトが本当に不変ではないということは私を悩ませません。 重要なのは、APIが不変のコントラクトを提供するということです。 もちろん、ユーザーは下線が引かれたプロパティをいじることで不正行為を行うことができます。不正行為は、不変性が主な方法である言語でも一般的に可能です。

表面積とパフォーマンスについて：CPUとメモリをすべて使い果たすことを避けるために内部でミューテータを使用する必要があると思います[1]。そのため、ある程度のレベルでそれらをサポートする必要があります。 次に、 setYear()などのように、それらを外部に公開することもできます。これにより、大量の表面積が追加されますが、実際にはそれほど複雑にはなりません。 非明示的ミューテーターの場合は、外部でクローンを作成し、内部で変更します。

これを確認する1つの方法は、ユーザーがコードのクローンを作成する必要があるため、Momentがユーザーのために行っている可能性があるということです。 これは、パフォーマンスに敏感な場所でのチェーンに関する問題を提示します。これは、ビルダーインターフェイス（Gregのアイデアによる）またはユーザーにミューテーターを使用させることによって戦うことができます。 ビルダーは多くの複雑さを追加します[2]ので、私は明示的なミューテーターの代替案を好むと思います。 現実には、ほとんどの場合、Momentはパフォーマンスに敏感な状況では使用されていないため、APIに関して最も便利な状況である必要はありません。 必要なときに備えて、パフォーマンスハッチを備えた不変のAPIが欲しいです。

[1] FPランドのかっこいい子供たちは、これを_構造共有_で解決しますが、ここではおそらく非現実的です。

[2]伝統的に、人々は別々のオブジェクトであるビルダーを作成しますが、セッターAPI全体をコピーする必要があるため、ここでは非常に冗長になります。 ただ唾を吐くだけですが、1つの選択肢は、 .chain()がisBuildingフラグが設定されたクローンモーメントを作成することです。 次に、内部クローンは無視され、ミューテーションのオブジェクトが返されます。 次に、 build()はフラグの設定を解除し、そのクローンを返します。 問題は、フラグが設定されている場合、ゲッターが血まみれの殺人を叫ぶ必要があることです。そうしないと、人々は、突然変異する連鎖しているが構築されていないモーメントを使用することになります。 次に、外部と内部で呼ばれるゲッターを区別する必要があります。 Blech。 もう1つの方法は、ビルダーに必要な機能を内部でミックスインに分解し、ビルダーとモーメントの両方で使用することですが、コード編成の観点からはおそらく機能しません。

私がうまくいったのは、関数に追加のパラメーターを追加することでした。フラグ（selfという名前）は可変性を示し、デフォルトでは不変（コピーまたは新しいオブジェクトを返す）であり、パフォーマンスを検出するとフラグをtrueに設定します。

この立場は多くの対立を解決しました、
ほぼ同じコードを実行する同様の名前の関数を持っている、
または、パフォーマンスポイントを検出したときに、関数名とおそらくパラメータを変更する必要があります
私のパブリックメソッドでは、関数を呼び出すコードをコピーで開始し、フラグをtrueにして呼び出しを続けます
これで私も機能を連鎖させることができます

私のコードでは、配列の配列（テーブル、行の配列など）を操作します
そのため、以前は結果を使用して新しい配列を再実行するフィルター、結合などの関数があり、同じ関数を数回呼び出した最終結果を取得するために、最初の呼び出しはコピーを作成することであり、変更しないことを検出しました最初の配列、および次の呼び出しでは、必要のない同じ配列ドロップ行を使用します

ここにある可能性のある基本的な例：
moment.add = function（measure、ammount、self）{
}

moment.add = function（measure、ammount、self）{
var $ moment = self？ this：this.clone（）;
//実際のコード
$ momentを返します。
}

みなさん、2セントありがとうございます:)

プロトコルについては、 @ icambronの最後の投稿にすべての点で同意します。

残っている2つの大きな質問があります。

簡単なのは、新しいAPIがどうあるべきか、2つのオプションです。
1.1異なる名前のメソッド（可変および不変） year / setYear 、 startOf / setStartOf
1.2またはビルダーAPI chain().mutators().build() 。これは@lfnavessが提案したもののハッキーではないバージョンです。

ビルダーAPIは間違いなくセクシーに見えますが、オブジェクトがビルドモードに長時間留まらないように注意する必要があります。これにより、私たちとユーザーに別の問題が発生します。

今、難しい問題-新しいバージョンへの移行。 ここに2つのオプションがあります。
2.1開発者はコードを書き直す必要があります（クレイジー正規表現は1.1および1.2のASTレベルのソリューションで機能する可能性があります-自分のメソッドの名前としてyearおよびmonthを使用する人がいない場合）。 pythonはこのアプローチを採用しました-私たちは皆結果を見ることができます-まったく新しい言語が生まれました！
2.2ビルダーAPIを常にオンにするオプション（現在と同じ）、および新しいコードに対して非アクティブ化する方法。 これはより_進化的_に見えますが、それが引き起こす混乱の量はおそらくそれだけの価値はありません。 すべての瞬間に2つのフラグがあります。それは可変であるか、そうである場合は-厳密に可変であるか（ゲッターなし）、または一時的に可変であるか（ゲッターはOK）です。 関数でモーメントオブジェクトを受信することは言うまでもありません。モードが何であるかを確認し、それを維持するようにしてください...なんて混乱なのでしょう。

そして今、私に思いついたクレイジーなアイデア

コピーオンライトクローン

m = moment();
funcIDontTrust(m.clone());  // doesn't actually clone

function funcIDontTrust(m) {
  m.year(2005);  // perform the clone here
  console.log(m);
}

インスタンスがかなり軽いことを考えると、このアプローチでどれだけ削減できるかはわかりません。 また、すべてのミューテーターがチェックを実行する必要があります。

さまざまなシナリオでさまざまなパフォーマンスを使用して実装する方法はいくつかあります。 良いニュースは、下位互換性があり、私たちとユーザーの労力を大幅に節約できることです。 そして、これは車輪の再発明よりも重要だと思います。

ここで何を得ているのかわかりません。

不変性への切り替えには多くの関連コストがあり、おそらく私はそれを見逃していますが、
同等のメリットはあまり見られません。

主な利点は開発者の好みのようです。 これはすべて、開発者が持っていないようにするためですか
それを渡すときに瞬間の所有権について考えるために？

不変性に切り替えることでバグの頻度が減るとは思いません。
バグの種類を変更します。 @ichernevの例は、正確な種類のバグを示しています。
表面、それは追跡するのと同じくらい難しいです。

m = moment();
funcIDontTrust(m.clone());  // doesn't actually clone

function funcIDontTrust(m) {
  m.year(2005);  // perform the clone here
  // m is still in 2014
  // m.year(2005) created a clone but did not assign it to anything
  // it should be `m = m.year(2005)`
  console.log(m);
}

これは、可変性と不変性の間の賛否両論のリストです。 私が何かを逃した場合、
私に知らせてください、そして私はこのコメントを編集します。

| 不変| 可変|
| --- | --- |
| 一部の開発者はそれを好みます| 他のいくつかの開発者はそれを好みます|
| 瞬間を回るときのバグを回避します| 複製されたモーメントの割り当てを忘れた場合のバグを回避します|
| 数十の新しいAPIメソッドで、可変性もサポートされます| 既存の.clone（）メソッドでは、不変性はすでにサポートされています|
| | 桁違いに速い|
| | 使用するメモリが大幅に少なくなります|

不変性は便利だと思いますが、JavaScriptにはあまり適していないと思います。 不変のインターフェースは、不変性が期待されるElmのような言語には意味があると思いますが、JavaScriptの場合、可変性が期待されると思います。

typeof a === "object"ビルトインのAPIの多くは変更可能です。 Array#push,pop,reverse,sort,shift,splice,unshiftすべて、新しい配列を返すのではなく、配列の内容を変更します。 16個のDate#setXメソッドはすべて、インスタンスを変更します。

瞬間が変化することについて不満を言う人はたくさんいると思いますが、切り替えると同じくらい多くの人が不満を言うようになると思います。 これは、2年前にeod/sodメソッドですでに発生して

可変性に関する多くの古い問題を見た後、私はおそらくここで壊れたレコードのように聞こえていると思います。 どちらの側でも、それは過去数年間提起されてきたのと同じ点です。 変更可能なAPIを維持するための議論が議論に表されていることを確認したかっただけです。

@timrwoodは良い比較ですが、不変のユースケースを理解するのに時間がかかっていないことは明らかです。 投稿したパフォーマンスの比較で、実装が不十分なAPIを想定していて、意味がない理由については、すでに説明しました。

バグ比較も無効です。 momentjsはチェーンAPIをサポートしているため、不変であることが期待できます。

var newM = m.year(2005) // wrong, these are both the same!

したがって、不変と可変の両方に、現在同じ問題があります。 チェーンAPIを削除すれば、現在の可変バージョンでそれを回避できます。

したがって、関数間で安全に瞬間を渡すことができるため、不変APIは可変よりも望ましいです。 関数間でモーメントを渡すと、現在の可変モーメントで2つのオプションがあります

1）非常識なバグのある方法（おそらく最も一般的です）：すべてのソースコードを調査して、不要な変異がないことを確認します。 ユニットテストを作成して、不要な突然変異が忍び寄らないことを確認します。
2）正気の方法（代わりに全員がこれを行っていると仮定しましょう）、防御的なプログラミング：関数を変更する前にclone（）関数を呼び出すことを忘れないでください。

不変のAPIを使用すると、毎回clone（）を呼び出すことを覚えておく必要はありません。 代わりに、クローン作成を回避できるAPI関数を呼び出すことを忘れないでください。ただし、これはパフォーマンスの最適化にすぎず、正確さの問題ではありません。

不変のユースケースを理解するのに時間がかかっていないことは明らかです

それは不公平な発言です。 私の主張は、私は利益を理解しているが、それらが費用を上回っているとは思わないということです。

あなたは安全に機能の間に瞬間を渡すことができます

クローンを呼び出すことを覚えておく必要はありません

これは不変性のユースケースではありませんか？ 私が理解するのに時間がかからなかったことがそれ以上あるならば、私に知らせてください、しかしこれは過去数年間の唯一の議論のようです。

@timrwoodはい、それがすべてのケースです。

しかし、あなたのケースが不変性（ひどいパフォーマンス、可変APIに存在しない別のタイプのバグを助長する）が無効であることを認める兆候は見られません。

Freeze（）が役立つかどうかわかりません
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze

ecmascript 5の観点に固執し、現在のオブジェクトをディープフリーズする関数、またはフリージーオブジェクトを自動的に作成するグローバルフラグを追加する必要があると思います

http://blogorama.nerdworks.in/preventextensionssealandfreeze/

フリーズオブジェクトはフリーズ解除できないため、フリーズオブジェクトを作成するためのコンストラクターの追加パラメーターかもしれません

@lfnavess書き込み時のコピーについて言及する前に、 freezeについて考えました。 問題は...誰もそれを使用しない/知らないということです。また、例外をスローしない場合（非厳密モードの場合）は役に立ちません。実際には、追跡するためのクレイジーなバグが作成されます。

@timrwood例を明確にしたとは思いません。 m.year(2014) // clone hereでは、内部的にモーメントが実際にクローンを作成し（より多くのメモリを割り当て）、mがその新しいメモリを自動的に指すことを意味しました。 これは基本的に、 clone()がシェルメモリ（内部の日付表現を指すもの）も少し割り当てる必要があることを意味します。そうすることでどれだけの利益が得られるかはわかりません。

インターフェースのみを複製し、基盤となるデータを（共有ストレージからインスタンス固有に）変更する機能を備えたclone半ばバージョンを作成します。これは、実際にはDateオブジェクトのコストに依存します。 欠点は、すべての関数が行う必要があることですthis._storage._dの代わりにthis._d 、そしてそれが利益を克服するかどうかはわかりません。

現在の既存のライブラリ/ユーザーの移行に対処する方法についてのコメントはありませんでした。 上記のオプションはどれも好きではありません。

逆互換性は、IMO、これに対する最も強力な議論です。 これを行う場合、それが大きな重大な変化であることを受け入れる必要があります。 それを受け入れたくないのなら、そうすべきではありません。

re：perfについては、不変性から得られる大きな利点もいくつかあることを言及する価値があります。 単調なパフォーマンスヒットではありません。 たとえば、物事は決して変更されないため、オブジェクトレベルでキャッシュすることができます。 また、 clone()から生きているがらくたを最適化できるはずだと思います。 AFAIKには、日付のクローンを作成し、5つの値のようにコピーすることが含まれます。 newThing._offset = oldThing._offsetようにハードコーディングする必要があると思います。

Edit、arg、no-プラグインもフィールドを追加します（例：ここ）。

下位互換性を強く望んでいるにもかかわらず、物事を軽量に保つことを強く望んでいることを考えると、最善の解決策はjavascriptソースをフォークすることだと思います（このプロジェクトのソースまたはまったく新しいプロジェクトを開始します）。 インターネット用の複数の時間の図書館のための余地があります。

また：re：構造共有に関する@ichernevのアイデア、1つの可能性は、共有状態オブジェクトをラップする代わりにプロトタイプ継承を使用することです。

私たちWhoopIncは、かなり長い間この議論に潜んでいます。 ここでの議論は循環しているように思われるので、私は今週末、ビルダーAPIを使用した不変の瞬間がどのように見えるかを調査するために時間をかけました。 （私は、招待されない限り、瞬間に対してPRを提出するつもりはありません。これは、瞬間自体に実装されると予想されるよりも、意図的にAPIの変更を厳しくしているためです。）結果は次のとおりです： https：// github。 com / WhoopInc / frozen-moment

私はほんの数時間しか経っていないので、すべてが端から端まで非常に荒いですが、テスト結果に基づいて、コアモーメント機能のほとんどが機能していると思います。 私はこの会話を追跡し続けます、そして私は私たちのレポの問題で私たちのフォークに特有のフィードバックを歓迎します。

今夜、そのリポジトリでいくつかの更新されたドキュメントを公開しようとしますが、基本的には、すべてのsetterメソッドとmutationメソッドを別々のビルダーオブジェクトに分割するだけです。 したがって、APIの使用はfrozenMoment("2014-07-21").thaw().subtract(1, "day").startOf("day").freeze().format("YYYY-MM-DD")ます。 （この特定の例では、 frozenMoment.build("2014-07-21").subtract...を使用して、frozenMomentからビルダーを初期化するのではなく、ビルダーでチェーンを開始する方が効率的ですが）

FWIW、私が使用を開始したとき、私はそれがFPの原則に従っていて、関数を呼び出すたびに同じ値を返すと思っていました。

var now = moment();
var yesterday = now.subtract(1, 'days');
var dayBeforeYesterday = now.subtract(2, 'days');

もちろん、期待した結果は得られませんでした。 これは私を新しいユーザーとして不意を突かれた。

この疑似コードについて考えてみましょう。これは、コードがどのように動作することを期待していたかを示しています。

var now = now;
var yesterday = now - 1day;
var dayBeforeYesterday = now - 2days;

しかし、代わりにそれはこのように機能することになり、それは私には奇妙に感じます：

var now = now;
var yesterday = now = now - 1day;
var dayBeforeYesterday = now = now - 2days;

今のところ、それはかなり退屈ですが、私.clone()どこでも慎重に

var now = moment();
var yesterday = now.clone().subtract(1, 'days');
var dayBeforeYesterday = now.clone().subtract(2, 'days');

IMO、Javascriptは微妙なエラーを起こしやすいので、FPの原則がそれらのエラーを最小限に抑えるのに役立つと思います。

これは難しい決断だと思います。 私はあなたの仕事に感謝します。 Moment.jsは素晴らしいです。

100％の不変性の場合は+1。

不変でないのは正直なところイライラします。

バージョン3で100％の不変性の場合は+1

間違いなく不変のAPIがあるはずです。 他の日付ライブラリ（特に、.NET DateTimeおよびJoda Time / Noda Time）のユーザーとして、 addメソッドが日付オブジェクトを変更しないことを直感的に期待しています。

不変性の+1

100％の不変性の場合は+1

不変性の決定が下された場合、私はそれを実現するために時間を割いて喜んでいます。 おそらく、ビデオ通話でペアリングします。 オープンソースにもっと貢献したいのですが、ロープを学ぶ必要があります。

私にとっては不変性が望ましいですが、最初から行う必要がありました。 これは劇的な破壊的な変化です。 不変性に焦点を当てたこのプロジェクトのフォークは、より良いアイデアです。

@dsherretそれがsemverの目的です。 メジャーバージョンをバンプするだけです。

ただし、ある程度の努力を払えば、「すべてを不変にしますか？TrueまたはFalse」という構成オプションとして導入できます。 デフォルトはfalseになります。

サポートされていない非公式のymmv不変モーメントプラグインはこちら： https ：//gist.github.com/timrwood/fcd0925bb779f4374a7c

ハハ！ ずっと後にここに来て、私がより不変のAPIの最初の支持者の1人であることを発見して驚いた。..:)

そして、はい、私は次のメジャーバージョンの不変性のために+1です。

私からのデフォルトで不変の瞬間のための別の+1。
そして、これが私の「imoment」の調合です： https ：//gist.github.com/idrm/a91dc7a4cfb381dca24e（自己責任で使用してください！）。 moment（）呼び出しをimoment（）に置き換えるだけで、それで十分です。 すべての静的moment.xyz（）（例：moment.min（）、moment.max（）など）関数呼び出しはそのままにしておく必要があります。

+1百万ドル

不変性の+1

このディスカッションスレッドからの以前の提案に+1を追加して、一部の関数の名前を読みやすくすることもできます（ "startOf"から "toStartOf"、 "add"から "plus"、 "month"から "withMonth "、 NS。）？ つまり、デフォルトで不変のルートを取ると仮定します。 私はJodaTimeをよく使用しますが、たとえば「date.withDayOfMonth（1）.withDayOfWeek（DateTimeConstants.MONDAY）」の意味を簡単に理解できます。
これらもメインのディストリビューションJSにある必要はありません。 バニラJSの上にこれらを叩くアドオンも同様に機能します（私は、このようなJoda Timeに合わせたアドオンを自分で作成して、「imoment」modと組み合わせる方法を強く検討しています）。

@ ichernev 、 @ icambron 、あなたはこれについて決定を下しましたか？ 3.0ではモーメントは不変になりますか？ もしそうなら：あなたはいつ3.0が出ると思いますか？ 凍結モーメントを使用するか、自分で小さなラッパーを作成することを検討しているので、私は尋ねています–そして私は待つべきかどうか疑問に思います。

参考までに、frozen-momentは最近、ほとんどが待機パターンになっています。上流のMomentから多数のPRを移植しましたが、そのフォークで理想的に発生するはずの他のリファクタリングには実際には取り組んでいません。

とは言うものの、デフォルトの英語ロケールのみが必要な場合は、frozen-momentがうまく機能するはずです。 （すべてが私のユースケースで機能し、Momentの高いユニットテストカバレッジを維持しています。）英語以外のロケールは、Momentの最近リファクタリングされたロケールAPIを移植した後に更新されなかったため、壊れています。

Moment 3.0の決定ができ​​たら、Momentでの不変性作業、または必要に応じて凍結モーメントフォークでもう少し真剣に取り組む予定です。 私の最初の目標は、ロケールのサポートを修正し、Moment3.0のAPIとの機能の同等性を維持することです。

不変性の+1

不変性の場合は+1。 オブジェクトも変更するformatメソッドはどうですか？

不変のmoment.jsの+1
または多分moment.jsのフォーク？ immutable-moment.js？ これは間違いなく重大な変更になるためです。

：100：
imootablesを行います！

+1最近の不変性は、優れたJSAPIに期待するものです。

：+1：はい、どうぞよろしくお願いします。 現在、.clone（）をいたるところに散らばっています。

+1これは非常に素晴らしい改善になります

：+1：すべてのものが不変

不変の場合は+1

すべてを不変にします。 now変数を操作する前に、すべてのmoment（now）変数のクローンを作成することにうんざりしていて、その後、nowが再び変更されます。

不変性の+1

startOf('day')が変化するとは思っていません

私は、moment.js演算子のほとんどが可変性に問題があることに間違いなく同意します。 mmnt.startOf('day')は、 mmnt変更するという点で、直感的なスーパーカウンターです。

多くのループと日付比較を伴うカレンダータイプのユースケースにmoment.jsを使用します。 clone()パフォーマンスの問題が発生しましたが、それらはひどいものです。 どのクローンと何が変異するかをある程度制御することは、私やおそらく他の人にとって不可欠です。
clone()どこにでもあることは最初は厄介に思えますが、それが行うことは非常に明確であり、パフォーマンスのためのリファクタリングが非常に簡単になりました。

より良いAPIを得るために、すべてのメソッドが内部でclone()盲目的に使用し始めた場合、私たちはその要点を見逃していると思います。

私の2¢:-)

@jdurand明示的に複製するよりも、明示的に変更したい。

@dsherret明示的には何も気にしません。 私の主な関心事は、非常にコストのかかる操作であるため、暗黙的にクローンを作成し
セッターはクローンコピーを返す必要があると誰かが言ったので、私は怖かった。 それは非常に非効率的です。

@jdurandの方が非効率的かもしれませんが、暗黙のクローンは、クローンオブジェクトと変更されたオブジェクトの違いがエンドユーザーのエクスペリエンスに目立った違いをもたらさないアプリケーションの大部分にメリットがあると思います。 開発者の大多数は一度に何千もの日付操作を行っていないため、開発者の使いやすさと開発者エラーの防止の試みは、節約された数ミリ秒よりも優先されるべきだと思います。 そうであれば、クローンを作成する代わりに変更したいと明示的に言うことができます。

補足：この変更により、パフォーマンスが向上する可能性があると思います...たとえば、代わりに過去の不変オブジェクトを参照し、このオブジェクトに対して実行する操作を保存することで、クローン作成を排除できます（例： add(1, 'days') ）。 結果は、 .toString() 、 .format() 、 .toDate() 、 .day()などが呼び出されたときにのみ操作を実行することによって計算されます。 これは劇的な変化であり、最終的には高速にならない可能性があります...パフォーマンスを比較するためにいくつかの単体テストを実行する必要があります（さらに、コードを見たことがないため、考慮していない他の問題がある可能性がありますクローン作成方法以外のmoment.jsで）。

@dsherret私は_builder_ / _lazy_アプローチが好きです。 後から考えると、おそらく最初からこのように構築されているはずです。
おっしゃるように、APIの互換性を念頭に置いた不変のフォークが最適だと思います。

さらに2セント：

1. パフォーマンスではなく利便性のためにモーメントが明確に構築されている場合、パフォーマンスについて本当に心配する必要がありますか？ m.add（ 'year'、1）の 'year'の解析は、クローン作成よりもはるかに遅いと思います。
2. トータルフォーク（別の名前、別のドキュメント）がない限り、2つのバージョンを維持するのはお尻の痛みになります。 賢い人が同じコードベースからmoment.immutable.min.jsとmoment.min.jsを生成するアイデアを思い付くべきだと思います...

いつから私たちは変化を壊すことをとても恐れていますか？ 現在のバージョンは安定しており、コードベースをリファクタリングしなくても引き続き使用できます。

2つのコードベースを維持することは苦痛であり、速度が低下し、可変/不変バージョンを用意するだけの価値はありません。

それでは、完全に不変の瞬間に行き、メジャーバージョンをバンプして、それで完了しましょう：dancers：

このライブラリを使い始めたばかりのときにこのスレッドを見つけましたが、コードのデバッグを行っていて、変更可能であることの予測できない副作用のように思われます。 ライブラリの完全に不変のバージョンを見たいです！

恥知らずなプラグ：私はここで確固たる決定を待つのにうんざりしました。 過去数日間、私はFrozen Momentを復活させ、Moment自体のプラグインとして機能するように書き直しました。 週末に最初のプレビューリリースを完了するのを手伝ってくれた@wyantbへの帽子のヒント。

Frozen Momentは、Momentと同じように機能する不変タイプを提供します。 基本的に、不変バージョンはMomentの機能をラップし、必要に応じて.clone()を呼び出します。

ビルダーAPIが好きな人は、Moment自体をビルダーオブジェクトの非常に優れた実装として考えるように挑戦します。 Frozen Momentは、私たち全員が必要とするコアの不変タイプと、可変Momentから不変のFrozenMomentを構築するためのメカニズムを追加します。

便利な不変のAPIを使用したいだけの人のために、私もそれをサポートするつもりです。 Frozenインスタンスを直接ビルドするコンストラクターはまだ作成していませんが、TODOリストにあります。 短期的には、回避策はmoment().freeze()またはmoment.utc().freeze()すべてを作成することです。

Frozen Momentは明らかに若いコードベースであるため、おそらくいくつかの荒削りな部分がありますが、期待どおりに機能しないものについては、試してみて問題を解決することをお勧めします。

ああ、もう1つ：私はまだこれを宣伝していませんが、FrozenMomentインスタンスはほとんどのMomentプラグインで「正しく機能する」はずです。 他のすべてのMomentプラグインがFrozenMomentの前に登録されていることを確認してください。 不変のFrozenMomentsで期待どおりに機能しないプラグインを見つけた場合は、バグを報告してください。調査します。

不変性の+1

不変の場合は+1

誰かがImmutableJSの上にモーメントを実装することを検討しましたか？ これはJSでの不変性のために最適化されたライブラリであり、不変オブジェクトの変更されていない部分を再利用して、メモリの問題を軽減します。

+1
これが原因で3年前のバグを修正しました： https ：

それで、ユーザーは不変性を求めますが、コアチームはそれをしない言い訳を見つけますか？ ：NS
さあ、この変更はES6でコードを書き直すよりもはるかに重要です^^現在の形式では、APIは単純に悪く、一部のメソッド（フィルター、連結など）が不変であるJS配列に少し似ていますが、一部は下位互換性に対する制約がライブラリよりも無限に高いことを除いて、他のものは（逆、ソート）ではありません。

+1

いつも私を捕まえる小さな罠（そして私見これは不変性の正当な理由です）：

var today = moment();
for (var i = 0; i < 7; i++) {
   week.push(today.subtract(i, 'days').format('dd').toUpperCase());
}

残念ながら、これは日の名前の配列を生成しませんが、実際には次のように日付を計算するため、奇妙なことが発生します。

i = 0 = today -0;
i = 1 = today -0 -1;
i = 2 = today -0 -1 -2;
etc

したがって、これにリファクタリングする必要があります。

var today = moment();
for (var i = 0; i < 7; i++) {
            if (i == 0) {
                week.push(today.subtract(0, 'days').format('dd').toUpperCase());
            }
            else {
                week.push(today.subtract(1, 'days').format('dd').toUpperCase());
            }
        }

@faebser優れた例

不変性の+1

+1

@faebserは今朝私に起こりました。 Angularの双方向バインディング+可変性は、現在の日付を変更しないようにクローン作成日を維持するために**に苦痛を与えます。

不変性の+1、これは私に数時間かかりました。

：+1：

不変性の+1

私はこのトピックについて少し引き裂かれています。

私の中の純粋主義者は、「不変性のために+1！モーメントオブジェクトは明らかにValueObjectの種類です」と叫びたがっています。

ただし、moment.jsがGitHubで13番目に人気のあるjavascriptリポジトリ（および24番目のオールラウンド）であり、bower.ioで「moment」を検索すると111の一致した結果が返されることを無視できません。 アプリケーションビルダーにモーメントの不変バージョンを実装する段階的な方法を提供できたとしても、その依存関係の間に大きな混乱を引き起こすでしょう。

@ichernevおそらくもっと謙虚な提案：瞬間のドキュメントページのごく一部を、

現在、ドキュメントページには「不変」という用語は記載されていません。 「momentimmutable」をグーグルで検索すると、このページに移動しますが、読むのに2時間かかり、このトピックに対する現在のスタンスについてはまだわかりません。 「瞬間不変」に対するグーグルのトップヒットが瞬間の不変性の未来についての迅速な答えを与えたなら、それは素晴らしいことです:)

@ jehoshua02を引用するには：
「これは難しい決断だと思います。あなたの仕事に感謝します。Moment.jsは素晴らしいです。」

これが私の提案です。 ベースモーメントを不変にする代わりに、 moment.immutableファクトリを追加します。 それはの財産になりますmoment関数と同じ正確なAPI署名を囲みますmomentが、不変。

それは、そのプロトタイプの機能を使用して、変更可能なmomentファクトリのプロトタイプ拡張である可能性もありますが、代わりにクローンを作成します。

編集： WhoopInc / frozen-momentがまさに私が探しているもののようです。

@thomasvanlankveldの重大な変更は、メジャーバージョン番号の目的です。 Bowerとnpmを使用している人は誰でも、現在のメジャーバージョン番号に固執するオプションがあります。 ここでは下位互換性について心配する必要はありません。CDNからこれを提供しているだけの人を除いては。 しかし、CDNのmomentjsを使用している場合は、とにかく時々ライブラリを更新することにそれほど関心がない可能性があります。

次のメジャーバージョン（またはその後のメジャーバージョン）で不変性を持つことは、ロードマップ上にあるべきだと私は主張します。

だから私もこの問題に遭遇したようです。

http://stackoverflow.com/questions/33002430/moment-js-formatting-incorrect-date

ですから、私は全面的に不変性を求めています。

+1不変性の場合

この驚くべき予想外の行動にちょうど夜を失った。
明確にするために、対応するメジャーバージョンの変更を伴う不変性の別の+1。

+1不変性の場合

完全な不変性の場合は+1。
「時々変更可能、時には不変」のために失われた時間の合計量はかなり大きいに違いありません。

ええ、私は真剣に意味します。 日時ライブラリでのパフォーマンスを気にするのは誰ですか？ のように..本当に？ 99.9％のユーザーは、リモートでも優れたパフォーマンスを必要とすることを何もしていないと思います。 通常、2、3の日付、または最悪の場合は数百の日付を処理します。 1秒あたり数百万の日付を処理している少数のユーザーは、最適化された可変APIポイントを使用できます。

不変性は唯一の正しい設計上の選択です。 不変型を使用したプログラミングは、可変型を使用した場合よりもバグが発生しにくいことを示すいくつかの研究があります。

不変性の場合は+1。 これには数時間かかりました。

問題の一部は、 .startOf()ようなメソッド名が、基になるオブジェクトの変更を意味しないことです。

私はMomentでパフォーマンスのボトルネックにぶつかったので、これが時々発生する可能性があることを保証できます。

ただし、不変のモーメントが本質的に効率が低くなるとは確信していません。また、それらがより効率的になるいくつかのケースを想像することもできます。

この議論はずっと前にJavaの世界で解決されました。 不変の日付が勝ち、最も人気のある実装（JodaTime）が最終的にJava8の標準ライブラリの一部になりました。

Java 8のLocalTimeの作業は、「なぜ私たちは_常に_これをしなかったのですか？」 瞬間。 テクノロジーを伝道することはめったにありませんが、正直なところ、変更可能な日付オブジェクトの利点はわかりません。

だから、ええ....これらのスレッドが+1で溢れるのは嫌いですが、問題の真実は、Momentが作成しない場合、他の誰かが不変のJS日付ライブラリを作成しようとしているということです。

私は最近、JodaTime APIの多く（つまり、Java 8の日付）をJSに移植することを目的とした新しいnpmモジュールに出くわしました。

これにより、不変性、LocalDate、LocalTimeなどがノードとブラウザにもたらされます。

これらの概念をJavaで使用したことで、他のすべての概念は厄介でバグが発生しやすくなります。

リンク？

金、2015年12月11日には、午後4時30分アンドリューSchmadel [email protected]
書きました：

私は最近、の多くを移植することを目的とした新しいnpmモジュールに出くわしました
JodaTime API（つまり、Java 8の日付）からJSへ。

これにより、不変性、LocalDate、LocalTimeなどが
ノードとブラウザ。

Javaでこれらの概念を使用した後、他のすべては厄介な感じがします
バグが発生しやすい。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/moment/moment/issues/1754#issuecomment-163964349 。

うわー。
（モバイルで入力、簡潔さを言い訳）

まだチャイムを鳴らしていないので、モーメント3.0では不変性を支持しているとだけ述べておきます。 主な理由は、 momentようなオブジェクトが_

パフォーマンスに大きな打撃があったとしても、それは正しいことです。 モーメントは他の人のデザインに自然にフィットする必要があります。 直感的なAPIはパフォーマンスよりも優れており、ミューテーションは値オブジェクト（IMHO）では直感的ではありません。

また、moment 3.0はDateオブジェクトへの依存関係を削除する必要があると思いますが、それは別のスレッドについての議論です。

ここで@ mj1856に完全に同意します。

私は瞬間インスタンスでObject.freezeを使用してきましたが、これは一般的に私が必要としていたものを達成しました。 ただし、次のことが失敗することがわかりました。

let now = Object.freeze(moment());
if (now.isSameOrBefore(anotherTime)) { // throws exception
}

例外：

TypeError: Can't add property _isValid, object is not extensible
 at valid__isValid (C:\git\quick-test\node_modules\moment\moment.js:93:24)
 at Moment.moment_valid__isValid [as isValid] (C:\git\quick-test\node_modules\moment\moment.js:2195:16)
 at Moment.isSame (C:\git\quick-test\node_modules\moment\moment.js:1945:44)
 at Moment.isSameOrBefore (C:\git\quick-test\node_modules\moment\moment.js:1962:21)

これを修正して、必要なときにObject.freezeを使用できるようにすることはできますか？

@wmertensこれだと思います： //github.com/pithu/js-joda

@ ichernev 、 @ mj1856 、私はしばらくの間コア開発に関与しておらず、不変性がかなり重要な関心を持っているので、以前のスタンスを撤回しています。

これに対する唯一のブロッカーであるかどうかはわかりませんが、3.0で不変性を使用して前進することは快適です。

@ gabrielmaldi @ wmertensうん。 それだけでした。 境界線に一貫性のないコメントをお詫びします-途中で書かれた投稿の[送信]ボタンをはっきりとクリックしました。

私のばらばらな考えのいくつかをまとめるために：

• JSの不変の日付オブジェクトには明らかに関心があります。 他のいくつかの言語には成熟した不変の日付ライブラリがあり、JSの不変オブジェクトに対する一般的な勢いがたくさんあります（ immutable.jsには10,500の星があります）。 少なくとも、これは概念実証に値すると思います。
• この関心にもかかわらず、書かれたコードはほとんどないようです。 js-jodaは、JS用の不変の日付ライブラリを作成する最初の本格的な試みのようです。
• 不変の瞬間は大きな破壊的な変化であり、それはいくつかの哲学的な疑問を提起します。 非常に大規模なMomentJSコミュニティのサポートを失うのは嫌ですが、不変のJS日付に興味を持っている私たちにとって、きれいな休憩を取り、試してみる代わりにjs-jodaに貢献することは必ずしも恐ろしいことではありません。 Moment（大規模で確立されたユーザーベースを持つ成熟したライブラリ）にかなり根本的な変更をプッシュします。
• 余談ですが、js-jodaはまだ非常に若く、著者の目標と意図がライブラリに対して何であるかは不明です。 特に、彼はライセンスを選択する必要があり、典型的なJS開発者のニーズがJodaTimeまたはJSR-310の忠実な再実装によって満たされるかどうかを検討したいと思うかもしれません。

不変性の場合は+1、結果として得られるサナーコード。

それは大きな努力になるでしょう、それでそれを実現するであろう（そしてそうしてきた）人々に心から感謝します。

モーメントは十分に広く使用されているので、 @ butterflyhugのhttps://github.com/WhoopInc/frozen-momentと同様に実装されていると仮定すると、次のようなものを使用するのが実用的だと思います

3.x：オプションとして不変で、デフォルトはfalseであり、グローバルモーメントエクスポートにtrueに設定されるフラグが設定されています。 ライブラリのロード時にconsole.warn（開発モード）
4.x：オプションとして不変、デフォルトはtrue、フラグは引き続きfalseとして設定できます。 console.warn 5.xのスケジュールについて（開発モードで）
5.x：唯一の方法として不変

長期的な不変性のビジョンを説明するページを前もって中央に配置します。たとえば、私がレイアウトした3.x / 4.x / 5.xのアウトラインに沿って年に1回のメジャーリリースを行います。これで、妥当なものになると思います。影響を受けた人がコードを更新するための金額。

いくつかの観察：

1. 不変性がプラグインなどを壊す瞬間のエコシステムの問題点を見つける方法として、ここにいる多くの人々が喜んでそれを使って物事を構築することを期待して、 WhoopInc / frozen-momentを構築しました。これまでのところ、それを行った人はほとんどいません。 、これにより、プラグインの作成者が不変の瞬間をサポートできるように、凍結された瞬間やコミュニティの伝道に取り組む意欲が低下しました。

とはいえ、frozen-momentを使用しているときに人々が見つけたバグの修正を喜んでお手伝いします。それらのバグが私のものであるかどうか、またはモーメントが不変になる可能性を考慮していなかった別のモーメントプラグインにあるかどうかは関係ありません。 凍結した瞬間に問題を提出するだけで、見ていきます。 そして、私はまだ、凍った瞬間のようなものに関するコミュニティの努力が、不変の瞬間への移行の痛みを理解し、緩和するのに役立つと思います。

1. momentが3.0で不変性を実装する場合、誰かがラッパーを作成して維持し、不変の3.xAPIの上に可変のmoment2.xAPIを実装するのは非常に簡単です。 概念的には、これは実際には凍結モーメントによく似ています。凍結モーメントが暗黙的にclone()場合、この可変ラッパーは代わりに、内部参照を新しい不変モーメント値に暗黙的に変更します。 これは、大規模なコードベースでモーメントを使用する人々の移行を容易にするのにも役立ちます。
2. 必要に応じて、潜在的な問題について考え、瞬間3で不変性を実装するのを喜んでお手伝いします。
3. js-jodaは、BSDライセンスを使用してJSR-310をJavaScriptに

@ butterflyhug-凍結された瞬間を構築してくれてありがとう！ それを見つけたときは興奮しましたが、サポートが削除された場合、不変の瞬間から可変の瞬間に変更することは私のコードで大きな仕事になることを考えると、プロジェクトから凍結モーメントへの依存関係を導入することを心配しました。 あなたの目標がフィードバックを得ることであり、あなたがそれを積極的にサポートしているなら、私はそれをするのがより快適です。 :-)

他に何人の人が同じ思考プロセスを持っていたのかわかりません。

ここの人々が、パフォーマンス上の理由から、 Dateオブジェクトへの依存関係を壊す（またはある種の遅延評価を追加する）という概念と併せて不変性を調査する必要があると考えているかどうか興味があります。

@schmod、一度に一歩ずつ物事を進めることをお勧めします。 これはすでに（明らかに）大きな変化です

@RobertMcCarterうん、不変性のオプションがコアライブラリに実装されない限り、予見可能な将来に凍結モーメントをサポートすることを計画しています-主に、私が期待するいくつかのことに個人的に使用しているためですしばらく維持します。 とは言うものの、私のユースケースはMomentエコシステム全体に及ぶわけではないので、他の人々からのフィードバックと使用法を利用して、何が重要かを特定します。

最初にendOf（）を使用した後、アプリで何が起こったのかを理解するのに30分費やした後、不変性の+1。 ドキュメントを注意深く読んでいなかったのは確かですが、その名前のメソッドは、たとえば月の終わりを返し、モーメントインスタンスは影響を受けないままになると想定しました。 正直なところ、それは驚きであり、それがこのように起こらないことはばかげていると思います。あるいは、私の意見では、ほとんど不変のAPIを持つことの大きなメリットに頭が慣れすぎているかもしれません。

不変性の+1 :)

私は不変性を気にしません、この優れたライブラリを放っておいてください！

@ es6Test不変性に同意できない理由は何ですか？ 変化への抵抗以外に具体的な理由はありますか？

+1
私のコードが.clone（）メソッドでいっぱいで、時々可変性がバグを見つけるのが非常に難しい場合、ライブラリが不変であれば、ライブラリの使用が容易になると思います。

+1お願いします、もっと不変性^ _ ^

@danpantryさらにいくつかのアプリを作った後、気が変わった。 私は不変性を好みます。

しかし、まだいくつかの変数を変更可能にしたいので、瞬間に日を追加したいことがよくあり、結果を保持するためにさらに変数を作成する必要はありません。

@ es6Test _本当に_嫌いな場合はlet使用しますか？

let date = moment()
// with immutability
date = date.add(5)

私も不変性に賛成です。 これがPythonのdatetimeライブラリの1つの機能であり、それが本当に輝いています。 文字列の場合と同じように、オブジェクトを変更することを心配せずにオブジェクトを投げることができます。

React / Reduxの世界では、不変性が非常に重要です。 瞬間は本質的に不変ではないので、私はすでにいくつかの厄介な問題に遭遇しました。 パフォーマンスは軽減できるため、ここでは関係ありません。 FacebookのImmutableJsライブラリは、パフォーマンスを犠牲にすることなく不変を実行できることを証明しています。

また、不変性についてもずっと+1します。 それまでは不変性のメリットが得られないため、途中でやっても意味がありません。

不変性と関数型プログラミングはこれまで以上に使用されています（そして私はそれが大好きです）。 私はこのイニシアチブに貢献するために私自身の時間を提供します。 寄稿者は私に連絡して、私がどのように助けになることができるかを知らせてください。

私たちが非常に興味を持っていたので、チームはこれについて最新情報を提供したいと思いました。

現時点で、私たちはあなたの懸念を聞いたことを知ってほしい。 メンテナチーム全体が、ライブラリをゼロから作成する場合は、ライブラリを不変にすることを選択することに同意します。 しかし、それは今のところではありません。

現状では、月に400万のNPMダウンロードがあり、他のチャネルを介して瞬間を取得することに依存しているユーザーの数は数え切れません。 これらのユーザーはすべて、今日のようにモーメントが変更可能であることを期待するコードを持っています。 さらに、モーメントが変更可能であることに依存する多くのプラグインがあります。

コードを書くのは簡単ですが、この種の変更のサポートニーズは、私たちの暇な時間にこれを行う小さなチームとして引き受けるのは困難です。 そうは言っても、私たちはそれを検討する用意があります。 しかし、私たちは疑問に思っています：

• 凍結モーメントプラグインがニーズを満たさないのはなぜですか？
• 不変のAPI（常にクローンを返すAPI）が必要なだけですか、それとも何らかの理由でオブジェクトを内部的に本当に変更しない必要がありますか？
• 現在のコードに2番目の不変のAPIを追加すると、ニーズが満たされますか？

フリーズモーメントプラグインの問題は、オプトアウトではなくオプトインであるということです。 毎日
moment（）を不変にするには、.freeze（）が必要です。

不変性の要点は、オブジェクトXがある場合、それを知っているということです。
明示的に変更可能にしない限り、変更しても不浸透性である必要があります。
なしでオブジェクトを内部的に変更できるパブリック関数
明示的な可変性には問題があります。

1つの回避策は、いくつかのことを行うことだと思います。

1. 現在のコードに2番目の不変APIを追加します
2. グローバルmoment（）設定があり、不変モードに設定されている場合は、すべて
   作成されたmoment（）インスタンスは不変であり、可変呼び出しが試行された場合、
   変更せず、代わりに不変を使用するための適切なメッセージでエラーが発生します
   API呼び出し。

みんなを満足させると思います。 どう思いますか？

12:11時月、2016年5月23日には、マギー・パイント[email protected]
書きました：

私たちがたくさん持っていたので、チームはこれについての最新情報を提供したかった
興味。

現時点で、私たちはあなたの懸念を聞いたことを知ってほしい。 NS
メンテナチーム全体が、ライブラリを
根本的に、私たちはそれを不変にすることを選択します。 しかし、それは方法ではありません
今です。

現状では、月に400万回のNPMダウンロードがあり、
他の人を介して瞬間を取得することに依存している数え切れないほどの数のユーザー
チャネル。 これらのユーザーはすべて、モーメントが次のように変更可能であることを期待するコードを持っています。
今日です。 さらに、私たちは瞬間に依存している多くのプラグインを持っています
変更可能。

コードは書くのに十分簡単ですが、この種のサポートの必要性
私たちのスペアでこれを行う小さなチームとして変更を行うことは困難です
時間。 そうは言っても、私たちはそれを検討する用意があります。 しかし、私たちは疑問に思っています：

• 凍結モーメントプラグインがニーズを満たさないのはなぜですか？
• 不変のAPI（常に
  クローン）、または何らかの理由で内部的に本当に変異しないようにする必要がありますか？
  オブジェクト？
• 現在のコードに2番目の不変のAPIを追加すると、
  ニーズ？

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/moment/moment/issues/1754#issuecomment -221062274

GmailアカウントのEricLau。

@maggiepintに返信していただきありがとうございます。

1. フリーズモーメントプラグインに関するいくつかの問題：これはデフォルトではなく、使用するために追加の作業が必要であり、アクティブに維持される可能性が低くなります。不変として構築されています。 最大の問題は、特に多くのエンジニアがいる大規模なプロジェクトで、それを使用するのを忘れることだと思います。
2. APIは副作用がないはずです。 クローンを返すことは良いことですが、元のオブジェクトも変更すると、副作用が発生します。 次のコードは、endを宣言するときにstartを変更しないでください。

start = moment();
end = start.add(10, 'minutes');

1. 「add」に加えて「immutableAdd」のような関数があるということですか？ もしそうなら、技術的にはそうです。特に、同じ名前を使用して不変の関数を使用するラッパーを作成する場合はそうです。

import "moment/immutable";
start = moment();
end = start.add(10, 'minutes'); // immutable version of add

私の意見では、このアプローチは、不変のAPIを使用したい人にとっては優雅なアップグレードに役立ちます。既存のコードは引き続き機能し、強制されることはなく、不変のAPIを使用したい人にとっては変更が少なくて済みます。

私たちは、コードの副作用をなくすというあらゆる意図を持っています。 基本的なパターンは、現在の関数にフックし、それらにcloneを呼び出させてから、そのクローンを操作することです。

ただし、技術的には、真に不変のコードを作成する場合、オブジェクトは変更されない値で構築する必要があります。 ただし、そうすると、この変更を行うのが難しくなります。 クローンを呼び出して、以前と同じように実行する方がはるかに簡単です。

私はドリューの考えを2番目にしています。

import "moment / immutable";
start = moment（）;
end = start.add（10、 '分'）; // addの不変バージョン

それは不変のオプトアウトであり、変更がないので、それは素晴らしいことです
関数名。

12:53時月、2016年5月23日には、マギー・パイント[email protected]
書きました：

私たちは、コードの副作用をなくすというあらゆる意図を持っています。 基本
パターンは、現在の関数にフックし、クローンを呼び出させることです。
次に、そのクローンを操作します。

ただし、技術的には、真に不変のコードを作成している場合、オブジェクトは
変更されない値で構築する必要があります。 そうすることで
ただし、この変更を行う際の難易度を上げます。 それははるかに簡単です
cloneを呼び出して、前に行っていたことを実行します。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/moment/moment/issues/1754#issuecomment -221076796

GmailアカウントのEricLau。

@ ericlau-固体

1. グローバルmoment（）設定があり、不変モードに設定されている場合は、すべて
   作成されたmoment（）インスタンスは不変であり、可変呼び出しが試行された場合、
   変更せず、代わりに不変を使用するための適切なメッセージでエラーが発生します
   API呼び出し。

ページ上の2つのライブラリが異なる瞬間の動作を予期している場合、これは機能しなくなります。 たとえば、変更可能な瞬間を期待するdatepickerを使用し、独自のコードは不変の瞬間を期待します-それは機能しません。

不変のAPIを持っている（凍結した瞬間）

プラグインが機能しないため、これも完璧ではありません。 実際には、不変性を導入し、既存のすべてのプラグインを機能させ続ける方法はありません。 プラグインは、誰かがプラグインを機能させるために時間を費やす前に、まったく機能しないか、不変の瞬間で機能しません。

import "moment / immutable";

したがって、これは基本的に、同様のインターフェイスを持つ別のライブラリを提案しています。 確かに、コードを壊すことはありませんが、混乱を引き起こし、一部のプロジェクトに2つのバージョンがインストールされている可能性があります（たとえば、datepickerは変更可能なバージョンを取り、コードは不変のバージョンを取ります）。

最良のオプションは、現在のAPIとほぼ同じように、ただし不変のオブジェクトを使用してAPIを作成することです。 フォークが正常である可能性があります。 結局のところ、それが自由ソフトウェアのやり方です。

開発者はコードを段階的にアップグレードできるため、「2つ目のAPIを追加/サブモジュールを公開する」オプションは互換性のために最適です。 可能であれば、 moment()の意味（モジュールランドのimport moment; 、またはブラウザビルドのmomentグローバル経由）はまったく変更されないはずです。そこにたくさんのレガシーコード。

IMO、次のことを可能にするソリューションが理想的です。

import moment from 'moment';
import {immutable as immoment} from 'moment';

var a = moment(); // mutable moment
var b = moment().immutable(); // immutable moment
var c = immoment(); // also an immutable moment; shorthand

別のライブラリではありませんが、そうです-2つの別個の異なるタイプのモーメントがあります。 可変および不変のモーメントオブジェクトが「内部」でかなりの量のコードを共有すると仮定すると、両方の構文を使用する必要がある開発者にとって、ライブラリサイズをそれほど増やす必要はありません。 アプリケーションが1つの構文のみを使用する場合、ツリーシェイクを使用して最適化されたビルドを生成できます。

ライブラリをフォークすると、ほとんどの開発者がロードする必要のあるコードのサイズが2倍になる可能性があり、これはほとんどのWebアプリケーションにとって望ましくありません。

プラグインが「箱から出して」不変の瞬間で動作すると想定するのは良い考えではないと思います。また、それが合理的な要件であるとは考えていません。

また、可変APIと不変APIが同一であることが合理的な要件/仮定ではないと思います。 アップグレードパスをできるだけスムーズにするように努める必要がありますが、厄介な構文に縛られるべきではありません。

また、「不変」APIがどのように見えるかについては議論/議論の余地がたくさんあると思います。 ビルダーパターン？ コンストラクターのインスタンス化？ 値オブジェクト？ 現在のAPIを実装しますが、クローンを返す「セッター」メソッドはありますか？

私の1つの要求は、新しいAPIが、どのような瞬間を扱っているかについて明確かつ明確にする必要があるということです。 IMO、 freezeはそのテストに失敗し、私が一瞬を過ぎるたびにclone()を呼び出す以外にほとんど保護を提供しません。

したがって、これは基本的に、同様のインターフェイスを持つ別のライブラリを提案しています。 確かに、コードを壊すことはありませんが、混乱を引き起こし、一部のプロジェクトに2つのバージョンがインストールされている可能性があります（たとえば、datepickerは変更可能なバージョンを取り、コードは不変のバージョンを取ります）。

個別のライブラリではなく、同じライブラリのスリムなラッパーです。 インストールする必要があるのは、momentの1つのバージョンだけです。 「moment / immutable」をインポートでき、datepickerは同じプロジェクトで「moment」を問題なくインポートできます。

不変の瞬間を処理するように更新されていない場合、瞬間を取り込んだり返したりするプラグインとのインターフェースに問題がある可能性があります。

プラグインに不変の瞬間を渡したとしましょう。プラグインは現在、それを可変として扱います。 プラグインが更新されるまで、プラグインに瞬間が与えられる前に、可変に変換する方法が必要になります。 理想的には、プロジェクトのメンテナが不変性をサポートするために時間を割いた後、非推奨になります。 おそらく、不変性を検出する方法も必要になるでしょう（プラグインの作成者向け）。

反対に、不変のインターフェースを使用するように更新し、不変の瞬間をユーザーに返すライブラリは、不変を使用せず、不変の瞬間を期待していないユーザーを捨てる可能性があります。 これは、非推奨の変換方法でも処理できると思います。 プラグインは、渡されたものと同じタイプのモーメントを返す必要があります。

@maggiepintはい、私はあなたのcloneのアプローチで大丈夫でしょう。 特にねじれが解決されている間。

@tacomanatorそれも私がやりたいことです。 内部で真に不変であるようにすべてをやり直すことは、ひどく耐えられません。
どういうわけか人々がそれを望んでいたかどうか私は知りませんでした。

@schmod freezeが明確で明確なAPIであると思わない理由について簡単に説明していただけますか？

関数名が可愛すぎる場合は、そのリポジトリの問題として、FrozenMomentのメソッドの名前を変更するための引数を検討してください。 一方、可変から不変に（そしてその逆に）変換することが可能であるとは思わない場合は、ここでいくつかの議論を促す可能性があると思います-ただし、FrozenMomentも喜んで受け取ります。それがより良いAPIであるという大まかなコンセンサスが得られれば、その方向に向かっています。

@maggiepint 「現在のコードに2番目の不変のAPIを追加する」を、基本的にFrozen Momentの一部またはすべてをコアライブラリにバンドルしていると読んで正しいですか？ それが役に立ったら、Frozen Momentまたはそのアイデアの一部を（公式プラグインまたはコアライブラリの一部として）モーメント組織に移行し、その新しいコンテキストでのメンテナンスを支援できることをうれしく思います。

@butterflyhugあなたは@ichernevが何を考えていたかを正確に言っています。 彼は、ライブラリに付属している公式プラグインに傾倒していました。 たぶん、Gitterでこれを調整できるかもしれません。 仕事で3日間不在にする必要があるため、空室が限られます。 残りの人は周りにいるはずです。

@butterflyhug

freezeは良い名前だと思います。「すべての単一の」瞬間の呼び出しの後に、それを使用することを覚えておく必要があるのは残念です。

import 'moment/immutable'にも同じ問題があると思いますが、忘れがちです。

正直なところ、あなたはsemverをフォローしています。正しいアプローチは、すべてを不変に_デフォルトで_使用し、この変更を独自のメジャーバージョンとしてリリースし、一定期間（12か月？）後に古いバージョンをサポートしないようにすることだと思います。 新機能/修正は、不変と可変の両方のトラックにマージでき、変更可能なバージョンを使用するユーザーに移行計画が提供されます。

前述の12か月後、古いバージョンは_まだ_機能しますが、TLCを受信しません。

もちろん、これには多くのオーバーヘッドがありますが、下位互換性のために変更を試みるよりも、この変更を正しく行う方がよいと思います。 また、変更が非常に複雑になり、コア開発チームの関心が薄れる可能性があります。 私は知らないよ。

このアプローチのもう1つの潜在的な欠点は、ユーザーがCDNからこのスクリプトを使用していて、明示的なバージョンを指定していないことです（何らかの理由で）。これにより、下位互換性のあるAPIがリリースされた場合にサイトが破損する可能性があります。 「そう言った」としか言えませんが、今のところ許容できるリスクではないかもしれません。

同じライブラリの2つのバージョンがあることは、グローバルオブジェクトに依存している場合にのみ問題になり、 freeze()を使い続ける以外に、それを回避するための適切な方法はありません。

TLDRは、解決しようとしている問題が、すでに使用しているsemverによって解決されているように聞こえます。 本来あるべき姿で使ってみませんか？ 変更を壊すためのメジャーバージョン。 これが機能しないのは、グローバルmoment変数に依存していて、CDNを使用している場合だけですが、ここで変更を加えると、とにかく問題が発生します。

私の投票は、semverおよび不変の3.0リリースにもあります。

私はfreeze名前に異議を唱えませんが、瞬間が凍結されているかどうかについて安全な推測をすることが難しいということは本質的に問題があると思います。 （ Object.freeze()にも同様の問題があります）

不変の瞬間は凍結不可能であってはならず、凍結されているかどうかについて疑いの余地はありません。 これは、ビルダーパターンの厳密な変形（つまり、オブジェクト_only_が.build()が呼び出されるまでセッターを持ち、その後_only_がゲッターを持つ）を介して、または瞬間を「凍結」することで実現できます。インスタンス化され、すべてのセッターがクローンを返します。

例えば：

/* BUILDER PATTERN */
var bldr = moment.immutable()
  .hours(5)
  .minutes(30)
  .seconds(25);

bldr.hours();  // throws exception.  builder has no getters

var time = bldr.build();

time.hours(); // 5
time.hours(6); // throws, OR returns a clone

/*  A more explicit variant:  */
var bldr = moment.immutable()
  .setHours(5);

bldr.getHours; // undefined

var time = bldr.build();
time.getHours(); // 5
time.setHours;   // undefined

/* VALUE OBJECT */
var time = moment.immutable()   // 00:00:00
  .hours(5)       // new object => 05:00:00
  .minutes(30)    // new object => 05:30:00
  .seconds(25);   // new object => 05:30:25

/*  Same thing, but more efficient:  */
var time2 = moment.immutable(5,30,25); // 05:30:25

time.hours();   // 5
time.hours(6);  // new object => 06:30:25

最初の例は非常にJavaに似ていますが、モーメントがどのように構築されるか、およびそれらを使用して何ができるかについても、あいまいさはほとんどありません。 また、オーバーヘッドがほとんどない新しいモーメントを構築するための効率的で直感的なパスを提供し、ほとんどの人が現在どのようにモーメントを使用しているかを厳密に追跡します。

構築されたモーメントのセッターに例外をスローさせることに賛成です。この動作により、あいまいさがさらに減少し（冗長性が犠牲になります）、開発者は新しいモーメントを作成するたびに認識を強制されます。

2番目の例は、多くのオブジェクトを作成（および破棄）しているため、オーバーヘッドがはるかに多いようです。 しかし、最適化の余地はたくさんあります。 最新のGCはかなり優れています。 遅延評価が役立つ可能性があります。 Momentオブジェクトを可能な限り軽量にする（基になるDate削除する）など（いくつかの比較のために、このパターンはJavaScriptで文字列が処理される方法と同じです）

私はsemverのファンですが、モジュールローダーがないと同じページに2つのバージョンのモーメントを配置することは不可能であるため、ブラウザーのユースケースでは重大な変更が問題になります。

前に述べたように、Momentに依存するレガシーコードがたくさんあります。 少なくとも、スムーズな移行期間を可能にするために、両方のパターンをサポートするリリースが必要です。

新しい瞬間を返す構成可能なメソッドの場合は+1。 それらが不変であるかどうかさえ気にしません。 構成を教えてください。メソッドを連鎖させたり、変更されたモーメントを2行ではなく1行に割り当てたりできます。

@alexyulyなぜクローンが機能しないのですか？ インラインで作成したい場合は、次のようなことができます。

var a = moment();
var b = a.clone().subtract(1, 'week').startOf('day');

または何でも。

@maggiepintばかげていると思いますが、ずっとメソッドを作成できるようです。 ヒントをありがとう。 たぶんそれをドキュメントでもう少し明確にしますか？ 例： http： //momentjs.com/docs/#/manipulating/start -of / <-戻り値についての言及はありません。

少し更新-このブログ投稿は、現時点でこの問題に関する私の立場です： https ：

私はチームの他のメンバーについては話しませんが、彼らはそれを見ており、私たちは一般的に私たち全員が同じような場所にいると言います。

@maggiepint素晴らしい非常に有効なポイント

これをありがとう。 不変性はreduxの王様なので、確実にjs-jodaに切り替えます。 私はまだ相対的な時間のために瞬間を保つかもしれません。

エリックラウ-Gmail

2016年6月24日金曜日11:12 AM -0700、「MaggiePint」 [email protected]は次のように書いています。

少し更新-このブログ投稿は、現時点でこの問題に関する私の立場です： https ：

私はチームの他のメンバーについては話しませんが、彼らはそれを見ており、私たちは一般的に私たち全員が同じような場所にいると言います。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

突然変異によって引き起こされるいくつかのより典型的なバグ/混乱： http ：

これは+1ですが、実際にはReduxを使用しているので、MomentインスタンスをRedux状態オブジェクトにまったく入れていないため、これは驚くほど小さな問題であることがわかりました。 日付文字列またはタイムスタンプのみで、レンダリングメソッドでMomentを使用して、日付文字列を他の文字列に変換します。

私がこれを行うのは、主に、余分な作業なしで状態をシリアル化および逆シリアル化するのが簡単であるだけでなく、ReactとReduxからミューテーションをうまく隠すためです。

今週末、これに関する最新情報を入手できるように最善を尽くしています。 計画はありますが、コミットする前にすべてがうまくいくことを確認する必要があります。 残念ながら、私は来週ミネアポリスからシアトルに移動するので、これはしばらく遅くなるかもしれませんが、私はそれを前進させたいと思います。

そのブログ投稿がまだトラフィックを獲得していることに気付いたので、大きな更新に備えて小さな更新。 私は現在、Babelを使用するためにmomentのビルドを作り直しています。 これにより、 @ butterflyhugのプラグインをコアリポジトリに@butterflyhugは、これに関して非常に親切に私たちを助けてくれました。 さらに、LoDashのJohn-David Dalton（どちらもMicrosoftで働いています）と会って、公式プラグインを導入する際の戦略について話し合っています。彼はすでにLoDash関数型でそれを行っていたからです。 長いブログ投稿とRFCがまもなく登場します。

@maggiepintは、frozen-momentを公式にサポートしていますが、 https：//github.com/WhoopInc/frozen-moment/issues/20に対処する予定

moment()呼び出すたびにデフォルトでフリーズした瞬間が返され、開発者が毎回.freeze()呼び出すことを覚えておく必要がない限り、この不変性へのアプローチは十分に良いと思います。

@gabrielmaldi良い質問です。 私はRFCを書いています（今すぐに行う必要があります）。そうです、不変のみの使用のためのより良いストーリーを提供することが私の明確な目標です。 私の提案は、静的メソッドを考慮に入れて、WhoopInc / float-moment＃20に関する私のコメントに沿ったものです。 RFCリポジトリに対してPRを開くときに、こことその号にRFCへのリンクを投稿します。その時点で、提案に対するコミュニティのフィードバックを歓迎します。

RFCドラフトの作成を終了し、PRを

この機能をユーザーにどのように提供したいかについて未解決の質問がまだいくつかあるため、これは非常に長いドキュメントです。そこで、さまざまなアプローチの長所と短所を強調しようとしています。 しかし、実装のアイデアはかなりしっかりしていると思うので、提案されているユーザー向けAPIについて予約があれば、ここの人々から聞いてみたいと思い

RFCのエグゼクティブサマリーと回答すべき主な質問： https ：

@maggiepintその記事にコメントを投稿しようとしましたが、どういうわけか飲み込まれました。 これが私が書いたものです：

これらの変更に関する私の最大の懸念は、コミュニティの不釣り合いに声高で表現力豊かな部分に対応することです。この議論が行われていることにさえ気づいていない通常の開発者の静かな防波堤を避けます。

GitHubのスレッドは、より広範な開発コミュニティの縮図ではありません。 このサイトは、Web上の多くのフォーラムと同じ参加バイアスに苦しんでおり、特定の種類の開発者に偏っています。 アプリケーションよりもアイデアに興味がある。 そしてあえて私は、社会的に人気のあるトレンドの周りに集まる傾向があるとさえ言います。 これらの開発者は、不変性や関数型プログラミングなどの哲学的なコーズセレブレに自然に惹かれ、他のどのグループよりもあなたに近づきます。 彼らは部屋の中で最も大きな声になり、この変化を叫ぶでしょう-しかし、より広い世界はどうですか？

より広い世界は、機能するものを望んでいます。 現在使用しているライブラリが引き続き更新を受信することを知りたいのですが、少なくともバグ修正ですが、理想的には、彼らの生活をより良くする小さな段階的な改善です。 しかし、それはそうは言いません。なぜなら、それはこれらのフォーラムを積極的に探し求めておらず、トレンドに反対するために厚い肌を必要とするからです。

あなたがこの変化に熱心であるならば、私はあなたがこれらの人々にこの変化が彼らの生活をより良くする理由を非常に明確に主張する必要があると思います。 なぜアップグレードする必要があるのか​​。 レガシープロジェクトが間接的なバグ修正を受け取らないことを心配する必要がない理由。 そして本質的に-彼らが現在できないことを彼らが今できるようになること。

また、この変更の重要性を実際に検証することにも十分注意する必要があると思います。 この変更をプラグインまたはラッパーとしてリリースし、トランクにマージする前に、数か月にわたってその取り込みを注意深く監視する必要があるのではないかと思います。 不変性がニッチな懸念として過大評価されている場合は、ライブラリ全体のコースを変更せずに、これらのボーカルユーザーを満足させる方法を見つけることができます。

初めてのユーザーとして、startOf endOfでしばらく失った後、ここで終了しました。 これらの方法は驚くほど変化しています！

完全な不変性の場合は+1

たぶん別の解決策は、momentjsのオブジェクトが可変であることを

別の解決策、可変性が必要な場合は、オブジェクト指向の概念を使用し、 NEWキーワードとmoment（）ファクトリパターンを使用してオブジェクト作成を作成します。

より広い世界は、機能するものを望んでいます。
...この変更が彼らの生活をより良くする理由をこれらの人々に非常に明確に主張する必要があります

私が目撃したすべての人は、「瞬間」が変化するという罠に陥ります。
3年間使用した後でも、「。startOfを使用しています。コピーが必要な場合は2回確認することをお勧めします」と自分に言い聞かせる必要があります。

現在の動作は直感的ではなく、これは長い間遅れています。
array.filter / mapを変異させて、それがどれほど楽しいかを確認してください。

それにかんする...
パフォーマンス/メモリ：私は今までに2つ以上の機能を連鎖させたことがなく、通常は.set().get()
疑似不変性：java-pass-by-ref-genがリリースされるまで、何世代にもわたって時間がかかります。

OOPと不変性のどちらを探しているかを選択するという@AdamHessのアイデアが好きです。

私たちが混乱する理由についての私の2セントはこれです：戻り値。 JSの可変関数が一般的に行うように、 moment.add('1', 'days')が未定義を返していた場合、混乱はなくなります。 同じオブジェクトを返すことは、少なくとも私にとっては、新しいコピーがあることを意味します。 もちろん、それは連鎖性を壊します。

より多くの開発者がメモリ使用の問題にぶつかる可能性は低いと思います（特別なユースケースを除く）。 しかし、瞬間の可変性はすでに私を噛みました。 日付は、文字列や数値のような値として扱う必要があります。

デフォルトで不変の場合は+1

ちなみに、これと同じ問題がPHPにも存在します。 PHPのようになりたいですか？！ 😆

PHPでは、（通常のDateTimeに加えて） DateTimeImmutable提供することで問題を解決します。

デフォルトの動作を不変に変更しない場合は、少なくともimoment / momenti （またはその他）のようなファーストクラスの代替APIを検討する必要があります。 私は文字通り常にそれを（可変APIを介して）使用し、私が使用する他のライブラリも不変バージョン/ APIを使用することを望んでいます。

私も不変性に投票します。それが計画である場合は、実装を支援したいと思います。 加算と減算を行うときに、すでに可変性の問題に遭遇しました。さらに混乱を招くのは、これらのメソッドが連鎖のためにインスタンスを返すことです。

ちなみにクローン期間はどうですか？ それを行うための最良の方法は何ですか、ハッキーを感じなかったものを見つけることができませんでした。

@ngerritsen利用可能な最良のオプションはmoment.duration(existingDuration)だと思います。

再：実装、＃3548はまだアクティブなPRです。 コードレベルの作業があまり残っていないことを願っていますが、大きな変更を検証するためにもっと目を向けても問題はありません。 また、メジャーバージョンバンプを実行する前に、ドキュメントなどに取り組む必要があります。これは、このような変更をリリースするために必要になります。 このリストのいずれかを手伝いたい場合は、私たちはそれをいただければ幸いです。 😀

.startOf（）が元の日付を変更することによって引き起こされる微妙なバグを特定するために1時間費やしました...ハードワークのおかげで、momentjsはJSの優れた日付ライブラリを構築する方法を示す素晴らしい仕事をしましたが、私は切り替えていますこの種のバグの非常に微妙な性質と、いくつかの一般的なFPの概念（主にReact、Redux、ELMのおかげで）を紹介した後、不変性の一般的な利点を理解し始めたためです。

その価値については、lodashはすでにlodash / fpを使用したより多くのFPアプローチに従っています。 すべてを完全に書き直すのではなく、既存の関数をラップするため、lodash / fpがどのように実装されているかを確認することをお勧めします。 Lodashの人たちはパフォーマンスについても非常に心配しています。

@mullにも同意し

moment.frozen名前空間が機能している間は、前の投稿者が示唆したように、 date-fnsのみを使用することをお勧めします。

可変モーメントによる別のバグを修正しました🎉

正直に関連して、3.0がES6クラスに移行できれば素晴らしいでしょう。

let mom1 = new Moment();
let mom2 = Moment.parse('2019-03-01T14:55');
// etc

そのような動きはまた、不変性の議論を導く可能性があります。 1つの例外を除いて、すべてのメソッドは不変である必要があります。 .set('minute/hour/year/etc', 18)と呼ばれるメソッド。

私はMomentを使い始めたばかりで、このライブラリが最初から完全に不変ではないことに_恐怖_しました。 これが修正されるまで、 moment-immutableを使用しています。

@alancnetの瞬間はおそらく変更されることはありません。 それはあまりにも大きな変化であり、現在の行動を受け入れることを学んだユーザーからの十分な反発があります。

彼らの新しいプロジェクトをチェックしてください： luxon
これは非常に素晴らしく、モダンで、不変（！）であり、すべてを.clone()呼び出しでラップするモーメント不変よりもはるかに優れたパフォーマンスを発揮するはずです。

momentjsから最新のアプローチに移行したい場合は、 https：//github.com/you-dont-need/You-Dont-Need-Momentjsをチェックして

それが可変であることに非常に驚いています！

luxonが代替品になるまでどのくらい

@alamotheその質問はウェブサイトで明確に回答されています： https ： //moment.github.io/luxon/docs/manual/moment.html

これを閉じます。 他の人が指摘しているように、ほとんど不変のAPIが必要な場合は、Luxonを使用してください。 ありがとう。