Moment: اجعل اللحظة ثابتة في الغالب

سنتان لدي هما أنه يجب علينا إما أن نذهب إلى الثبات الكامل أو لا نذهب على الإطلاق. وجود بعض الأساليب غير قابلة للتغيير ( startOf ، add ) وبعضها ليس ( year ، get ) أمر محير فقط ، وسيتعين على المطورين تتبع أي منها.

كما أنني أفضل كل شيء ثابت بشكل افتراضي. هل الحروف ليست ثابتة بالفعل؟

فيما يلي المشكلات الكبيرة التي أراها مع التحول إلى الثبات.

الثبات الزائف

نظرًا لطبيعة جافا سكريبت ، فلن نتمكن أبدًا من امتلاك ثبات حقيقي.

أفضل ما يمكننا فعله هو إنشاء نسخة ثم تغييرها وإعادتها. يمكننا التفاف جميع الطرق العامة بعناية للتأكد من أننا نقوم دائمًا بالنسخ والتحول بدلاً من التحور فقط ، لكن هذا لا يمنع أي شخص من القيام بـ m._d = new Date() أو حتى m._d.setHours(1) .

أتفق مع icambron ، إذا انتقلنا إلى الثبات ، فيجب أن يكون تغييرًا كاملاً. أي طريقة يمكن أن تغير خاصية في لحظة ما ستنشئ بدلاً من ذلك نسخة من اللحظة وتجري تغييرًا على النسخة بدلاً من ذلك.

مساحة سطح Api

الشيء المؤسف في التحول إلى الثبات الزائف هو أن العديد من واجهات برمجة التطبيقات الجديدة يجب أن يتم إنشاؤها إذا كنا نريد الاستمرار في دعم قابلية التغيير.

في السابق ، كان التحول من تحويل لحظة إلى استنساخ وتحوير لحظة بسيطة مثل إضافة .clone() في المكان الصحيح. الآن ، سيتعين علينا إنشاء واجهات قابلة للتغيير لجميع أجهزة الضبط ، والتي تضيف بشكل كبير إلى مساحة سطح api.

يتضمن ذلك 20 طريقة setter ، إضافة / طرح ، و 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

أعتقد أن الاختبار الثاني هو تمثيل أفضل بكثير لخسائر الأداء عند التحول إلى الثبات الزائف. إذا قمنا بضرب هذه النتائج في 21 حالة استنساخ مذكورة أعلاه ، فإن أوقات التنفيذ تكون أبطأ بكثير.

أنا متأكد من أنه يمكننا تحسين المسار لاستنساخ لحظة ، لكننا سنحتاج إلى جعله أسرع بمقدار 50 ضعفًا للحصول على أداء مشابه. أنا متأكد من أن هذا مستحيل.

ملخص

التحول إلى الثبات يزيد بشكل كبير من تعقيد واجهات برمجة التطبيقات الداخلية والخارجية وله مشاكل كبيرة في الأداء والذاكرة. لا أعتقد أن هذه التكاليف تستحق الفوائد التي ستوفرها الثبات.

أعتقد أن مخاوف الأداء المدرجة هنا تفتقد إلى النقطة:

بشكل عام ، هناك حاجة إلى استنساخ أولي () لضمان الصحة قبل إجراء الطفرة.

لا يمكننا التظاهر بأن الاستنساخ () ليس مطلوبًا مع واجهة برمجة التطبيقات الحالية. الحالة الرئيسية التي تختلف هنا هي إجراء طفرات متسلسلة متعددة. تتم معالجة هذه الحالة من خلال إنشاء واجهة برمجة تطبيقات منشئ بحيث يتم تنفيذ جميع الطفرات كطفرات على نسخة واحدة.

هل أفتقد حالات الاستخدام الشائعة الأخرى؟

كانت مشكلتي الأصلية حول طرق startOf و endOf وجه التحديد. لسبب ما ، كانت هذه الأسماء بالنسبة لي مثل "اجعلني أبدأ بعد شهر" وليس "تعيين هذه اللحظة على بداية الشهر". تعتبر طرق مثل add و subtract جيدة تمامًا من حيث معنى الدلالات. من الجيد تمامًا إضافة شيء إلى كائن دون إنشاء كائن جديد.
بالنسبة لي شخصيًا ، فإن إعادة تسمية الطرق startOf و endOf إلى شيء مثل toStartOf و toEndOf (مثل "نقل هذه اللحظة إلى بداية الشهر") ستحل المشكلة مشكلة. برأيي المتواضع

gregwebs آسف ، كنت أعني set أعلاه.

أنا لا أتفق معsoswow ؛ أعتقد أنه يجب أن يكون متسقًا. في الواقع ، أعتقد أن toStartOf يدل على الثبات بقوة أكبر ، كما لو كان يقدم عرضًا تقديميًا بديلاً على غرار toISOString . والأهم من ذلك ، أعتقد أننا بحاجة إلى أن نكون قادرين على الإدلاء ببيانات مثل "لحظات تغير محددات اللحظات" أو "محددو اللحظات يعيدون نسخًا" ، وليس "حسنًا ، لهذه الأساليب ..."

حول اهتماماتtimrwood :

لا يزعجني حقيقة أن كائنات JS لن تكون ثابتة حقًا. النقطة المهمة هي أن API توفر عقدًا غير قابل للتغيير. بالطبع يمكن للمستخدم الغش من خلال العبث بالخصائص التي تم التأكيد عليها ، ويكون الغش ممكنًا بشكل عام حتى في اللغات التي يكون فيها الثبات هو الطريقة الرئيسية للقيام بالأشياء.

فيما يتعلق بمساحة السطح وحول الأداء: أعتقد أننا سنحتاج إلى استخدام الطفرات داخليًا لتجنب استخدام كل وحدة المعالجة المركزية والذاكرة [1] ، لذلك سيتعين علينا بعد ذلك دعمها على مستوى ما. ثم قد نعرضها أيضًا خارجيًا ، مثل setYear() ، إلخ. هذا يضيف مجموعة من مساحة السطح ، لكنه لا يضيف الكثير من التعقيد ؛ بالنسبة للطفرات غير الصريحة ، استنساخ خارجيًا ، تحور داخليًا.

تتمثل إحدى طرق النظر إلى ذلك في أنه يتعين على المستخدم استنساخ التعليمات البرمجية الخاصة به ، لذلك قد يكون تطبيق Moment مفيدًا لهم أيضًا. هذا يمثل مشكلة في التسلسل في الأماكن الحساسة للأداء ، والتي يمكن محاربتها إما بواجهة منشئ (حسب فكرة جريج) أو عن طريق السماح للمستخدم فقط باستخدام الطفرات هناك. يضيف المنشئ تعقيدًا مجموعة [2] ، لذلك أعتقد أنني أفضل البدائل الصريحة للطفرات. أعتقد أن الحقيقة هي أنه في معظم الأوقات ، لا يتم استخدام Moment في المواقف الحساسة للأداء ، لذلك لا يجب أن تكون هذه المواقف هي الأكثر ملاءمة من حيث واجهة برمجة التطبيقات. أفضل أن يكون لدي واجهة برمجة تطبيقات لطيفة غير قابلة للتغيير مع فتحة مثالية عندما أحتاج إليها.

[1] الأطفال الرائعون في FP land يحلون هذه المشكلة من خلال "المشاركة الهيكلية" ، ولكن ربما يكون هذا غير عملي هنا.

[2] بشكل تقليدي ، يصنع الناس بناة عبارة عن كائنات منفصلة ، ولكن هذا سيكون مطولًا حقًا هنا ، حيث سيتعين عليك نسخ واجهة برمجة تطبيقات الإعداد بالكامل. مجرد spitballing ، ولكن أحد البدائل هو أن .chain() يخلق لحظة استنساخ تحتوي فقط على علامة isBuilding تعيينها عليها. ثم يتم تجاهل المستنسخات الداخلية ، ما عليك سوى إرجاع الكائن للطفرة. ثم يقوم build() بإلغاء تعيين العلم وإرجاع تلك النسخة. تكمن المشكلة في أنك بحاجة إلى أن يصرخ الحاصلون على القتل الدموي إذا تم وضع العلم ، أو سينتهي الأمر بالناس باستخدام اللحظات المقيدة بالسلاسل ولكن غير المكتملة والتي يتم تغييرها فجأة. ثم تحتاج إلى التفريق بين الخارج والداخلي يسمى الحاصل. بليتش. بديل آخر هو تحليل الوظيفة التي يحتاجها المنشئ داخليًا إلى مزيج واستخدامه في كل من المنشئ وفي Moment ، ولكن ربما لا يكون هذا عمليًا من منظور تنظيم الكود.

ما نجح معي ، هو إضافة معلمة إضافية إلى الوظائف ، وعلم (أطلق عليه اسم self) للإشارة إلى قابلية التغيير ، بشكل افتراضي غير قابل للتغيير (إرجاع نسخة أو كائن جديد) ، وعندما أكتشف الأداء ، أضبط العلامة على true

حلت وجهة النظر هذه الكثير من النزاعات ،
لها وظائف ذات اسم مشابه تنفذ نفس الكود تقريبًا ،
أو الاضطرار إلى تغيير اسم الوظيفة وربما المعلمات عندما أكتشف نقاط الأداء
في أساليبي العامة ، أبدأ الكود باستدعاء الوظائف بنسخة واتباع المكالمات التي تحمل العلامة في صواب
مع هذا يمكنني أيضًا ربط الوظائف

في الكود الخاص بي ، أعمل مع مصفوفات ، (مثل جدول ، صفيف من الصفوف)
لذلك لدي وظائف للتصفية ، والتوحيد ، وما إلى ذلك ، والتي تعيد تشغيل مصفوفة جديدة مسبقًا بالنتيجة ، واكتشفت ذلك للحصول على النتيجة النهائية التي اتصلت بها عدة مرات بنفس الوظيفة ، والآن أول مكالمة هي إنشاء نسخة وليس تغيير المصفوفة الأولية ، والمكالمات التالية أعمل مع نفس صف إسقاط الصفيف الذي لا أحتاجه

مثال أساسي يمكن أن يكون هنا:
لحظة.إضافة = وظيفة (قياس ، مقدار ، ذاتي) {
}

لحظة.إضافة = وظيفة (قياس ، مقدار ، ذاتي) {
var $ moment = self؟ هذا: this.clone () ؛
// الكود الفعلي
عودة $ لحظة؛
}

شكرا لكم جميعا على سنتهم 2 :)

بالنسبة للبروتوكول ، أوافق على آخر مشاركة لـ icambron في جميع النقاط.

هناك سؤالان كبيران متبقيان.

الأسهل هو ما يجب أن تكون عليه واجهة برمجة التطبيقات الجديدة ، خياران:
1.1 طرق ذات أسماء مختلفة (قابلة للتغيير وغير قابلة للتغيير) year / setYear ، startOf / setStartOf
1.2 أو builder api chain().mutators().build() ، وهي النسخة غير المخترقة لما اقترحه

يبدو منشئ واجهة برمجة التطبيقات أكثر جنسية بالتأكيد ، ولكن يجب الحرص على عدم بقاء الكائنات في وضع البناء لفترة طويلة ، مما يضيف مصدرًا آخر للمشاكل لنا وللمستخدمين.

الآن المشكلة الصعبة - الانتقال إلى الإصدار الجديد. أرى خيارين هنا:
يجب على المطورين 2.1 إعادة كتابة التعليمات البرمجية الخاصة بهم (قد يعمل التعبير العادي المجنون في 1.1 وحل على مستوى AST لـ 1.2 - نظرًا لعدم استخدام أي شخص year و month كأسماء للطرق الخاصة بهم). اتبع بيثون هذا النهج - يمكننا جميعًا رؤية النتيجة - ولدت لغة جديدة تمامًا!
2.2 خيار لتشغيل Builder api دائمًا (كما هو الحال الآن) ، وطريقة لإلغاء تنشيطه للحصول على رمز جديد. يبدو هذا ثوريًا بدرجة أكبر ، لكن مقدار الارتباك الذي قد يسببه ربما لا يستحق كل هذا العناء. كل لحظة لها علمان: هل هي قابلة للتغيير ، وفي حال كانت كذلك - هل هي قابلة للتغيير بشكل صارم (بدون حاصل) أم قابلة للتغيير انتقاليًا (الحصول على موافق). ناهيك عن تلقي كائنات اللحظة في الوظائف - يجب عليك التحقق من الوضع ، والتأكد من صيانته ... يا لها من فوضى!

والآن جاءتني فكرة مجنونة الآن

استنساخ النسخ عند الكتابة

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

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

لست متأكدًا من المقدار الذي يمكن حلقه باستخدام هذا النهج ، نظرًا لأن الحالات اللحظية خفيفة جدًا. كما يتعين على جميع المتحولين الآن إجراء فحص.

هناك عدة طرق للتنفيذ بأداء متفاوت في سيناريوهات مختلفة. والخبر السار هو أنه متوافق مع الإصدارات السابقة وسنوفر علينا وعلى مستخدمينا قدرًا كبيرًا من الجهد. وأعتقد أن هذا أهم من إعادة اختراع العجلة.

لست متأكدًا مما نكسبه هنا.

التحول إلى نظام الثبات له الكثير من التكاليف المرتبطة به وربما أفتقده ، لكن
لا أرى فوائد مماثلة حقًا.

يبدو أن الفوائد الرئيسية هي تفضيل المطور. هل هذا كل شيء بحيث لا يمتلكه المطورون
للتفكير في ملكية اللحظة عند تمريرها؟

لا أعتقد أن التحول إلى الثبات سيجعل الأخطاء أقل تكرارًا ، بل ستفعل ذلك
تغيير نوع الخلل. يُظهر مثال
السطح ، والتي يصعب تعقبها.

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 () الحالية ، يتم دعم الثبات |
| | ترتيب حجم أسرع |
| | يستخدم ذاكرة أقل بشكل ملحوظ |

أعتقد أن الثبات مفيد ، لكنني لا أعتقد أنه مناسب تمامًا لجافا سكريبت. أعتقد أن الواجهة غير القابلة للتغيير قد تكون منطقية بالنسبة للغة مثل Elm ، حيث يُتوقع الثبات ، ولكن بالنسبة لجافا سكريبت ، أعتقد أن التغيير متوقع.

الكثير من واجهات برمجة التطبيقات لـ typeof a === "object" المدمجة قابلة للتغيير. Array#push,pop,reverse,sort,shift,splice,unshift بتغيير محتويات المصفوفة بدلاً من إرجاع مصفوفة جديدة. جميع طرق Date#setX 16 تغير مثيلها.

أعتقد أننا نرى الكثير من الناس يشكون من أن اللحظات قابلة للتغيير ، ولكن إذا قمنا بالتبديل ، أعتقد أنه سيكون لدينا نفس العدد من الأشخاص الذين يشكون. لقد حدث هذا eod/sod منذ عامين.

بعد النظر في مجموعة من المشكلات القديمة حول قابلية التغيير ، أعتقد أنني ربما أبدو كسجل مكسور هنا. على كلا الجانبين ، إنها نفس النقاط التي أثيرت في السنوات القليلة الماضية. أردت فقط التأكد من تمثيل حجة الاحتفاظ بواجهة برمجة تطبيقات قابلة للتغيير في المناقشة.

timrwood هذه مقارنات جيدة ، لكن من الواضح أنك لم تأخذ الوقت الكافي لفهم حالة الاستخدام غير القابل للتغيير. لقد ناقشنا بالفعل لماذا تفترض مقارنات الأداء التي نشرتها أن واجهة برمجة التطبيقات (API) سيئة التنفيذ وغير منطقية.

مقارنة الخطأ غير صالحة أيضًا. نظرًا لأن Momjs تدعم واجهة برمجة تطبيقات متسلسلة ، يمكن للمرء أن يتوقع أن تكون غير قابلة للتغيير.

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

لذا فإن كلا من الثابت وغير القابل للتغيير لديهما نفس المشكلة الآن. يمكنك تجنبه مع الإصدار الحالي القابل للتغيير إذا تخلصت من واجهة برمجة التطبيقات المتسلسلة.

لذا فإن واجهة برمجة التطبيقات غير القابلة للتغيير هي أفضل من قابلة للتغيير لأنه يمكنك تمرير لحظة بين الوظائف بأمان. مع اللحظات المتغيرة الحالية ، إذا مررت لحظة بين الوظيفة ، فلدي خياران

1) طريقة عربات التي تجرها الدواب المجنونة (ربما تكون الأكثر شيوعًا): تحقق من جميع التعليمات البرمجية المصدر للتأكد من عدم وجود طفرات غير مرغوب فيها. اكتب اختبارات الوحدة للتأكد من عدم تسلل الطفرات غير المرغوب فيها.
2) الطريقة العاقلة (لنفترض بدلاً من ذلك أن الجميع يفعل ذلك) ، البرمجة الدفاعية: تذكر استدعاء وظيفة clone () قبل التحول في وظيفتي.

باستخدام واجهة برمجة التطبيقات غير القابلة للتغيير ، لا يتعين علينا تذكر استدعاء clone () في كل مرة. بدلاً من ذلك ، علينا أن نتذكر استدعاء وظيفة API التي تتيح لنا تجنب الاستنساخ ، ولكن هذا مجرد تحسين للأداء ، وليس مسألة صحة.

من الواضح أنك لم تأخذ الوقت الكافي لفهم حالة الاستخدام غير القابلة للتغيير

هذا بيان غير عادل. حجتي هي أنني أرى الفوائد ، لكن لا أعتقد أنها تفوق التكاليف.

يمكنك تمرير لحظة بأمان بين الوظائف

لا يتعين علينا أن نتذكر استدعاء استنساخ

أليس هذا هو حالة الاستخدام للثبات؟ إذا كان هناك المزيد مما لم أستغل الوقت لفهمه ، فيرجى إبلاغي بذلك ، ولكن يبدو أن هذه هي الحجة الوحيدة في السنوات القليلة الماضية.

timrwood نعم ، هذا هو الحال برمتها.

لكنني لا أرى إشارة منك تعترف بأن حالتك _ ضد_ الثبات (الأداء الرهيب ، يروج لنوع مختلف من الأخطاء غير موجود في واجهة برمجة التطبيقات القابلة للتغيير) غير صالحة.

لا أعرف ما إذا كان التجميد () يمكن أن يساعد
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze

أعتقد أننا يجب أن نلتزم بوجهة نظر ecmascript 5 ، وربما نضيف وظيفة تعمل على تجميد الكائن الحالي بعمق ، أو علامة عامة تقوم تلقائيًا بإنشاء كائنات frezee

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

ربما معلمة إضافية في المُنشئ لإنشاء كائن تجميد ، لأن كائن التجميد لا يمكن إلغاء تجميده

lfnavess فكرت في freeze قبل ذكر النسخة عند الكتابة. المشكلة هي أنه ... لا أحد يستخدمه / يعرف عنه ، ولا يساعد عندما لا يطرح استثناء (في الوضع غير المقيد) - إنه في الواقع يخلق أخطاء مجنونة لتتبعها.

timrwood لا أعتقد أنني أوضحت المثال الخاص بي. في السطر m.year(2014) // clone here كنت أعني أن اللحظة الداخلية ستعمل في الواقع على استنساخ (تخصيص المزيد من الذاكرة) وستشير m إلى تلك الذاكرة الجديدة تلقائيًا. حسنًا ، هذا يعني بشكل أساسي أن clone() يجب أن يخصص أيضًا القليل من ذاكرة shell (شيء يشير إلى تمثيل التاريخ الداخلي) ، لست متأكدًا من المبلغ الذي سيتم ربحه من خلال القيام بذلك.

إنشاء إصدار نصف مؤكد من clone ، يستنسخ الواجهة فقط ، والقدرة على تغيير البيانات الأساسية (من التخزين المشترك إلى خاص بالمثيل) - إنه يعتمد حقًا على مدى تكلفة كائنات التاريخ. الجانب السلبي هو أن كل وظيفة تحتاج إلى this._storage._d بدلاً من this._d ، ولست متأكدًا مما إذا كان ذلك سيتغلب على الفائدة.

لم أحصل على أي تعليقات حول كيفية التعامل مع ترحيل المكتبات الحالية / المستخدمين الحاليين. لا أحب حقًا أيًا من الخيارات المذكورة أعلاه.

التوافق العكسي ، IMO ، هو أقوى حجة ضد هذا. إذا فعلنا هذا ، علينا فقط أن نقبل أنه تغيير كبير. إذا كنا لا نريد قبول ذلك ، فلا يجب أن نفعله.

من الجدير بالذكر إعادة: perf أن هناك أيضًا بعض المزايا الهائلة التي يمكنك الحصول عليها من الثبات ؛ إنها ليست ضربة أداء رتيبة. على سبيل المثال ، يمكنك تخزين الأشياء مؤقتًا على مستوى الكائن ، لأنها لن تتغير أبدًا. أعتقد أيضًا أننا يجب أن نكون قادرين على تحسين حماقة المعيشة من clone() ؛ AFAIK يتضمن استنساخ تاريخ ونسخ مثل خمس قيم ؛ أعتقد أنه يجب علينا فقط ترميزهم بشكل ثابت مثل newThing._offset = oldThing._offset .

تحرير ، arg ، لا - الإضافات تضيف الحقول أيضًا (على سبيل المثال هنا ).

نظرًا للرغبة القوية في التوافق مع الإصدارات السابقة مع الاحتفاظ بالشيء خفيف الوزن ، أعتقد أن أفضل حل هو تفرع مصادر جافا سكريبت (إما في مصادر هذا المشروع أو بدء مشروع جديد تمامًا). يوجد متسع لأكثر من مكتبة زمنية للإنترنت.

أيضًا: إعادة: فكرة ichernev حول المشاركة الهيكلية ، تتمثل إحدى الاحتمالات في استخدام وراثة النموذج الأولي بدلاً من تغليف كائن حالة مشترك.

لقد كنا في WhoopInc كامنين في هذه المناقشة لفترة طويلة. نظرًا لأن المناقشة هنا تبدو وكأنها تدور في دوائر ، فقد استغرقت بعض الوقت في نهاية هذا الأسبوع لاستكشاف الشكل الذي قد تبدو عليه نسخة غير قابلة للتغيير مع واجهة برمجة تطبيقات منشئ. (ليس لدي أي نية لتقديم العلاقات العامة مقابل لحظة ما لم تتم دعوتي للقيام بذلك ، حيث إنني أقوم عمدًا بإجراء تغييرات أكثر صرامة في واجهة برمجة التطبيقات مما أتوقع أن أراه مطبقًا في اللحظة نفسها.) وإليك النتيجة: https: // github. كوم / WhoopInc / لحظة مجمدة

أنا فقط بضع ساعات ، لذلك كل شيء صعب للغاية حول الحواف ، ولكن بناءً على نتائج الاختبار ، أعتقد أن معظم وظائف اللحظة الأساسية تعمل. سأستمر في تتبع هذه المحادثة ، وسأرحب بالملاحظات الخاصة بالشوكة في مشكلات الريبو.

سأحاول نشر بعض المستندات المحدّثة على هذا الريبو الليلة ، لكنني في الأساس قسمت كل أساليب الضبط والطفرة إلى كائن منشئ منفصل. لذلك قد يبدو استخدام واجهة برمجة التطبيقات مثل frozenMoment("2014-07-21").thaw().subtract(1, "day").startOf("day").freeze().format("YYYY-MM-DD") . (على الرغم من أنه في هذا المثال بالذات ، سيكون من الأفضل أن تبدأ السلسلة باستخدام منشئ بدلاً من تهيئة مُنشئ من لحظة مجمدة ، باستخدام frozenMoment.build("2014-07-21").subtract... )

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 مذهل.

+1 لثبات 100٪.

إنه بصراحة نوع من الإحباط لأنه لا يكون ثابتًا.

+1 لثبات 100٪ في الإصدار 3

يجب أن يكون هناك بالتأكيد واجهة برمجة تطبيقات ثابتة. كمستخدم المكتبات تاريخ الأخرى (وخاصة، وصافي DateTime وJoda الوقت / نودا الوقت)، وأتوقع أن حدسي و add الطريقة لن يتحول الكائن التاريخ.

+1 للثبات

+1 لثبات 100٪

إذا تم اتخاذ القرار من أجل الثبات ، فسأكون على استعداد لإعطاء وقتي لتحقيق ذلك. ربما يتم الاقتران عبر مكالمة فيديو. أرغب في المساهمة أكثر في المصادر المفتوحة ولكني بحاجة إلى تعلم الحبال.

بالنسبة لي ، الثبات هو الأفضل ، لكن كان يجب أن يتم ذلك من البداية. هذا تغيير جذري. سيكون مفترق هذا المشروع الذي يركز على الثبات فكرة أفضل.

dsherret هذا ما هو سمفر . كنا فقط نتعثر في الإصدار الرئيسي.

ومع ذلك ، مع بعض الجهد يمكن تقديمه كخيار تكوين: "هل تريد كل شيء غير قابل للتغيير؟ صحيح أم خطأ". سيكون الافتراضي خطأ.

المكوّن الإضافي غير الرسمي ymmv غير القابل للتغيير هنا: https://gist.github.com/timrwood/fcd0925bb779f4374a7c

هاها! لقد فوجئت بالمجيء إلى هنا في وقت لاحق واكتشفت أنني كنت من أوائل المؤيدين لواجهة برمجة تطبيقات أكثر ثباتًا .. :)

ونعم أنا +1 للثبات للإصدار الرئيسي التالي.

+1 آخر للحظة غير قابلة للتغيير افتراضيًا مني.
وإليك طريقة تحضير "Imoment" الخاصة بي: https://gist.github.com/idrm/a91dc7a4cfb381dca24e (استخدمه على مسؤوليتك الخاصة!). فقط استبدل مكالماتك اللحظية () بـ imoment () وهذا يجب أن يكون كافيًا. يجب أن تظل جميع استدعاءات الوظائف الثابتة للحظات. xyz () (على سبيل المثال ، min () ، و

+ 1 مليون دولار

+1 للثبات

هل يمكنني أيضًا إضافة +1 إلى اقتراح سابق من سلسلة المناقشة هذه لإعادة تسمية بعض الوظائف حتى يسهل قراءتها ("startOf" إلى "toStartOf" ، و "add" to "plus" ، و "month" to "withMonth "، إلخ.)؟ أي ، بافتراض أنك تأخذ المسار الثابت الافتراضي. أستخدم Joda Time كثيرًا ، ومن السهل معرفة ما يعنيه ، على سبيل المثال ، "date.withDayOfMonth (1) .withDayOfWeek (DateTimeConstants.MONDAY)".
لا يجب أن تكون هذه في التوزيعة الرئيسية JS أيضًا ؛ ستعمل الوظيفة الإضافية التي تصفعها فوق Vanilla JS أيضًا (حسنًا ، أنا أفكر بشدة في كتابة مثل هذه الوظيفة الإضافية المحاذاة لوقت Joda بنفسي لدمجها مع نموذج "Imoment" الخاص بي).

ichernev ، icambron ، هل اتخذت قرارًا بهذا الشأن؟ هل ستكون اللحظات ثابتة في 3.0؟ إذا كان الأمر كذلك: متى تتوقع أن يخرج 3.0؟ أنا أسأل لأنني أفكر في استخدام لحظة مجمدة أو كتابة غلاف صغير بنفسي - وأتساءل عما إذا كان علي الانتظار.

لمعلوماتك ، كانت اللحظة المجمدة في الغالب في نمط الانتظار مؤخرًا - لقد قمت بنقل مجموعة من العلاقات العامة من لحظة المنبع ، لكنني لم أعمل حقًا على أي من عمليات إعادة البناء الأخرى التي يجب أن تحدث بشكل مثالي في تلك الشوكة.

ومع ذلك ، يجب أن تعمل اللحظة المجمدة بشكل رائع إذا كنت تحتاج فقط إلى اللغة الإنجليزية الافتراضية. (كل شيء يعمل مع حالات الاستخدام الخاصة بي ، وقد حافظت على تغطية اختبار الوحدة العالية لـ Moment.) تعطلت اللغات غير الإنجليزية لأنني لم أقم بتحديثها بعد نقل واجهات برمجة التطبيقات المحلية الخاصة بـ Moment التي أعيد تشكيلها مؤخرًا.

بمجرد أن نتخذ قرارًا بشأن Moment 3.0 ، سأخطط للعمل بجدية أكبر قليلاً على عمل الثبات في Moment ، أو على مفترق اللحظة المجمدة ، حسب الاقتضاء. سيكون هدفي الأولي هو إصلاح الدعم المحلي والحفاظ على تكافؤ الميزات مع واجهة برمجة تطبيقات Moment 3.0.

+1 للثبات

+1 للثبات. ماذا عن طريقة format التي تغير الكائن أيضًا؟

+1 للحظة ثابتة. js
أو ربما مفترق لحظة. js؟ ثابت لحظة. js؟ لأن هذا سيكون بالتأكيد تغيير جذري.

: 100:
افعل المقتنيات!

1+ الثبات في هذه الأيام هو شيء أتوقعه في أي JS API جيد

: +1: نعم من فضلك ، نود كثيرا هذا. حاليا نحن نرش .clone () في كل مكان.

+1 سيكون هذا تحسينًا رائعًا جدًا

: +1: كل الأشياء غير قابلة للتغيير

+1 ثابت

اجعل كل شيء غير قابل للتغيير. لقد سئمت من استنساخ كل لحظة (الآن) متغير قبل أن أعمل على متغير الآن ثم الآن يتغير مرة أخرى.

+1 للثبات

لم أكن أتوقع أن يتغير startOf('day') (على الرغم من أنني سأعترف بأنه موثق جيدًا إذا كنت قد قرأت بعناية أكبر). تسبب ذلك في خطأ ممتع في طلبي.

أنا أتفق بالتأكيد على أن معظم مشغلي moment.js محرجون في قابليتهم للتغيير. mmnt.startOf('day') هو مضاد بديهي للغاية لأنه يغير mmnt .

أستخدم Mom.js لحالات استخدام نوع التقويم مع العديد من الحلقات ومقارنات التواريخ. لقد واجهت مشاكل الأداء مع clone() وهي فظيعة. إن امتلاك قدر من التحكم في ما هو مستنسخ وما يتحول هو أمر ضروري بالنسبة لي وربما للآخرين.
على الرغم من أن الحصول على clone() كل مكان يبدو محرجًا في البداية ، إلا أن ما يفعله واضح تمامًا ويجعل إعادة البناء من أجل الأداء أمرًا سهلاً للغاية بالنسبة لي.

إذا بدأت كل طريقة بشكل أعمى باستخدام clone() داخليًا من أجل الحصول على واجهة برمجة تطبيقات أفضل ، أعتقد أننا قد فاتنا هذه النقطة.

بلدي 2 ¢ :-)

jdurand أنا أفضل أن

dsherret لا أمانع صراحة في أي شيء. قلقي الرئيسي هو عدم الاستنساخ ضمنيًا لأنه عملية مكلفة للغاية.
ذكر أحدهم أن المستوطنين سيحتاجون إلى إعادة نسخة مستنسخة وهذا أخافني ؛ سيكون غير فعال للغاية.

jdurand قد يكون أكثر

Sidenote: مع هذا التغيير ، أعتقد أنه يمكن إجراء بعض التحسينات في الأداء على الرغم من ... على سبيل المثال ، يمكن القضاء على الاستنساخ من خلال الرجوع بدلاً من ذلك إلى الكائن السابق غير القابل للتغيير ثم تخزين العملية التي سيتم إجراؤها لهذا الكائن (على سبيل المثال add(1, 'days') ). لن يتم حساب النتيجة بعد ذلك إلا عن طريق تنفيذ العمليات عندما يتم استدعاء شيء مثل .toString() ، .format() ، .toDate() ، .day() ، إلخ .... سيكون هذا تغييرًا جذريًا وقد لا ينتهي به الأمر إلى أن يكون أسرع ... يجب إجراء بعض اختبارات الوحدة لمقارنة الأداء (بالإضافة إلى ذلك ، قد تكون هناك مشكلات أخرى لم أفكر فيها لأنني لم ألقي نظرة على أي رمز مطلقًا in moment.js بخلاف كيفية استنساخه).

dsherret أحب أسلوب _builder _ / _ lazy_ ؛ بعد فوات الأوان ، ربما كان من المفترض أن يتم بناؤه على هذا النحو من البداية.
كما قلت ، أعتقد أن الشوكة غير القابلة للتغيير مع مراعاة توافق واجهة برمجة التطبيقات ستكون الأفضل.

2 سنتات أخرى:

1. هل يجب أن نشعر بالقلق حقًا بشأن الأداء ، عندما تكون اللحظة مبنية بوضوح للراحة بدلاً من الأداء؟ أعتقد أن تحليل "السنة" في m.add ("السنة" ، 1) أبطأ بكثير من الاستنساخ.
2. ما لم يكن هناك شوكة كاملة (اسم مختلف ، مستند مختلف) ، فسيكون من الصعب الحفاظ على نسختين. أعتقد أن شخصًا ما ذكيًا يجب أن يأتي بفكرة لتوليد time.immutable.min.js و moment.min.js من نفس قاعدة الشفرة ...

منذ متى نخشى تغيير التغييرات؟ الإصدار الحالي مستقر ولا يزال بإمكان الأشخاص استخدامه دون إعادة هيكلة قاعدة التعليمات البرمجية الخاصة بهم.

يعد الحفاظ على قاعدتي أكواد أمرًا مزعجًا ، ويبطئ من سرعتك ولا يستحق حقًا أن يكون لديك نسخة قابلة للتغيير / غير قابلة للتغيير.

لذلك دعونا نذهب مع لحظة غير قابلة للتغيير تمامًا ، ونطرح النسخة الرئيسية وننتهي منها: الراقصون:

وجدت هذا الموضوع لأنني بدأت للتو في استخدام هذه المكتبة ولكني كنت أقوم بإخراج شعري من تصحيح بعض التعليمات البرمجية والتعامل مع ما يبدو لي أنه آثار جانبية لا يمكن التنبؤ بها لكوني قابلة للتغيير. أحب أن أرى نسخة كاملة من المكتبة غير قابلة للتغيير!

المكونات الوقحة: لقد تعبت من انتظار قرار حازم هنا. خلال الأيام القليلة الماضية ، قمت بإحياء Frozen Moment وأعدت كتابتها لتكون بمثابة مكون إضافي لـ Moment نفسها. نصيحة القبعة إلى wyantb لمساعدتي في إنجاز أول إصدار للمعاينة خلال عطلة نهاية الأسبوع.

يوفر Frozen Moment نوعًا غير قابل للتغيير يعمل تمامًا مثل Moment. بشكل أساسي ، يلف الإصدار غير القابل للتغيير وظائف Moment ويستدعي .clone() عندما يكون ذلك مناسبًا.

بالنسبة لأولئك الذين يحبون واجهات برمجة التطبيقات الخاصة بالبناء ، أود أن أتحداك أن تفكر في Moment نفسها كتطبيق جيد جدًا لكائن منشئ! يضيف Frozen Moment النوع الأساسي غير القابل للتغيير الذي نريده جميعًا ، وآلية لبناء لحظة مجمدة ثابتة من لحظة قابلة للتغيير.

بالنسبة لأولئك الذين يرغبون فقط في العمل باستخدام واجهة برمجة تطبيقات ملائمة غير قابلة للتغيير - حسنًا ، أعتزم دعم ذلك أيضًا. لم أقم ببناء مُنشئ يقوم ببناء مثيل Frozen بشكل مباشر حتى الآن ، ولكن هذا موجود في قائمة TODO . على المدى القصير ، يتمثل الحل في إنشاء كل شيء باستخدام moment().freeze() أو moment.utc().freeze() .

من الواضح أن Frozen Moment هي قاعدة بيانات صغيرة ، لذلك من المحتمل أن تكون هناك بعض الحواف الخشنة - لكنني أشجع أي شخص هنا على تجربتها وتقديم المشكلات لأي شيء لا يعمل بالطريقة التي تتوقعها.

أوه ، هناك شيء آخر: أنا لا أعلن عن هذا حتى الآن ، ولكن يجب أن تعمل حالات Frozen Moment "فقط" مع معظم مكونات Moment الإضافية. فقط تأكد من أن جميع ملحقات Moment الأخرى تسجل نفسها قبل Frozen Moment. إذا وجدت مكونًا إضافيًا لا يعمل كما هو متوقع مع لحظات مجمدة ثابتة ، فأبلغ عن خطأ وسأبحث فيه.

+1 على الثبات

+1 ثابت

هل نظر أي شخص إلى لحظة التنفيذ أعلى JS غير القابل للتغيير ؟ إنها مكتبة محسّنة للثبات في JS ، فهي تعيد استخدام الأجزاء غير المتغيرة من كائن غير قابل للتغيير ، مما يقلل من مخاوف الذاكرة.

+1
لقد أصلحت للتو خطأ عمره 3 سنوات بسبب هذا: https://github.com/Saleslogix/argos-saleslogix/commit/87b35b22c1a42670da369701b15e2bdb3786cabc

إذن المستخدمون يطلبون الثبات ولكن الفريق الأساسي يجد أعذارًا لعدم القيام بذلك؟ : ص
هيا يا رفاق ، هذا التغيير أكثر أهمية من إعادة كتابة الكود في ES6 ^ ^ في شكله الحالي ، فإن API سيئة ببساطة ، مثل JS Array حيث بعض الطرق غير قابلة للتغيير (مرشح ، concat ، إلخ) ولكن بعضها البعض الآخر ليس (عكسي ، فرز) باستثناء أن قيود التوافق مع الإصدارات السابقة أعلى بشكل لا نهائي من المكتبة.

+1

الفخ الصغير الذي يصيبني دائمًا (و IMHO هذا سبب وجيه للثبات):

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 إلى إحداث ألم في ** s للحفاظ على تواريخ الاستنساخ لتجنب تعديل التواريخ الحالية.

+1 لثباته ، كلفني هذا بضع ساعات فقط.

: +1:

+1 للثبات

أنا ممزق قليلاً بشأن هذا الموضوع.

الأصولي بداخلي يريد أن يصرخ "+1 من أجل الثبات! من الواضح أن كائنات اللحظة هي من نوع ValueObject ."

ومع ذلك ، لا يمكننا تجاهل هذه اللحظة. js هي النسخة الثالثة عشر الأكثر شيوعًا من ملفات جافا سكريبت على GitHub ( والرابعة والعشرون من جميع النواحي) ، وهذا البحث عن "لحظة" على bower.io يُرجع 111 نتيجة متطابقة. حتى لو تمكنا من تزويد بناة التطبيقات بطريقة تدريجية لتنفيذ إصدار ثابت من اللحظة ، فسوف يتسبب ذلك في فوضى كبيرة بين تبعياتها.

ichernev ربما يكون اقتراحًا أكثر تواضعًا: هل من الممكن تخصيص جزء صغير من صفحة توثيق اللحظة للحديث عن

في الوقت الحالي ، لا تذكر صفحة التوثيق مصطلح "ثابت". يأخذك البحث عن "لحظة غير قابلة للتغيير" في Google إلى هذه الصفحة ، لكن الأمر استغرق ساعتين في القراءة وما زلت غير متأكد من موقفك الحالي بشأن هذا الموضوع. سيكون من الرائع أن تقدم أفضل نتيجة لـ "لحظة غير قابلة للتغيير" من Google إجابة سريعة عن مستقبل الثبات في الوقت الحالي :)

اقتبس من @ jehoshua02 :
"أنا أتعاطف مع أن هذا قرار صعب اتخاذه. أنا أقدر عملك. Moment.js مذهل."

هذا هو اقتراحي. بدلاً من جعل اللحظة الأساسية غير قابلة للتغيير ، أضف مصنعًا moment.immutable . ستكون خاصية للوظيفة moment وستتضمن نفس توقيع API الدقيق مثل moment ، لكنه غير قابل للتغيير.

يمكن أن يكون مجرد امتداد نموذج أولي لمصنع moment القابل للتغيير ، باستخدام وظائف هذا النموذج الأولي ، ولكن الاستنساخ بدلاً من ذلك.

تحرير: يبدو أن WhoopInc / التجمد هو بالضبط ما أبحث عنه.

التغييرات الفاصلة في thomasvanlankveld هي سبب استخدام أرقام الإصدارات الرئيسية. أي شخص يستخدم Bower و npm سيكون لديه خيار التمسك برقم الإصدار الرئيسي الحالي ؛ لا ينبغي أن نقلق بشأن التوافق مع الإصدارات السابقة هنا - ربما باستثناء هؤلاء الأشخاص الذين يقدمون هذا فقط من CDN. ولكن إذا كانوا يستخدمون Momjs من CDN ، فمن المحتمل أنهم ليسوا مهتمين بتحديث المكتبة من وقت لآخر على أي حال.

أود أن أزعم أن وجود الثبات في الإصدار الرئيسي التالي - أو النسخة الرئيسية بعد ذلك - يجب أن يكون على خريطة الطريق.

لذا يبدو أنني واجهت هذه المشكلة أيضًا.

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

لذلك أنا مع الثبات في جميع المجالات.

+1 لثباتها

لقد فقدت للتو أمسية بسبب هذا السلوك المفاجئ وغير المتوقع.
+1 آخر للثبات مع تغيير الإصدار الرئيسي المقابل لتوضيح ذلك.

+1 لثباتها

+1 لثبات كامل.
يجب أن يكون المقدار الجماعي للساعات الضائعة بسبب "أحيانًا قابلة للتغيير ، وأحيانًا غير قابل للتغيير" كبيرًا جدًا.

نعم أعني بجدية. من يهتم بالأداء في مكتبة التاريخ والوقت؟ شبه حقيقى؟ أعتقد أن 99.9٪ من المستخدمين لا يفعلون أي شيء يتطلب أداءً جيدًا حتى عن بُعد. عادةً ما تتعامل مع عدة تواريخ ، أو في أسوأ الأحوال بضع مئات. يمكن للمستخدمين القلائل الذين يتعاملون مع ملايين التواريخ في الثانية استخدام نقاط واجهة برمجة تطبيقات محسّنة قابلة للتغيير.

الثبات هو خيار التصميم العقلاني الوحيد. هناك العديد من الدراسات التي تُظهر أن البرمجة بأنواع غير قابلة للتغيير تكون أقل عرضة للإصابة بالأخطاء مقارنة بالأنواع القابلة للتغيير.

+1 للثبات. كلفني هذا بضع ساعات.

جزء من المشكلة هو أن أسماء الطرق مثل .startOf() لا تعني تغيير الكائن الأساسي.

لقد واجهت اختناقات في الأداء مع Moment ، لذا يمكنني أن أؤكد لكم أن هذا يمكن أن يحدث في بعض الأحيان.

ومع ذلك ، لست مقتنعًا بأن اللحظات غير القابلة للتغيير ستكون بطبيعتها أقل كفاءة ، ويمكن أن تتخيل بعض الحالات التي تكون فيها أكثر كفاءة.

تمت تسوية هذا النقاش منذ وقت طويل في عالم جافا. فازت التواريخ الثابتة ، وأصبح التطبيق الأكثر شيوعًا (JodaTime) في النهاية جزءًا من المكتبة القياسية في Java 8.

كان العمل مع Java 8's LocalTime واحدًا من تلك الصفعة على جبهتك "لماذا لم نفعل هذا دائمًا؟" لحظات. نادرًا ما أبشر التقنيات ، لكنني بصراحة لا أرى أي ارتفاعات في كائنات التاريخ القابلة للتغيير.

لذا ، نعم .... أكره أن هذه الخيوط تغمرها إجراءات +1 ، لكن حقيقة الأمر هي أن شخصًا آخر سينشئ مكتبة تاريخ JS ثابتة إذا لم يكن Moment لا.

لقد عثرت مؤخرًا على وحدة npm جديدة تهدف إلى نقل جزء كبير من JodaTime API (أي تواريخ Java 8) إلى JS.

سيؤدي ذلك إلى جلب أشياء مثل الثبات و LocalDate و LocalTime إلى العقدة والمستعرض.

بعد أن عملت مع هذه المفاهيم في Java ، فإن كل شيء آخر يشعر بالملل والخطأ.

وصلة؟

يوم الجمعة ، 11 ديسمبر 2015 ، الساعة 4:30 مساءً Andrew Schmadel [email protected]
كتب:

لقد عثرت مؤخرًا على وحدة npm جديدة تهدف إلى نقل الكثير من ملفات
JodaTime API (على سبيل المثال. تواريخ Java 8) إلى JS.

سيؤدي ذلك إلى جلب أشياء مثل الثبات والتاريخ المحلي والوقت المحلي إلى
العقدة والمتصفح.

بعد أن عملت مع هذه المفاهيم في Java ، فإن كل شيء آخر يشعر بالملل
وعرضة للبق.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/moment/moment/issues/1754#issuecomment -163964349.

ووت.
(مكتوب على الهاتف المحمول ، توجع العذر)

نظرًا لأنني لم أتحدث بعد ، سأقول فقط أنني أؤيد الثبات في اللحظة 3.0. في المقام الأول لأنني أتيت من مدرسة DDD الفكرية ، حيث يمكن اعتبار كائنات مثل moment كائنات ذات قيمة ، وبالتالي يتم تنفيذها بشكل أفضل على أنها غير قابلة للتغيير.

حتى لو كان هناك أداء مهم ، فلا يزال هذا هو الشيء الصحيح الذي يجب القيام به. يجب أن تتناسب اللحظة بشكل طبيعي مع تصميمات الآخرين. تتفوق واجهة برمجة التطبيقات البديهية على الأداء ، والطفرة ليست بديهية على كائنات القيمة (IMHO).

أعتقد أيضًا أن اللحظة 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 أفترض أن هذا هو: https://github.com/pithu/js-joda

ichernev ، @ mj1856 ، نظرًا لأنني لم أشارك في التطوير الأساسي

لست متأكدًا مما إذا كنت مانعًا الوحيد لهذا الأمر ، لكنني مرتاح للمضي قدمًا مع الثبات في الإصدار 3.0.

تضمين التغريدة هذا كان هو. أعتذر عن تعليقي غير المتسق - لقد نقرت بوضوح على زر "إرسال" في منشور مكتوب في منتصف الطريق.

لتجميع بعض أفكاري المفككة:

• من الواضح أن هناك بعض الاهتمام بعناصر التاريخ الثابتة لـ JS. توجد مكتبات تاريخ ناضجة غير قابلة للتغيير في العديد من اللغات الأخرى ، وهناك الكثير من الزخم العام تجاه الكائنات غير القابلة للتغيير في JS (يحتوي immutable.js على 10500 نجمة إذا كان هذا مؤشرًا). على أقل تقدير ، أعتقد أن هذا يستحق إثباتًا للمفهوم.
• على الرغم من هذا الاهتمام ، يبدو أنه تمت كتابة القليل جدًا من التعليمات البرمجية. يبدو أن js-joda هي أول محاولة جادة لكتابة مكتبة تاريخ ثابتة لـ JS.
• ستكون اللحظات غير القابلة للتغيير تغييرًا هائلًا ، مما يثير بعض الأسئلة الفلسفية. على الرغم من أنني أكره أن أفقد دعم مجتمع MomentJS الضخم جدًا ، إلا أنه لن يكون بالضرورة أمرًا مروعًا بالنسبة لنا نحن المهتمين بتواريخ JS الثابتة لعمل استراحة نظيفة ، والمساهمة في js-joda بدلاً من المحاولة لدفع تغيير جذري إلى حد ما على Moment (مكتبة ناضجة مع قاعدة مستخدمين كبيرة وراسخة).
• جانبا: لا يزال js-joda صغيرًا جدًا ، ومن غير الواضح ما هي أهداف المؤلف ونواياه بالنسبة للمكتبة. على وجه الخصوص ، يحتاج إلى اختيار ترخيص ، وقد نرغب في النظر في ما إذا كانت احتياجات مطور JS النموذجي ستتم تلبيتها من خلال إعادة تنفيذ مخلصة لـ Joda Time أو JSR-310.

+1 للثبات ، وكود saner الذي سينتج.

سيكون مجهودًا كبيرًا ، لذا أتقدم بخالص الشكر لأولئك الذين (وما زالوا) يحققون ذلك.

تُستخدم Moment على نطاق واسع لدرجة أنني أعتقد أنه سيكون من الممكن اتخاذ إجراء مع شيء يقترب من التالي ، على افتراض أن يتم تطبيقه على نحو مشابه لـ butterflyhug https://github.com/WhoopInc/frozen-moment

3.x: غير قابل للتغيير كخيار ، يتم تعيينه افتراضيًا إلى خطأ ، ويتم تعيين علامة على التصدير اللحظي العالمي الذي سيتم تعيينه على صحيح ؛ console. warn عند تحميل المكتبة (في وضع dev)
4.x: غير قابل للتغيير كخيار ، تم تعيينه افتراضيًا إلى صحيح ، ولا يزال العلم متاحًا ليتم تعيينه على أنه خطأ ؛ console. للتحذير من الجدول الزمني لـ 5.x (في وضع dev)
5.x: غير قابل للتغيير باعتباره الطريقة الوحيدة

احصل على صفحة أولية ومركز يصف رؤية الثبات على المدى الطويل - على سبيل المثال ، إصدار رئيسي واحد سنويًا على طول المخطط 3.x / 4.x / 5.x الذي وضعته - وأعتقد أنه سيعطي فكرة معقولة المبلغ لأي شخص متضرر لتحديث التعليمات البرمجية الخاصة بهم.

بعض الملاحظات:

1. لقد قمت ببناء WhoopInc / لحظة مجمدة على أمل أن مجموعة من الأشخاص هنا قد يكونون على استعداد لبناء أشياء معها ، كطريقة للعثور على نقاط المشكلة في النظام البيئي اللحظي حيث يؤدي الثبات إلى تعطيل المكونات الإضافية ، وما إلى ذلك. حتى الآن ، قام عدد قليل من الأشخاص بذلك ، الأمر الذي جعلني أقل حرصًا على العمل على اللحظة المجمدة و / أو التبشير المجتمعي لمساعدة مؤلفي الإضافات في دعم اللحظات الثابتة.

ومع ذلك ، ما زلت على استعداد للمساعدة في إصلاح الأخطاء التي يجدها الأشخاص عند استخدام لحظة مجمدة - بغض النظر عما إذا كانت هذه الأخطاء لي أو ما إذا كانت في مكون إضافي آخر لم يفكر أبدًا في احتمال أن تصبح اللحظات غير قابلة للتغيير. مجرد ملف القضايا في لحظة التجمد وسألقي نظرة. وما زلت أعتقد أن جهد المجتمع حول شيء مثل اللحظة المجمدة يمكن أن يساعدنا في فهم وتخفيف آلام الانتقال إلى لحظات ثابتة.

1. إذا نفذت اللحظة الثبات في الإصدار 3.0 ، فسيكون من السهل جدًا أن يكتب شخص ما غلافًا ويحتفظ به لتنفيذ اللحظة القابلة للتغيير 2.x API أعلى واجهة برمجة التطبيقات 3.x غير القابلة للتغيير. من الناحية المفاهيمية ، سيبدو هذا في الواقع إلى حد كبير مثل اللحظة المجمدة: في كل مكان تلك اللحظة المجمدة ضمنيًا clone() s ، فإن غلاف التغيير هذا سيغير ضمنيًا مرجعيته الداخلية إلى قيمة لحظة ثابتة جديدة. يمكن أن يساعد هذا أيضًا في تسهيل الانتقال للأشخاص الذين يستخدمون اللحظة في قواعد أكواد كبيرة.
2. سأكون على استعداد للمساعدة في التفكير في المشكلات المحتملة وتنفيذ الثبات في اللحظة الثالثة ، إذا رغبت في ذلك.
3. سيقوم js-joda بنقل JSR-310 مباشرة إلى JavaScript باستخدام ترخيص BSD .

butterflyhug - شكرًا لبناء اللحظة المجمدة! لقد كنت متحمسًا عندما وجدت ذلك ، لكنني كنت قلقًا بشأن إدخال تبعية من مشروعي إلى لحظة مجمدة ، نظرًا لأنه إذا تم إسقاط الدعم ، فإن التغيير من لحظة غير قابلة للتغيير إلى لحظة قابلة للتغيير ستكون مهمة كبيرة في الكود الخاص بي. إذا كان هدفك هو الحصول على تعليقات وكنت تدعمها بنشاط ، فأنا مرتاح أكثر لفعل ذلك. :-)

لا أعرف عدد الأشخاص الآخرين الذين قد يكون لديهم نفس عمليات التفكير.

أشعر بالفضول إذا كان الناس هنا يعتقدون أنه يجب استكشاف الثبات بالاقتران مع فكرة كسر التبعية على الكائن Date (أو حتى إضافة نوع من التقييم البطيء) لأسباب تتعلق بالأداء.

أود أن أقترح اتخاذ الأشياء خطوة واحدة في كل مرة ،schmod. هذا بالفعل (على ما يبدو) تغيير كبير

RobertMcCarter Yep ، أخطط لدعم اللحظة المجمدة في المستقبل المنظور ، ما لم / حتى يتم تنفيذ بعض خيارات الثبات في المكتبة الأساسية - إلى حد كبير لأنني أستخدمها شخصيًا لبعض الأشياء التي أتوقع أن تكون كذلك الحفاظ عليها لفترة من الوقت. ومع ذلك ، لا تغطي حالات الاستخدام الخاصة بي نظام Moment البيئي الكامل ، لذلك أعتمد على التعليقات والاستخدام من الأشخاص الآخرين للمساعدة في تحديد ما هو مهم.

+1 لثباتها ، بعد نصف ساعة أمضيتها في اكتشاف ما حدث لتطبيقي بعد استخدام endOf () لأول مرة. منحت أنني لم أقرأ المستندات بعناية ، فقد افترضت للتو أن طريقة بهذا الاسم ستعيد نهاية الشهر على سبيل المثال ، وتترك مثيل اللحظة دون تأثر. لأكون صريحًا ، إنها مفاجأة وأجد أنه من السخف ألا يحدث ذلك بهذه الطريقة أو ربما رأسي معتاد جدًا على - في رأيي - الفوائد الهائلة لامتلاك واجهة برمجة تطبيقات غير قابلة للتغيير تقريبًا

+1 لثباتها :)

أنا لا أهتم بالثبات ، اترك هذه المكتبة الممتازة وشأنها!

@ es6Test على أي أساس لا توافق على الثبات؟ هل لديك أي سبب ملموس غير مقاومة التغيير؟

+1
أعتقد أنه سيسهل استخدام المكتبة إذا كانت غير قابلة للتغيير ، فإن الكود الخاص بي مليء بطريقة clone.

+1 من فضلك ، المزيد من الثبات ^ _ ^

danpantry @ بعد إنشاء المزيد من التطبيقات ، غيرت رأيي. أنا أفضل الثبات.

لكني ما زلت أرغب في أن يكون لدي بعض المتغيرات القابلة للتغيير ، غالبًا ما أرغب في إضافة أيام إلى اللحظات ولا أريد إنشاء المزيد من المتغيرات للاحتفاظ بالنتيجة.

@ es6Test فقط استخدم let إذا لم تعجبك _really_ ؟

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

أنا أؤيد الثبات أيضًا. هذه هي الميزة الوحيدة لمكتبة Python datetime والتي تجعلها تتألق حقًا. يمكنك رمي الأشياء دون الحاجة إلى القلق بشأن تعديل شيء ما ، تمامًا كما هو الحال مع سلاسل الأحرف.

في عالم React / Redux ، تعتبر الثبات أمرًا بالغ الأهمية. لقد واجهت بعض المشكلات الشائكة بالفعل لأن اللحظة ليست ثابتة في جوهرها. الأداء غير ذي صلة هنا لأنه يمكن تخفيفه. تثبت مكتبة ImmutableJs من Facebook أنه يمكن عمل غير قابل للتغيير دون التضحية بالأداء.

سأقوم أيضًا بإجراء 1+ على الثبات على طول الطريق. لن تحصل على أي فائدة من الثبات حتى ذلك الحين ، لذلك لا فائدة من القيام بذلك في منتصف الطريق.

يتم استخدام الثبات والبرمجة الوظيفية الآن أكثر من أي وقت مضى (وأنا أحبه). سأقدم وقتي الخاص للمساهمة في هذه المبادرة. يرجى الاتصال بي أيها المساهمون وإخباري كيف يمكنني تقديم المساعدة.

أراد الفريق تقديم تحديث حول هذا الأمر حيث كان لدينا الكثير من الاهتمام.

في هذا الوقت ، نريدك أن تعلم أننا استمعنا إلى مخاوفك. يوافق فريق المشرفين بالكامل على أننا عندما نكتب المكتبة من الألف إلى الياء ، سنختار جعلها غير قابلة للتغيير. ومع ذلك ، ليس هذا هو الحال الآن.

كما هو الحال ، لدينا 4 ملايين NPM تنزيل شهريًا ، إلى جانب عدد لا يحصى من المستخدمين الذين يعتمدون على الحصول على اللحظة من خلال القنوات الأخرى. كل هؤلاء المستخدمين لديهم رمز يتوقع أن تكون اللحظة قابلة للتغيير كما هي اليوم. بالإضافة إلى ذلك ، لدينا العديد من المكونات الإضافية التي تعتمد على كون اللحظة قابلة للتغيير.

الشفرة سهلة بما يكفي للكتابة ، لكن من الصعب تلبية احتياجات الدعم لهذا النوع من التغيير كفريق صغير يقوم بذلك في أوقات فراغنا. بعد قولي هذا ، نحن على استعداد للنظر فيه. نحن نتساءل بالرغم من ذلك:

• لماذا لا يلبي البرنامج المساعد Frozen Mom احتياجاتك؟
• هل تحتاج فقط إلى واجهة برمجة تطبيقات غير قابلة للتغيير (واجهة برمجة تطبيقات تقوم دائمًا بإرجاع نسخة) ، أم أننا لسبب ما نحتاج إلى عدم تغيير الكائنات داخليًا؟
• هل ستلبي إضافة واجهة برمجة تطبيقات ثانية غير قابلة للتغيير إلى الكود الحالي احتياجاتك؟

تكمن المشكلة في المكون الإضافي المجمد اللحظي في أنه يتم الاشتراك فيه وليس إلغاء الاشتراك. كل
تحتاج اللحظة () إلى تجميد () لكي تكون غير قابلة للتغيير.

بيت القصيد من الثبات هو أنه عندما يكون لدي كائن X ، فأنا أعرف ذلك
ما لم أجعله قابلاً للتغيير بشكل صريح ، يجب أن يكون منيعًا للتغيير.
أي وظيفة عامة تتيح لي تغيير كائن داخليًا بدون
صريح التحول هو إشكالية.

أعتقد أن أحد الحلول هو القيام بعدة أشياء:

1. أضف واجهة برمجة تطبيقات ثانية غير قابلة للتغيير إلى الكود الحالي
2. احصل على لحظة عامة () حيث إذا تم ضبطها على الوضع الثابت ، الكل
   لحظة () الحالات التي تم إنشاؤها غير قابلة للتغيير ، إذا تمت محاولة استدعاء قابل للتغيير ،
   لن يتغير وبدلاً من ذلك يخطئ في الرسالة المناسبة لاستخدام غير قابل للتغيير
   مكالمات API.

أعتقد أن ذلك سيرضي الجميع. ماذا تعتقد؟

يوم الاثنين 23 مايو 2016 الساعة 12:11 مساءً ، Maggie Pint [email protected]
كتب:

أراد الفريق تقديم تحديث حول هذا الأمر نظرًا لأن لدينا الكثير
فائدة.

في هذا الوقت ، نريدك أن تعلم أننا استمعنا إلى مخاوفك. ال
يوافق فريق المشرفين بالكامل على أننا كنا نكتب المكتبة من
من الأرض ، نختار جعلها غير قابلة للتغيير. ومع ذلك ، هذه ليست الطريقة
إنه الآن.

كما هو الحال ، لدينا 4 ملايين NPM تنزيل شهريًا ، إلى جانب ملف
عدد لا يحصى من المستخدمين الذين يعتمدون على الحصول على لحظة من خلال الآخرين
القنوات. كل هؤلاء المستخدمين لديهم رمز يتوقع أن تكون اللحظة قابلة للتغيير مثل
انه اليوم. بالإضافة إلى ذلك ، لدينا العديد من المكونات الإضافية التي تعتمد على اللحظة الحالية
متقلب.

الشفرة سهلة بما يكفي للكتابة ، لكن احتياجات الدعم من هذا النوع
من الصعب القيام بالتغيير كفريق صغير يقوم بذلك في قطع غيارنا
زمن. بعد قولي هذا ، نحن على استعداد للنظر فيه. نحن نتساءل بالرغم من ذلك:

• لماذا لا يلبي البرنامج المساعد Frozen Mom احتياجاتك؟
• هل تحتاج فقط إلى واجهة برمجة تطبيقات غير قابلة للتغيير (واجهة برمجة تطبيقات تقوم دائمًا بإرجاع ملف
  استنساخ) ، أو هل نحتاج لسبب ما إلى عدم تحوير ملف
  شاء؟
• ستلبي إضافة واجهة برمجة تطبيقات ثانية غير قابلة للتغيير إلى الكود الحالي
  يحتاج؟

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/moment/moment/issues/1754#issuecomment -221062274

إريك لاو من حساب Gmail.

شكرا للرد maggiepint.

1. بعض المشكلات المتعلقة بالمكوِّن الإضافي المتجمد: إنه ليس الإعداد الافتراضي ، فهو يتطلب عملاً إضافيًا لاستخدامه ، وهناك فرصة أقل لصيانته بنشاط ، وافتراضي أنه يحتوي على أداء ناجح (ربما يكون صغيرًا جدًا) على شيء كان بنيت على أنها ثابتة. أعتقد أن المشكلة الأكبر هي نسيان استخدامه ، خاصة في المشاريع الأكبر مع العديد من المهندسين.
2. يجب أن تكون واجهة برمجة التطبيقات خالية من الآثار الجانبية. يعد إرجاع نسخة أمرًا جيدًا ولكن إذا قمت أيضًا بتعديل الكائن الأصلي ، فسيكون ذلك من الآثار الجانبية. يجب ألا يتم تعديل الكود التالي عند إعلان النهاية:

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

1. هل تقصد وجود وظائف مثل "immutableAdd" بالإضافة إلى "add"؟ إذا كان الأمر كذلك ، فحينئذٍ نعم من الناحية الفنية ، خاصةً إذا قمت بإنشاء غلاف لاستخدام وظائف غير قابلة للتغيير باستخدام نفس الأسماء:

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

في رأيي ، يضفي هذا النهج نفسه على ترقية رشيقة لأولئك الذين يرغبون في استخدام واجهة برمجة التطبيقات غير القابلة للتغيير - ستظل الشفرة الحالية تعمل ، ولن يتم إجبار أي شخص على ذلك ، وتتطلب تغييرات أقل لأولئك الذين يرغبون في استخدام واجهة برمجة التطبيقات غير القابلة للتغيير.

لدينا كل النية لجعل الآثار الجانبية للكود مجانية. سيكون النمط الأساسي هو ربط الوظائف الحالية ، وجعلها تستدعي استنساخًا ، ثم تعمل على هذا الاستنساخ.

من الناحية الفنية ، إذا كنت تقوم بإنشاء كود غير قابل للتغيير حقًا ، فيجب إنشاء الكائنات بقيم لن تتغير. القيام بذلك سيزيد من صعوبة إجراء هذا التغيير بالرغم من ذلك. من الأسهل بكثير استدعاء استنساخ ثم القيام بما كنا نفعله من قبل.

أنا ثاني فكرة درو:

استيراد "لحظة / ثابتة" ؛
بدء = لحظة () ؛
النهاية = start.add (10، 'minutes') ؛ // نسخة غير قابلة للتغيير من الإضافة

سيكون هذا أمرًا رائعًا نظرًا لأنه إلغاء الاشتراك غير قابل للتغيير ولا توجد تغييرات عليه
أسماء الوظائف.

يوم الاثنين 23 مايو 2016 الساعة 12:53 مساءً ، Maggie Pint [email protected]
كتب:

لدينا كل النية لجعل الآثار الجانبية للكود مجانية. الأساسية
سيكون النمط هو ربط الوظائف الحالية ، وجعلها تستدعي استنساخًا ،
ثم تعمل على هذا الاستنساخ.

من الناحية الفنية ، إذا كنت تصنع كودًا غير قابل للتغيير حقًا ، فإن الكائنات
يجب أن تُبنى بقيم لن تتغير. القيام بذلك
زيادة صعوبة إجراء هذا التغيير بالرغم من ذلك. من الأسهل بكثير
استدعاء استنساخ ثم افعل ما كنا نفعله من قبل.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/moment/moment/issues/1754#issuecomment -221076796

إريك لاو من حساب Gmail.

@ ericlau- صلبة

1. احصل على لحظة عامة () حيث إذا تم ضبطها على الوضع الثابت ، الكل
   لحظة () الحالات التي تم إنشاؤها غير قابلة للتغيير ، إذا تمت محاولة استدعاء قابل للتغيير ،
   لن يتغير وبدلاً من ذلك يخطئ في الرسالة المناسبة لاستخدام غير قابل للتغيير
   مكالمات API.

سوف ينكسر هذا إذا توقعت مكتبتان على الصفحة سلوكيات مختلفة في الوقت الحالي. على سبيل المثال ، يمكنك استخدام منتقي البيانات ، الذي يتوقع لحظة قابلة للتغيير ، وتتوقع شفرتك الخاصة واحدة غير قابلة للتغيير - لن تعمل.

وجود واجهة برمجة تطبيقات غير قابلة للتغيير (لحظة مجمدة)

هذا أيضًا ليس مثاليًا ، لأنه لن تعمل معه أي ملحقات للحظة. في الواقع ، لا توجد طريقة لإدخال الثبات والحفاظ على عمل جميع المكونات الإضافية الحالية. لن تعمل المكونات الإضافية على الإطلاق ، أو لن تعمل مع لحظات ثابتة ، قبل أن يقضي شخص ما الوقت في جعلها تعمل.

استيراد "لحظة / ثابتة" ؛

لذلك هذا في الأساس يقترح مكتبة مختلفة بواجهة مماثلة. بالتأكيد ، لن يكسر الكود ولكن من المحتمل أن يتسبب ذلك في حدوث ارتباك ويجعل بعض المشروعات بها نسختين مثبتتين (على سبيل المثال ، سيأخذ منتقي البيانات الإصدار القابل للتغيير ، وستأخذ الكود الإصدار الثابت).

الخيار الأفضل هو جعل واجهة برمجة التطبيقات 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

ليست مكتبة مختلفة ، ولكن نعم - لديك نوعان منفصلان ومميزان من اللحظات. بافتراض أن كائنات اللحظة القابلة للتغيير والثابتة تشترك في قدر كبير من التعليمات البرمجية "تحت الغطاء" ، فلن يحتاج حجم المكتبة إلى زيادة كبيرة للمطورين الذين يحتاجون إلى استخدام كلا الصيغتين. إذا كان التطبيق يستخدم صيغة واحدة فقط ، فيمكن استخدام اهتزاز الشجرة لإنتاج بنية محسّنة.

من المحتمل أن يؤدي تشعب المكتبة إلى مضاعفة حجم الشفرة التي سيحتاج معظم المطورين إلى تحميلها ، وهو أمر غير مرغوب فيه لمعظم تطبيقات الويب.

لا أعتقد أنه سيكون فكرة جيدة أن نفترض أن أي مكونات إضافية ستعمل مع لحظات ثابتة "خارج الصندوق" ، ولن أعتبر ذلك مطلبًا معقولًا.

لا أعتقد أيضًا أنه من المتطلبات / الافتراضات المعقولة أن تكون واجهات برمجة التطبيقات المتغيرة وغير القابلة للتغيير متطابقة. يجب أن نسعى جاهدين لجعل مسار الترقية سلسًا قدر الإمكان ، ولكن لا ينبغي أن نحصر أنفسنا في أي صيغ محرجة.

أعتقد أيضًا أن هناك مساحة كبيرة للنقاش / الجدل حول الشكل الذي ستبدو عليه واجهة برمجة التطبيقات "غير القابلة للتغيير". نمط البناء؟ إنشاء مثيل منشئ؟ كائن القيمة؟ هل تريد تنفيذ واجهة برمجة التطبيقات الحالية ، ولكن هل تريد أي طرق "تعيين" إرجاع نسخة؟

طلبي الوحيد هو أن تكون واجهة برمجة التطبيقات الجديدة واضحة ولا لبس فيها بشأن نوع اللحظة التي نعمل معها. IMO ، freeze يفشل في هذا الاختبار ، ويقدم القليل من الحماية بخلاف استدعاء clone() كل مرة أقضي فيها لحظة.

لذلك هذا في الأساس يقترح مكتبة مختلفة بواجهة مماثلة. بالتأكيد ، لن يكسر الكود ولكن من المحتمل أن يتسبب ذلك في حدوث ارتباك ويجعل بعض المشروعات بها نسختين مثبتتين (على سبيل المثال ، سيأخذ منتقي البيانات الإصدار القابل للتغيير ، وستأخذ الكود الإصدار الثابت).

ليست مكتبة منفصلة ، مجرد غلاف رفيع حول نفس المكتبة. لن يكون هناك سوى إصدار واحد من لحظة التثبيت. يمكنك استيراد "لحظات / غير قابلة للتغيير" وقد يقوم منتقي البيانات باستيراد "لحظة" في نفس المشروع بدون مشكلة.

قد تكون هناك مشكلة في التفاعل مع المكونات الإضافية التي تستغرق أو تعود للحظة إذا لم يتم تحديثها للتعامل مع اللحظات الثابتة.

لنفترض أنك مررت لحظة غير قابلة للتغيير إلى مكون إضافي يتعامل معها في الوقت الحالي على أنها قابلة للتغيير. حتى يتم تحديث المكون الإضافي ، يجب أن تكون هناك طريقة للتحويل إلى متغير قبل إعطاء لحظة للمكوِّن الإضافي. من الناحية المثالية ، سيتم إهماله بعد أن يكون لدى المشرفين على المشروع بعض الوقت للخبز لدعم الثبات. من المحتمل أيضًا أن تكون هناك طريقة لاكتشاف الثبات (لمؤلفي الإضافات).

على الجانب الآخر ، قد تتخلص المكتبة التي يتم تحديثها لاستخدام الواجهة الثابتة ، وتعيد للمستخدمين لحظة غير قابلة للتغيير ، أولئك الذين لا يستخدمون الثبات ولا يتوقعون لحظة غير قابلة للتغيير. أعتقد أنه يمكن التعامل مع هذا أيضًا من خلال طريقة إلغاء مهملة للتحويل. يجب أن ترجع المكونات الإضافية لحظة من نفس النوع كما تم تمريرها.

maggiepint نعم أنا أفهم وجهة نظرك ولكن أعتقد أن ذلك قد يكون قفزة كبيرة للغاية. أنا شخصياً سأكون على ما يرام مع نهج يكون ببساطة خلف الستارة clone . خاصة أثناء عمل مكامن الخلل.

tacomanator هذا ما أريد أن أفعله أيضًا. إن إعادة كل شيء ليكون غير قابل للتغيير داخليًا أمر لا يمكن الدفاع عنه بشكل رهيب.
لم أكن أعرف ما إذا كان الناس يريدون ذلك لسبب ما.

schmod هل يمكنك توضيح سبب عدم اعتقادك أن freeze هو واجهة برمجة تطبيقات واضحة لا لبس فيها؟

إذا كان اسم الوظيفة لطيفًا جدًا ، فسأكون سعيدًا للنظر في حجة لإعادة تسمية أساليب Frozen Moment كمسألة في هذا الريبو. من ناحية أخرى ، إذا كنت لا تعتقد أنه من الممكن التحويل من قابل للتغيير إلى غير قابل للتغيير (والعكس) ، فأنا أظن أن ذلك قد يثير بعض النقاش هنا - على الرغم من ملاحظة أنني سأكون أيضًا على استعداد لأخذ لحظة مجمدة في هذا الاتجاه إذا حصلنا على إجماع تقريبي على أن ذلك سيكون أفضل واجهة برمجة تطبيقات.

maggiepint هل أنا محق في قراءة "إضافة واجهة برمجة تطبيقات ثانية غير قابلة للتغيير إلى الكود الحالي" كتجميع جزء أو كل لحظة مجمدة مع المكتبة الأساسية؟ إذا كان ذلك مفيدًا ، فسأكون سعيدًا بالمساعدة في ترحيل Frozen Moment أو بعض أفكارها إلى المنظمة الحالية (إما كمكوِّن إضافي رسمي أو كجزء من المكتبة الأساسية) والمساعدة في صيانتها في هذا السياق الجديد.

butterflyhug أنت تقول بالضبط ما كان يفكر فيه ichernev . كان يميل نحو البرنامج المساعد الرسمي الذي يتم شحنه مع المكتبة. ربما يمكننا التنسيق حول هذا في Gitter في وقت ما؟ يجب أن أكون بعيدًا عن العمل لمدة ثلاثة أيام في العمل ، لذا فإن التوافر سيكون محدودًا. يجب أن يكون باقي الرجال بالجوار.

تضمين التغريدة

أعتقد أن freeze اسم جيد ، من الممتع أن تتذكر استخدامه بعد _ كل استدعاءات فردية_ للحظة.

أعتقد أيضًا أن import 'moment/immutable' لديه نفس المشكلات ، ومن السهل نسيانها.

بصراحة ، أنت تتبع semver ، أعتقد أن النهج الصحيح هو جعل كل شيء يستخدم _ افتراضيًا _ وإصدار هذا التغيير باعتباره إصدارًا رئيسيًا خاصًا به ، مع خطة لعدم دعم الإصدارات الأقدم بعد فترة زمنية (12 شهرًا؟). يمكن دمج الميزات / الإصلاحات الجديدة في كلا المسارين ، غير قابل للتغيير وقابل للتغيير ، مع خطة ترحيل تُعطى للمستخدمين الذين يستخدمون الإصدار القابل للتغيير.

بعد الاثني عشر شهرًا المذكورة أعلاه ، ستظل الإصدارات القديمة تعمل ، لكنها لن تتلقى أي TLC.

بالطبع ، هذا كثير من النفقات العامة ، لكنني أعتقد أنه سيكون من الأفضل القيام بهذا التغيير بشكل صحيح بدلاً من محاولة التلاعب به لصالح التوافق مع الإصدارات السابقة. كما أنه يجعل التغيير أكثر تعقيدًا مما قد يثني اهتمام فريق التطوير الأساسي. لا أدري.

هناك جانب سلبي محتمل آخر لهذا النهج حيث يستخدم المستخدمون هذا البرنامج النصي من CDN ولا يحددون إصدارًا صريحًا (لأي سبب كان) ، مما قد يتسبب في تعطل مواقعهم إذا تم إصدار واجهة برمجة تطبيقات متوافقة مع الإصدارات السابقة. كل ما يمكنني قوله هو "لقد أخبرتك بذلك" ، لكنني أفهم أن هذا قد لا يكون مخاطرة مقبولة في الوقت الحالي.

سيكون وجود نسختين من نفس المكتبة مشكلة فقط إذا كنت تعتمد على كائن عالمي ولا توجد طريقة رائعة للتغلب على ذلك بخلاف الاستمرار في استخدام freeze() .

يبدو أن TLDR هو أن المشكلة التي تحاول حلها يتم حلها بواسطة semver ، الذي تستخدمه بالفعل. لماذا لا تستخدمه فقط كما يجب استخدامه؟ الإصدار الرئيسي لكسر التغييرات. المناسبة الوحيدة التي يحدث فيها هذا الانقطاع هي عندما تعتمد على متغير عالمي moment وباستخدام CDN ، ولكن أي تغيير نجريه هنا سيؤدي إلى كسر ذلك على أي حال

تصويتي أيضًا على إصدار 3.0 semver وغير القابل للتغيير.

لا أعترض على اسم freeze ، لكنني أجد أنه من الصعب وضع افتراضات آمنة حول ما إذا كانت لحظة مجمدة أم لا. (يواجه Object.freeze() مشكلة مماثلة)

يجب ألا تكون اللحظة الثابتة غير قابلة للتجميد ، ولا ينبغي أبدًا أن يكون هناك أي شك حول ما إذا كانت مجمدة أم لا. يمكن تحقيق ذلك من خلال متغير صارم لنمط المنشئ (على سبيل المثال. الكائن _ فقط _ له محددات حتى يتم استدعاء .build() ، وبعد ذلك _ فقط _ يتم الحصول عليه) ، أو "تجميد" اللحظة فورًا تم إنشاء مثيل له ، مع إعادة كل المستوطنين نسخة.

على سبيل المثال:

/* 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

المثال الأول شبيه جدًا بجافا ، ولكنه أيضًا يترك القليل من الغموض حول كيفية تكوين اللحظات وما يمكنك فعله بها. كما أنه يوفر مسارًا فعالًا وبديهيًا لإنشاء لحظات جديدة مع القليل من النفقات العامة ، ويتابع عن كثب كيفية استخدام معظم الأشخاص للحظة حاليًا.

أؤيد وجود المستوطنين في اللحظات المبنية برمي الاستثناءات ، لأن هذا السلوك من شأنه أن يقلل الغموض (على حساب الإسهاب) ، ويجبر المطورين على الاعتراف كلما قاموا بإنشاء لحظات جديدة.

يبدو أن المثال الثاني يحتوي على الكثير من النفقات العامة ، لأننا نصنع (ونتخلص من) الكثير من الكائنات. ولكن هناك مجال كبير للتحسين. GC الحديثة جيدة جدًا ؛ يمكن أن يساعد التقييم البطيء ؛ يمكننا أن نجعل كائنات Moment خفيفة الوزن قدر الإمكان (بإسقاط Date ) ، وما إلى ذلك (لبعض المقارنة ، لا يختلف هذا النمط عن الطريقة التي يتم بها التعامل مع السلاسل في JavaScript)

أنا من محبي semver ، لكن حالة استخدام المتصفح تجعل من كسر التغييرات مشكلة ، لأنه سيكون من المستحيل الحصول على نسختين من اللحظة على نفس الصفحة بدون أداة تحميل وحدة.

كما ذكرنا سابقًا ، هناك الكثير من التعليمات البرمجية القديمة التي تعتمد على اللحظة. على أقل تقدير ، نحتاج إلى إصدار يدعم كلا النموذجين ، للسماح بفترة انتقال سلسة.

+1 للطرق القابلة للإنشاء التي تعيد لحظات جديدة. أنا لا أهتم حتى إذا كانت غير قابلة للتغيير. فقط أعطني تكوينًا ، حتى أتمكن من ربط الطرق معًا ، أو تعيين اللحظة المتغيرة في سطر واحد (بدلاً من 2).

alexyuly لماذا لا يعمل الاستنساخ من أجلك؟ إذا كنت تريد إنشاء محتوى مضمّن ، فيمكنك القيام بشيء مثل:

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

أو أيا كان.

maggiepint حسنًا ، أشعر بالحماقة ، يبدو أنه يمكنك إنشاء طرق طوال الوقت. شكرا على الاكرامية. ربما اجعل الأمر أكثر وضوحًا في المستندات؟ على سبيل المثال http://momentjs.com/docs/#/manipulation/start -of / <- لم يذكر أي قيمة معاد.

تحديث بسيط - منشور المدونة هذا هو موقفي من هذه المشكلة في الوقت الحالي: https://maggiepint.com/2016/06/24/why-moment-js-isnt-immutable-yet/

أنا لا أتحدث نيابة عن بقية أعضاء الفريق ، لكنهم رأوها ، وأقول بشكل عام أننا جميعًا في مكان مشابه.

maggiepint نقاط رائعة وصالحة جدا

شكرا على هذا. الثبات هو الملك في الإعادة ، لذلك سأنتقل إلى js-joda بالتأكيد. قد لا يزال بإمكاني الاحتفاظ باللحظة للوقت النسبي.

إريك لاو - بريد جوجل

في الجمعة ، 24 حزيران (يونيو) 2016 الساعة 11:12 صباحًا -0700 ، كتبت "Maggie Pint" [email protected] :

تحديث بسيط - منشور المدونة هذا هو موقفي من هذه المشكلة في الوقت الحالي: https://maggiepint.com/2016/06/24/why-moment-js-isnt-immutable-yet/

أنا لا أتحدث نيابة عن بقية أعضاء الفريق ، لكنهم رأوها ، وأقول بشكل عام أننا جميعًا في مكان مشابه.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

بعض الأخطاء الشائعة / الارتباك الناجم عن الطفرة: http://stackoverflow.com/questions/26131003/moment-js-start-and-end-of-given-month

+1 لهذا ولكن في الواقع مع Redux ، وجدت أن هذه مشكلة صغيرة بشكل مدهش لأنني لا أضع مثيلات اللحظة في كائن حالة إعادة التشغيل على الإطلاق. فقط سلاسل التاريخ أو الطوابع الزمنية وأنا أستخدم Moment في طرق العرض فقط لتحويل سلاسل التاريخ إلى سلاسل أخرى.

أفعل هذا بشكل أساسي لأنه من السهل إجراء تسلسل للحالة وإلغاء تسلسلها دون أي عمل إضافي ، ولكنه يخفي أيضًا الطفرة بشكل جيد من React و Redux.

أبذل قصارى جهدي لإطلاعك على آخر المستجدات في نهاية هذا الأسبوع. لدينا خطة ، لكني بحاجة للتأكد من أنها ستنجح قبل أن ألتزم بها. لسوء الحظ ، سأنتقل من مينيابوليس إلى سياتل الأسبوع المقبل ، لذلك قد يتباطأ هذا لبعض الوقت ، لكنني أريد المضي قدمًا.

تحديث صغير استعدادًا لتحديث أكبر ، لأنني لاحظت أن منشور المدونة لا يزال يتلقى بعض الحركة. أقوم حاليًا بإعادة بناء لحظة العمل لاستخدام Babel. يؤدي هذا إلى إحضار المكون الإضافي butterflyhug إلى المستودع الأساسي وجعله مدعومًا رسميًا. في هذه العملية ، سنقوم بتنظيف بعض الأشياء حول المكون الإضافي. butterflyhug ساعدنا كثيرًا في هذا الأمر. بالإضافة إلى ذلك ، ألتقي جون ديفيد دالتون من LoDash (كلانا يعمل في Microsoft) لمناقشة الإستراتيجية عند إحضار مكون إضافي رسمي ، كما فعل بالفعل مع LoDash الوظيفية. مشاركة مدونة طويلة و RFC قريبًا.

maggiepint أثناء دعم اللحظة المجمدة رسميًا ، هل تخطط لمخاطبة https://github.com/WhoopInc/frozen-moment/issues/20؟

أعتقد أن هذا الأسلوب في الثبات جيد بما يكفي طالما أن كل مكالمة إلى moment() ترجع لحظة مجمدة بشكل افتراضي ، ولا يتعين على المطورين أن يتذكروا استدعاء .freeze() كل مرة.

gabrielmaldi سؤال جيد. أنا أكتب RFC (يجب أن يتم ذلك في أي يوم الآن) ، ونعم ، إن هدفي الواضح هو تقديم قصة أفضل للاستخدام غير القابل للتغيير فقط. يتماشى اقتراحي مع تعليقي على WhoopInc / Frozen-moment # 20 ، مع مراعاة الأساليب الثابتة. سوف أنشر رابطًا إلى RFC الخاص بي هنا وفي هذه المسألة عندما أفتح ملفي PR الخاص بي ضد RFC repo ، وسنرحب بالتأكيد بتعليقات المجتمع على الاقتراح في ذلك الوقت.

لقد انتهيت من كتابة مسودة RFC وفتحت العلاقات العامة .

إنه مستند طويل جدًا ، ويرجع ذلك جزئيًا إلى أنه لا يزال هناك عدد قليل من الأسئلة المعلقة حول كيفية تقديم هذه الوظيفة للمستخدمين ولذا أحاول إبراز إيجابيات وسلبيات الأساليب المختلفة هناك. لكنني أعتقد أن أفكار التنفيذ قوية جدًا ، لذلك أود أن أسمع من الناس هنا إذا كان لديك تحفظات حول واجهة برمجة التطبيقات المقترحة التي تواجه المستخدم .

ملخص تنفيذي لـ RFC مع الإجابة على أسئلتنا الأساسية: https://maggiepint.com/2016/07/16/immutability-its-happening/

maggiepint حاولت نشر تعليق على تلك المقالة ، لكن لسبب ما تم ابتلاعها. هذا ما كتبته:

أكثر ما يقلقني بشأن هذه التغييرات هو أنها تستجيب لجزء غير متناسب من الصوت والتعبير من المجتمع - وتجنب الحصن الهادئ للمطورين العاديين الذين لا يدركون حتى أن هذه المناقشة تجري.

سلاسل GitHub ليست صورة مصغرة لمجتمع التنمية الأوسع. يعاني هذا الموقع من نفس تحيز المشاركة مثل العديد من المنتديات على الويب ، وهو منحاز لنوع معين من المطورين: ملتزم فكريا بنظرية الحوسبة ؛ مهتم بالأفكار بدلاً من التطبيقات ؛ وأجرؤ على القول إنني أميل اجتماعيًا إلى الالتفاف حول الاتجاهات الشعبية. ينجذب هؤلاء المطورون بشكل طبيعي إلى قضية فلسفية مثل الثبات والبرمجة الوظيفية ، ولديهم وصول أقرب إليك من أي مجموعة أخرى. سيكونون أعلى صوت في الغرفة ، وسوف يطالبون بهذا التغيير - لكن ماذا عن العالم الأوسع؟

العالم الأوسع يريد أشياء تعمل. يريد أن يعرف أن المكتبة التي تستخدمها حاليًا ستستمر في تلقي التحديثات - إصلاحات الأخطاء على الأقل ، ولكن من الناحية المثالية ، تحسينات تدريجية صغيرة تجعل حياتهم أفضل. لكنها لا تقول ذلك ، لأنها لا تبحث بنشاط عن هذه المنتديات ، ولأن الأمر يتطلب جلدًا سميكًا للتحدث ضد هذا الاتجاه.

إذا كنت عازمًا على هذا التغيير ، فأعتقد أنك ستحتاج إلى تقديم حالة واضحة جدًا لهؤلاء الأشخاص عن سبب جعل هذا التغيير حياتهم أفضل ؛ لماذا يجب عليهم الترقية؟ لماذا لا داعي للقلق من أن مشاريعهم القديمة لن تتلقى إصلاحات أخطاء غير مباشرة ؛ وبشكل أساسي - ما الأشياء التي يمكنهم الآن القيام بها والتي لا يمكنهم القيام بها في الوقت الحالي.

أعتقد أيضًا أنه يجب أن تكون حريصًا جدًا على التحقق من أهمية هذا التغيير بالقيمة الحقيقية. أتساءل عما إذا كان يجب عليك تحرير هذا التغيير كمكوِّن إضافي أو مجمّع ، ومراقبة امتصاصه بعناية على مدار عدة أشهر قبل دمجه في صندوق البريد. إذا تم تمثيل الثبات بشكل مبالغ فيه باعتباره مصدر قلق متخصص ، فستجد طريقة لإرضاء هؤلاء المستخدمين الصوتيين دون تغيير مسار المكتبة ككل.

بصفتي مستخدمًا للمرة الأولى ، انتهيت هنا بعد ضياع بعض الوقت مع startOf endOf. هذه الأساليب تتغير بشكل مدهش!

+1 لثبات كامل

ربما يكون الحل الآخر هو توضيح أن الأشياء في Momentjs قابلة للتغيير بشكل مؤلم . تذكر الوثائق ذلك في قسم الاستنساخ ، لكنها ليست بارزة بدرجة كافية.

حل آخر ، إذا كنت تريد قابلية التغيير ، استخدم مفاهيم Object Oriented وأنشئ إنشاء كائن باستخدام الكلمة الرئيسية NEW vs the moment () نمط المصنع.

العالم الأوسع يريد أشياء تعمل.
... ستحتاج إلى تقديم حالة واضحة جدًا لهؤلاء الأشخاص عن سبب جعل هذا التغيير حياتهم أفضل

كل شخص رأيته جديدًا في اللحظة يقع في فخ "اللحظات" التي تتغير.
حتى بعد 3 سنوات من استخدام اللحظة ، لا يزال يتعين علي أن أقول لنفسي "يا إلهي ، أنت تستخدم. ابدأ هنا .. تحقق أفضل مرتين إذا كنت بحاجة إلى نسخة".

السلوك الحالي ليس بديهيًا وهذا ما طال انتظاره.
حاول أن تجعل array.filter / map يتغير وانظر إلى أي مدى يكون ذلك ممتعًا.

بخصوص...
الأداء / الذاكرة: لم أقم مطلقًا بتقييد أكثر من 2 funcs في الوقت الحالي وعادة ما يكون .set().get()
الثبات الزائف: سيستغرق الأمر عدة أجيال عديدة حتى يتم إخراج java-pass-by-ref-gen.

تعجبني فكرة

سنتان حول سبب ارتباكنا هو هذا: القيم المرتجعة. إذا كان moment.add('1', 'days') يقوم بإرجاع غير محدد ، مثل الدوال القابلة للتغيير في JS بشكل عام ، فإن الالتباس سيختفي. إعادة الشيء نفسه ، بالنسبة لي على الأقل ، يعني أن لدي نسخة جديدة. بالطبع ، هذا من شأنه كسر قابلية التسلسل.

أعتقد أن هناك احتمالية منخفضة لحدوث مشكلات في استخدام الذاكرة لمزيد من المطورين (باستثناء حالات الاستخدام الخاصة). رغم ذلك ، فإن قابلية مومنت للتغير قد عضتني بالفعل. يجب التعامل مع التواريخ كقيم مثل سلسلة أو رقم.

+1 لا يتغير بشكل افتراضي

هذه المشكلة نفسها موجودة في PHP ، بالمناسبة. هل تريد أن تكون مثل PHP ؟! 😆

في PHP ، قاموا بحلها بتقديم DateTimeImmutable (بالإضافة إلى DateTime العادي).

إذا لم نغير السلوك الافتراضي ليكون غير قابل للتغيير ، فيجب علينا على الأقل التفكير في واجهة برمجة تطبيقات بديلة من الدرجة الأولى مثل imoment / momenti (أو أيًا كان). سأستخدم ذلك دائمًا حرفيًا (عبر واجهة برمجة التطبيقات القابلة للتغيير) وآمل أن أي مكتبة أخرى أستخدمها ستستخدم الإصدار / واجهة برمجة التطبيقات غير القابلة للتغيير أيضًا.

أنا أصوت لصالح الثبات أيضًا ، وأنا على استعداد للمساعدة في التنفيذ إذا كانت هذه هي الخطة. لقد واجهت بالفعل مشكلات في قابلية التغيير عند إجراء عمليات الجمع والاستبدال ، ما يجعل الأمر أكثر إرباكًا هو أن هذه الطرق تعيد المثيل بسبب التسلسل.

بالمناسبة ماذا عن مدد الاستنساخ؟ ما هي أفضل طريقة للقيام بذلك ، لا يمكن العثور على أي شيء لا يشعر بالاختراق.

ngerritsen أعتقد أن أفضل خيار متاح هو moment.duration(existingDuration) .

رد: التنفيذ ، # 3548 لا يزال علاقات عامة نشطة. نأمل ألا يكون هناك الكثير من العمل على مستوى الكود ، ولكن لا يضر أبدًا أن يكون لديك المزيد من العيون للتحقق من صحة التغييرات الكبيرة. نحتاج أيضًا إلى العمل على التوثيق وما إلى ذلك قبل أن نتمكن من إجراء تفريغ كبير للإصدار ، والذي سيكون ضروريًا لإصدار تغيير مثل هذا. إذا كنت ترغب في المساعدة في أي من هذه القائمة ، فأنا متأكد من أننا نقدر ذلك. 😀

أمضيت للتو ساعة في محاولة تحديد خطأ خفي تسبب فيه. to date-fns بسبب الطبيعة الدقيقة جدًا لهذا النوع من الأخطاء ولأنني بعد تقديمي لبعض مفاهيم FP العامة (غالبًا بفضل React و Redux و ELM) بدأت في تقدير الفوائد العامة للثبات.

لما يستحق ، اتبعت لوداش بالفعل نهج 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

مثل هذه الخطوة يمكن أن توجه أيضا مناقشة الثبات. أود أن أقول إن جميع الطرق يجب أن تكون ثابتة مع استثناء واحد. طريقة تسمى .set('minute/hour/year/etc', 18) .

لقد بدأت للتو في استخدام Moment ، وتم "إجازة" أن هذه المكتبة لم تكن ثابتة تمامًا منذ البداية. أنا أستخدم لحظة غير قابلة للتغيير حتى يتم إصلاح ذلك.

ربما لن تتغير لحظة alancnet أبدًا. إنه تغيير كبير للغاية وهناك رد كافٍ من المستخدمين الذين تعلموا تبني السلوك الحالي.

تحقق من مشروعهم الجديد: luxon
إنه لطيف للغاية ، وحديث ، وغير قابل للتغيير (!) ويجب أن يؤدي بطريقة أفضل من الثبات اللحظي الذي يلف كل شيء في مكالمات .clone() .

بالنسبة لأولئك الذين يرغبون في الانتقال من Momentjs إلى نهج حديث ، يرجى مراجعة https://github.com/you-dont-need/You-Dont-Need-Momentjs

مندهش جدا أنه قابل للتغيير!

إلى أي مدى يجب أن

alamothe تمت الإجابة على هذا السؤال بوضوح على الموقع: https://moment.github.io/luxon/docs/manual/moment.html

إغلاق هذا. كما أشار آخرون ، استخدم Luxon إذا كنت تريد واجهة برمجة تطبيقات غير قابلة للتغيير في الغالب. شكرا.