Moment: 순간을 대부분 불변하게 하다

제 2센트는 우리가 완전한 불변성을 추구하거나 아예 하지 말아야 한다는 것입니다. 일부 메서드는 변경할 수 없고( startOf , add ) 일부 메서드는 변경되지 않습니다( year , get ). 어느 것이 어느 것입니다.

또한 기본적으로 변경 불가능한 모든 것을 선호합니다. getter는 이미 변경 불가능하지 않습니까?

다음은 불변성으로 전환할 때 볼 수 있는 큰 문제입니다.

의사 불변성

자바스크립트의 특성상 우리는 진정한 불변성을 가질 수 없습니다.

우리가 할 수 있는 최선은 복사본을 만든 다음 그 복사본을 변경하고 반환하는 것입니다. 우리는 모든 public 메소드를 조심스럽게 래핑하여 단순히 변경하는 것이 아니라 항상 복사하고 변경하도록 할 수 있지만 누군가가 m._d = new Date() 또는 m._d.setHours(1) 하는 것을 막지는 못합니다.

@icambron에 동의합니다. 불변으로 이동하면 완전한 변경이 되어야 합니다. 순간에 속성을 변경할 수 있는 모든 방법은 대신 순간의 복사본을 만들고 대신 복사본을 변경합니다.

API 표면적

의사 불변성으로 전환할 때의 불행한 점은 변경성을 계속 지원하려면 많은 새 API를 만들어야 한다는 것입니다.

이전에는 순간 변형에서 순간 복제 및 변형으로 전환하는 것이 올바른 위치에 .clone() 를 추가하는 것만큼 간단했습니다. 이제 우리는 모든 setter에 대해 변경 가능한 인터페이스를 생성해야 하며, 이는 API 표면적에 상당히 추가됩니다.

여기에는 ~20개의 setter 메서드, add/subtract, local/utc/zone/tz, startOf/endOf, lang 및 타사 플러그인에서 사용되는 기타 메서드가 포함됩니다.

메모리 문제

이제 값을 변경할 때마다 복사본을 생성하기 때문에 메모리 사용량이 증가합니다. 물론 새로운 순간은 가비지 수집되지만 이 변경과 관련된 추가 비용은 염두에 두어야 합니다.

우리는 다른 setter를 사용하는 방법으로 일회용 클론을 생성하지 않도록 많은 주의를 기울여야 합니다.

어떤 메서드가 호출되는지 추적하기 위해 이 작은 함수 래퍼를 사용했습니다.

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배 더 ​​빠르게 만들어야 합니다. 나는 이것이 불가능하다고 확신합니다.

요약

불변성으로 전환하면 내부 및 외부 API의 복잡성이 크게 증가하고 주요 성능 및 메모리 문제가 있습니다. 나는 그 비용이 불변성이 제공하는 이점의 가치가 있다고 생각하지 않습니다.

여기에 나열된 성능 문제가 요점을 놓치고 있다고 생각합니다.

일반적으로 돌연변이를 수행하기 전에 정확성을 보장하기 위해 초기 .clone()이 필요합니다.

현재 API에서 clone()이 필요하지 않은 것처럼 가장할 수 없습니다. 여기서 다른 주요 사례는 다중 순차적 돌연변이를 수행하는 것입니다. 이 경우는 모든 돌연변이가 단일 클론에서 돌연변이로 수행되도록 빌더 API를 생성하여 해결됩니다.

다른 일반적인 사용 사례가 누락되었습니까?

내 원래 문제는 startOf 및 endOf 메서드에 관한 것이었습니다. 어떤 이유에서인지 이 이름은 "이 순간을 한 달의 시작으로 설정"이 아니라 "한 달의 시작"과 같았습니다. add 및 subtract add 와 같은 메소드는 의미론적 의미에서 완벽하게 괜찮습니다. 새로 만들지 않고 개체에 무언가를 추가하는 것은 완벽합니다.
개인적으로 toStartOf 및 toEndOf 와 같은 startOf 및 endOf 메서드 이름을 toEndOf (예: "이 순간을 한 달의 시작으로 이동")으로 변경하면 문제가 해결됩니다. 문제. 임호

@gregwebs 죄송합니다. 위의 set 의미했습니다.

@soswow에 동의하지 않습니다. 일관성이 있어야 한다고 생각합니다. 사실 toStartOf 는 toISOString 대체 프레젠테이션을 제공하는 것처럼 불변성을 훨씬 더 강력하게 암시한다고 생각합니다. 더 중요한 것은 "Moments setters는 moment를 변경합니다" 또는 "Moments setters는 복사본을 반환합니다"와 같은 진술을 할 수 있어야 한다고 생각합니다.

@timrwood 의 우려 사항:

JS 객체가 진정으로 불변하지 않을 것이라는 사실은 나를 괴롭히지 않습니다. 요점은 API가 변경할 수 없는 계약을 제공한다는 것입니다. 물론 사용자는 밑줄 친 속성을 조작하여 속일 수 있으며 일반적으로 불변성이 작업을 수행하는 주요 방법인 언어에서도 속임수가 가능합니다.

표면적 및 성능에 대해: CPU와 메모리를 모두 사용하지 않으려면 내부적으로 mutator를 사용해야 한다고 생각합니다[1]. 그러면 어느 정도 지원해야 할 것입니다. 그런 다음 setYear() 등과 같이 외부에 노출할 수도 있습니다. 이렇게 하면 표면적이 많이 추가되지만 실제로 복잡성이 많이 추가되지는 않습니다. 비명시적 돌연변이자의 경우 외부적으로 복제하고 내부적으로 돌연변이합니다.

이를 보는 한 가지 방법은 사용자가 자신의 코드에서 복제해야 하므로 Moment가 사용자를 대신할 수 있다는 것입니다. 이는 성능에 민감한 위치에서 연결하는 데 문제가 있습니다. 이는 빌더 인터페이스(Greg의 아이디어에 따라) 또는 사용자가 거기에서 변경자를 사용하게 함으로써 싸울 수 있습니다. 빌더는 복잡함을 추가합니다[2]. 그래서 저는 명시적 mutator 대안을 선호한다고 생각합니다. 대부분의 경우 Moment는 성능에 민감한 상황에서 사용되지 않는 것이 현실이므로 그러한 상황이 API 측면에서 가장 편리할 필요는 없습니다. 필요할 때 성능 해치가 있는 멋진 불변 API를 사용하고 싶습니다.

[1] FP 랜드의 멋진 아이들은 _구조적 공유_로 이 문제를 해결하지만 여기에서는 아마도 비현실적일 것입니다.

[2] 전통적으로 사람들은 별도의 객체인 빌더를 만들지만 전체 setter API를 복사해야 하기 때문에 여기에서는 정말 장황합니다. 그냥 뱉어내지만 한 가지 대안은 .chain() 가 isBuilding 플래그가 설정된 복제 순간을 생성하는 것입니다. 그런 다음 내부 클론은 무시되고 돌연변이를 위해 객체를 반환합니다. 그런 다음 build() 플래그를 설정 해제하고 해당 복제본을 반환합니다. 문제는 깃발이 설정되면 게터가 피비린내 나는 살인을 외쳐야 한다는 것입니다. 그렇지 않으면 사람들이 갑자기 돌연변이가 되는 연결되었지만 구축되지 않은 순간을 사용하게 될 것입니다. 그런 다음 외부 및 내부적으로 호출되는 게터를 구별해야 합니다. 블레흐. 또 다른 대안은 빌더가 필요로 하는 기능을 내부적으로 믹스인으로 분해하여 빌더와 Moment 모두에서 사용하는 것이지만 코드 구성 관점에서는 작동하지 않을 수 있습니다.

나에게 효과가 있었던 것은 함수에 추가 매개 변수를 추가하는 것이었습니다. 변경 가능성을 나타내는 플래그(나는 self라고 함)는 기본적으로 불변(복사본 또는 새 객체 반환)이며, 성능을 감지하면 플래그를 true로 설정합니다.

이 입장은 많은 갈등을 해결했고,
거의 동일한 코드를 실행하는 유사한 이름을 가진 함수가 있는 경우
또는 성능 포인트를 감지할 때 함수 이름과 매개변수를 변경해야 합니다.
내 공개 메서드에서 복사본으로 함수를 호출하는 코드를 시작하고 플래그가 true인 다음 호출을 시작합니다.
이것으로 나는 또한 기능을 연결할 수 있습니다

내 코드에서 배열 배열(예: 테이블, 행 배열)로 작업합니다.
그래서 나는 이전에 결과와 함께 새 배열을 다시 실행하는 필터링, 통합 등의 기능을 가지고 있으며 최종 결과를 얻기 위해 동일한 기능을 여러 번 호출했음을 감지했습니다. 이제 첫 번째 호출은 복사본을 만들고 변경하지 않는 것입니다. 초기 배열 및 다음 호출에서 내가 필요하지 않은 동일한 배열 삭제 행으로 작업합니다.

여기에 있을 수 있는 기본 예:
moment.add = function(측정, 금액, 자체){
}

moment.add = 함수(측정, 금액, 자체) {
var $moment = 자기 ? this : this.clone();
// 실제 코드
$ 순간 반환;
}

2센트를 주신 모든 분들께 감사드립니다 :)

프로토콜의 경우 @icambron 의 모든 요점에 대한 마지막 게시물에 동의합니다.

두 가지 큰 질문이 남아 있습니다.

더 쉬운 것은 새 API가 무엇이어야 하는지, 두 가지 옵션입니다.
1.1 다른 이름의 메서드(변경 가능 및 변경 불가) year / setYear , startOf / setStartOf
1.2 또는 builder api chain().mutators().build() , @lfnavess가 제안한

빌더 API는 확실히 더 섹시해 보이지만 오브젝트가 빌드 모드에 너무 오래 머무르지 않도록 주의해야 합니다. 이는 우리와 사용자에게 또 다른 문제의 원인이 됩니다.

이제 어려운 문제는 새 버전으로 마이그레이션하는 것입니다. 여기에 두 가지 옵션이 있습니다.
2.1 개발자는 코드를 다시 작성해야 합니다(미친 정규식은 1.1에서 작동하고 1.2에서는 AST 수준 솔루션에서 작동할 수 있음 -- 아무도 자신의 메서드 이름으로 year 및 month 를 사용하지 않는다면). python은 이 접근 방식을 취했습니다. 결과를 모두 볼 수 있습니다. 완전히 새로운 언어가 탄생했습니다!
빌더 API를 항상 켜는 2.2 옵션(현재와 동일) 및 새 코드에 대해 이를 비활성화하는 방법. 이것은 더 _진화적으로_ 보이지만, 이로 인해 야기될 혼란의 정도는 아마도 가치가 없을 것입니다. 모든 순간에는 이제 두 개의 플래그가 있습니다. 변경 가능한지 여부와 변경 가능한 경우 -- 엄격하게 변경 가능한지(게터 없음) 또는 과도기적으로 변경 가능한지(getters ok). 함수에서 모멘트 객체를 받는 것은 말할 것도 없고, 모드가 무엇인지 확인하고 유지해야 합니다... 이 얼마나 엉망진창인지!

그리고 지금 나에게 온 미친 아이디어

Copy-On-Write 클론

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() 메서드에서는 이미 불변성을 지원합니다. |
| | 10배 빠른 |
| | 훨씬 적은 메모리 사용 |

불변성이 유용하다고 생각하지만 JavaScript에는 적합하지 않다고 생각합니다. 불변 인터페이스가 Elm과 같이 불변성이 예상되는 언어에는 의미가 있을 수 있지만 JavaScript의 경우 가변성이 예상된다고 생각합니다.

typeof a === "object" 내장 API의 대부분은 변경 가능합니다. Array#push,pop,reverse,sort,shift,splice,unshift 모두 새 배열을 반환하는 대신 배열의 내용을 변경합니다. Date#setX 메서드의 16개 모두 인스턴스를 변경합니다.

순간이 변한다고 불평하는 사람들을 많이 봤다고 생각하지만, 우리가 전환하면 불평하는 사람들도 그만큼 많을 거라고 생각합니다. 이것은 이미 2년 전에 eod/sod 메서드에서 발생했습니다.

변경 가능성에 대한 많은 오래된 문제를 살펴본 후 여기에서 내가 아마 깨진 레코드처럼 들릴 것입니다. 양측 모두 지난 몇 년 동안 제기된 동일한 사항입니다. 나는 단지 변경 가능한 API를 유지하기 위한 논쟁이 토론에서 표현되었는지 확인하고 싶었습니다.

@timrwood 좋은 비교이지만, 불변의 사용 사례를 이해하는 데 시간을

버그 비교도 유효하지 않습니다. momentjs는 연결 API를 지원하기 때문에 변경 불가능할 것으로 예상할 수 있습니다.

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

따라서 immutable과 mutable은 현재 동일한 문제를 가지고 있습니다. 연결 API를 제거하면 현재 변경 가능한 버전으로 이를 피할 수 있습니다.

따라서 함수 간에 순간을 안전하게 전달할 수 있기 때문에 변경할 수 없는 API가 변경 가능한 것보다 선호됩니다. 현재 변경 가능한 순간으로 기능 사이에 순간을 전달하면 2 가지 옵션이 있습니다.

1) 미친 버그 방식(아마도 가장 일반적임): 모든 소스 코드를 조사하여 원치 않는 돌연변이가 없는지 확인합니다. 원치 않는 돌연변이가 침투하지 않도록 단위 테스트를 작성하십시오.
2) 정상적인 방법(대신 모든 사람이 이것을 하고 있다고 가정하자), 방어적 프로그래밍: 내 함수에서 변경하기 전에 clone() 함수를 호출하는 것을 기억하십시오.

불변 API를 사용하면 매번 clone()을 호출하는 것을 기억할 필요가 없습니다. 대신, 우리는 복제를 피할 수 있게 해주는 API 함수를 호출해야 한다는 것을 기억해야 합니다. 그러나 이것은 정확성의 문제가 아니라 성능 최적화일 뿐입니다.

변경할 수 없는 사용 사례를 이해하는 데 시간을 들이지 않았다는 것은 분명합니다.

불공정한 발언입니다. 제 주장은 이점이 있지만 비용보다 중요하다고 생각하지 않는다는 것입니다.

함수 사이에 잠시 시간을 안전하게 전달할 수 있습니다.

우리는 클론을 호출하는 것을 기억할 필요가 없습니다

이것은 불변성의 사용 사례가 아닙니까? 내가 이해하는 데 시간이 걸리지 않은 것이 더 있다면 알려주세요. 그러나 이것은 지난 몇 년 동안 유일한 주장인 것 같습니다.

@timrwood 네, 그게 전부입니다.

그러나 귀하의 사례가 _against_ 불변성(끔찍한 성능, 변경 가능한 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 - 플러그인도 필드를 추가합니다(예: 여기 ).

이전 버전과의 호환성에 대한 강한 열망을 감안할 때 아직 경량을 유지하는 것이 가장 좋은 방법은 자바스크립트 소스를 분기하는 것입니다(이 프로젝트의 소스에서 또는 완전히 새로운 프로젝트를 시작함). 인터넷을 위한 1시간 이상의 도서관을 위한 공간이 있습니다.

또한: 구조적 공유에 대한 @ichernev 의 아이디어, 한 가지 가능성은 공유 상태 개체를 래핑하는 대신 프로토타입 상속을 사용하는 것입니다.

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 그것이 용도 입니다. 우리는 주요 버전을 충돌할 것입니다.

그러나 약간의 노력으로 구성 옵션으로 도입할 수 있습니다. "모든 것을 변경할 수 없습니까? True 또는 False"입니다. 기본값은 false입니다.

지원되지 않는 비공식 ymmv 불변 순간 플러그인: https://gist.github.com/timrwood/fcd0925bb779f4374a7c

ㅋ! 나는 훨씬 나중에 여기에 와서 더 불변 API에 대한 첫 번째 지지자 중 하나라는 것을 발견하고 놀랐습니다. :)

그리고 네, 저는 다음 메이저 버전의 불변성에 대해 +1입니다.

기본적으로 변경할 수 없는 순간에 대한 또 다른 +1입니다.
그리고 여기 내 '순간' 조합이 있습니다: https://gist.github.com/idrm/a91dc7a4cfb381dca24e (자신의 책임하에 사용하십시오!). 순간() 호출을 imoment()로 바꾸면 충분합니다. 모든 정적 moment.xyz()(예: moment.min(), moment.max() 등) 함수 호출은 그대로 유지되어야 합니다.

+1백만 달러

불변성을 위해 +1

또한 이 토론 스레드의 이전 제안에 +1을 추가하여 일부 기능의 이름을 더 쉽게 변경하여 읽을 수 있습니다("startOf"에서 "toStartOf", "add"에서 "plus", "month"에서 "withMonth) ", 등.)? 즉, 기본적으로 변경할 수 없는 경로를 사용한다고 가정합니다. 저는 Joda Time을 많이 사용하며, 예를 들어 "date.withDayOfMonth(1).withDayOfWeek(DateTimeConstants.MONDAY)"가 무엇을 의미하는지 쉽게 알 수 있습니다.
이것들은 메인 배포판 JS에 있을 필요도 없습니다. 바닐라 JS 위에 이것들을 추가하는 애드온도 잘 작동합니다(젠장, 나는 내 "순간" 모드와 결합하기 위해 그러한 Joda Time-aligned 애드온을 직접 작성하는 것을 강력히 고려하고 있습니다).

@ichernev , @icambron , 이것에 대한 결정을 내리셨습니까? 3.0에서 순간이 변경되지 않을까요? 그렇다면: 3.0이 언제 나올 것으로 예상하십니까? 나는 frozen-moment를 사용하거나 작은 래퍼를 직접 작성하는 것을 고려하고 있기 때문에 묻고 있습니다. 그리고 기다려야 하는지 궁금합니다.

참고로, frozen-moment는 최근 대부분 보류 패턴에 있었습니다. 업스트림 Moment에서 많은 PR을 이식했지만 해당 포크에서 이상적으로 발생해야 하는 다른 리팩토링에 대해서는 실제로 작업하지 않았습니다.

즉, 기본 영어 로캘만 필요한 경우 frozen-moment가 훌륭하게 작동합니다. (모든 것이 내 사용 사례에 적합하며 Moment의 높은 단위 테스트 범위를 유지했습니다.) 영어가 아닌 언어는 Moment의 최근 리팩터링된 로케일 API를 이식한 후 업데이트되지 않았기 때문에 깨졌습니다.

일단 Moment 3.0에 대한 결정이 내려지면 Moment의 불변성 작업이나 적절한 경우 frozen-moment 포크에 대해 좀 더 진지하게 작업할 계획입니다. 나의 초기 목표는 로케일 지원을 수정하고 Moment 3.0의 API와 기능 패리티를 유지하는 것입니다.

불변성을 위해 +1

불변성을 위해 +1. 또한 개체를 변경하는 format 메서드는 어떻습니까?

불변의 순간에 +1.js
아니면 moment.js의 포크? 불변의 순간.js? 이것은 확실히 획기적인 변화가 될 것이기 때문입니다.

:100:
이모터블을 해!

+1 요즘 불변성은 좋은 JS API에서 기대하는 것입니다.

:+1: 예, 우리는 이것을 매우 원합니다. 현재 우리는 .clone()을 도처에 뿌립니다.

+1 이것은 아주 좋은 개선이 될 것입니다

:+1: 모든 것을 변경할 수 없음

불변의 경우 +1

모든 것을 불변으로 만드십시오. 나는 now 변수에 대해 작업하기 전에 매 순간(now) 변수를 복제하는 것이 지겹습니다. 그리고 now는 다시 변경됩니다.

불변성을 위해 +1

나는 startOf('day') 가 변이할 것이라고 기대하지 않았을 것입니다. 내 응용 프로그램에 재미있는 버그가 발생했습니다.

나는 대부분의 moment.js 연산자가 가변성에서 어색하다는 데 확실히 동의합니다. mmnt.startOf('day') 은 mmnt 변경한다는 점에서 매우 직관적입니다.

나는 많은 루프와 날짜 비교가 있는 달력 유형 사용 사례에 moment.js를 사용합니다. 나는 clone() 성능 문제를 겪었고 그들은 끔찍합니다. 어떤 클론 어떤 변이 일부 제어를 갖는 것은 나에게 아마 다른 사람 필수적이다.
모든 곳에 clone() 가 있는 것이 처음에는 어색해 보일지라도 그것이 하는 일은 매우 명확하고 성능을 위한 리팩토링을 매우 쉽게 만들었습니다.

모든 메서드가 더 나은 API를 위해 내부적으로 clone() 맹목적으로 사용하기 시작하면 요점을 놓친 것 같습니다.

내 2¢ :-)

@jdurand 명시적으로 복제하는 것보다 명시적으로 변경하고 싶습니다.

@dsherret 나는 명시 적으로 아무 것도 신경 쓰지 않습니다. 내 주요 관심사는 매우 비용이 많이 드는 작업이므로 암시적으로 복제하지 않는 것입니다.
누군가는 setters가 복제된 복사본을 반환해야 하고 그것이 저를 두렵게 할 것이라고 언급했습니다. 매우 비효율적일 것입니다.

@jdurand 더 비효율적일 수 있지만 암시적 복제는 복제된 개체와 변경된 개체의 차이가 최종 사용자의 경험에 눈에 띄는 차이가 없는 대부분의 응용 프로그램에 도움이 될 것이라고 생각합니다. 대부분의 개발자가 한 번에 수천 개의 날짜 작업을 수행하지 않기 때문에 개발자의 용이성과 개발자 오류를 방지하려는 노력이 몇 밀리초보다 우선해야 한다고 생각합니다. 그렇다면 복제 대신 돌연변이를 원한다고 명시적으로 말할 수 있습니다.

참고: 이 변경으로 인해 성능이 약간 향상될 수 있다고 생각합니다... 예를 들어, 대신 과거의 변경할 수 없는 개체를 참조하고 이 개체에 대해 수행할 작업을 저장하여 복제를 제거할 수 있습니다(예: add(1, 'days') ). 결과는 .toString() , .format() , .toDate() , .day() 등이 호출될 때 연산을 실행하여 계산됩니다. 그것은 극적인 변화가 될 것이며 더 빨라지지 않을 수도 있습니다 ... 성능을 비교하기 위해 일부 단위 테스트를 수행해야 할 것입니다 (또한 코드를 본 적이 없기 때문에 고려하지 않은 다른 문제가있을 수 있습니다 복제 방법 이외의 moment.js에서).

@dsherret 나는 _builder_/_lazy_ 접근 방식을 좋아합니다. 돌이켜보면 아마 처음부터 이렇게 지어졌어야 했을 것입니다.
말씀하신대로 API 호환성을 염두에 둔 불변의 포크가 가장 좋을 것 같습니다.

2센트 더:

1. 성능보다는 편의성을 위한 모멘트가 명확하게 구축된 상황에서 성능에 대해 걱정해야 할까요? m.add('year',1)에서 '연도'를 구문 분석하는 것이 복제보다 훨씬 느리다고 생각합니다.
2. 전체 포크(다른 이름, 다른 문서)가 없는 한 2가지 버전을 유지하는 것은 골치 아픈 일입니다. 나는 똑똑한 누군가가 같은 코드 기반에서 moment.immutable.min.js와 moment.min.js를 생성하는 아이디어를 생각해 내야 한다고 생각합니다...

언제부터 우리는 변화를 깨는 것을 두려워합니까? 현재 버전은 안정적이며 사람들은 코드 기반을 리팩토링하지 않고도 계속 사용할 수 있습니다.

두 개의 코드베이스를 유지하는 것은 고통스럽고 속도를 늦추며 변경 가능/불변 버전을 보유하는 것만으로는 가치가 없습니다.

그러니 완전히 불변하는 순간으로 넘어가서 메이저 버전을 범하고 끝냅시다 :댄서:

방금 이 라이브러리를 사용하기 시작하면서 이 스레드를 찾았지만 일부 코드를 디버깅하고 변경 가능한 예측할 수 없는 부작용으로 보이는 것을 처리하고 있었습니다. 완전히 변경할 수 없는 버전의 라이브러리를 보고 싶습니다!

뻔뻔한 플러그: 여기서 확고한 결정을 기다리는 데 지쳤습니다. 지난 며칠 동안 나는 Frozen Moment를 부활시키고 Moment 자체의 플러그인 역할을 하도록 다시 작성했습니다. 주말에 첫 번째 프리뷰 릴리스를 완료하는 데 도움을 준 @wyantb 에게 모자 팁.

Frozen Moment는 Moment처럼 작동하는 불변 유형을 제공합니다. 기본적으로 변경할 수 없는 버전은 Moment의 기능을 래핑하고 적절할 때마다 .clone() 를 호출합니다.

빌더 API를 좋아하는 사람들을 위해 Moment 자체를 빌더 객체의 아주 좋은 구현으로 생각하도록 도전하고 싶습니다! Frozen Moment는 우리 모두가 원하는 핵심 불변 유형과 변경 가능한 Moment에서 불변의 Frozen Moment를 구축하는 메커니즘을 추가합니다.

편리한 불변 API로 작업하고 싶은 분들을 위해 -- 저도 지원하려고 합니다. 아직 Frozen 인스턴스를 직접 빌드할 생성자를 만들지 않았지만 TODO 목록에 있습니다. 단기적으로 해결 방법은 moment().freeze() 또는 moment.utc().freeze() 모든 것을 만드는 것입니다.

Frozen Moment는 분명히 젊은 코드베이스이므로 몇 가지 거친 부분이 있을 수 있습니다. 하지만 여기 있는 누구라도 시도해 보고 예상대로 작동하지 않는 문제에 대해 문제를 제기할 것을 권장합니다.

아, 한 가지 더: 저는 아직 이것을 광고하지 않지만 Frozen Moment 인스턴스는 대부분의 Moment 플러그인에서 "그냥 작동"해야 합니다. 다른 모든 Moment 플러그인이 Frozen Moment 전에 등록되었는지 확인하십시오. 변경 불가능한 Frozen Moments에서 예상대로 작동하지 않는 플러그인을 발견하면 버그를 신고해 주시면 조사하겠습니다.

불변성 +1

불변의 경우 +1

아무도 Immutable JS 위에 순간을 구현하는 것을 보았습니까? JS의 불변성을 위해 최적화된 라이브러리이며 불변 객체의 변경되지 않은 부분을 재사용하여 메모리 문제를 줄입니다.

+1
나는 이것으로 인해 3년 된 버그를 수정했습니다: https://github.com/Saleslogix/argos-saleslogix/commit/87b35b22c1a42670da369701b15e2bdb3786cabc

그래서 사용자는 불변성을 요구하지만 핵심 팀은 그것을 하지 않을 핑계를 찾습니까? :NS
여러분, 이 변경은 ES6에서 코드를 다시 작성하는 것보다 훨씬 더 중요합니다. ^^ 현재 형식에서 API는 단순히 일부 메서드(필터, 연결 등)를 변경할 수 없는 JS Array와 비슷하지만 일부는 좋지 않습니다. 다른 것들은 하위 호환성에 대한 제약이 라이브러리보다 무한히 높다는 점을 제외하고는 (역방향, 정렬) 아닙니다.

+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 종류입니다."라고

그러나 우리는 moment.js가 GitHub에서 13번째로 가장 인기 있는 자바스크립트 저장소이고(전체적으로 24번째 ), bower.io에서 "moment"를 검색하면 111개의 일치하는 결과를 반환한다는 사실을 무시할 수 없습니다. 우리가 애플리케이션 빌더에게 불변 버전의 순간을 구현하는 점진적인 방법을 제공할 수 있다고 해도 종속성 간에 엄청난 혼란을 야기할 것입니다.

@ichernev 아마도 더 겸손한 제안: 순간 문서 페이지의 작은 부분을 변경성 대 불변성에 대해 이야기하는 데 할애할 수 있습니까? 주제에 대한 공식 입장을 간략하게 설명하고 주장에 대한 간략한 요약을 추가하거나 이 스레드에 대한 링크를 배치하거나 특정 토론 입력을 원할 경우 CTA처럼 작동할 수 있습니다.

현재 문서 페이지에는 "불변"이라는 용어가 언급되어 있지 않습니다. "moment immutable"을 인터넷 검색하면 이 페이지로 이동하지만 읽는 데 2시간이 걸렸고 해당 주제에 대한 귀하의 현재 입장이 아직 확실하지 않습니다. "순간 불변"에 대한 Google의 최고 히트가 순간 불변의 미래에 대한 빠른 답변을 주었다면 좋을 것입니다. :)

@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.
"때로는 변경 가능하고 때로는 변경 불가능"으로 인해 손실된 총 시간의 양은 상당히 클 것입니다.

그래, 진심으로 말이야. 누가 datetime 라이브러리의 성능에 신경을 쓰나요? 마치.. 정말? 사용자의 99.9%는 원격에서도 좋은 성능이 필요한 작업을 하지 않고 있다고 생각합니다. 일반적으로 두 개의 날짜 또는 최악의 경우 수백 개의 날짜를 처리합니다. 초당 수백만 개의 날짜를 처리하는 소수의 사용자는 최적화된 변경 가능한 API 포인트를 사용할 수 있습니다.

불변성은 유일한 정상적인 디자인 선택입니다. 불변 유형을 사용한 프로그래밍이 가변 유형보다 버그 발생 가능성이 훨씬 낮다는 여러 연구가 있습니다.

불변성을 위해 +1. 몇 시간이 걸렸습니다.

문제의 일부는 .startOf() 와 같은 메서드 이름이 기본 개체의 변형을 의미하지 않는다는 것입니다.

나는 Moment로 성능 병목 현상을 겪었으므로 이것이 때때로 발생할 수 있음을 확신할 수 있습니다.

그러나 나는 불변의 순간이 본질적으로 덜 효율적일 것이라고 확신하지 않으며 더 효율적일 몇 가지 경우를 상상할 수 있습니다.

이 논쟁은 오래 전에 Java 세계에서 해결되었습니다. 불변 날짜가 이겼고 가장 인기 있는 구현(JodaTime)이 결국 Java 8의 표준 라이브러리의 일부가 되었습니다.

Java 8의 LocalTime 은 "왜 우리는 _항상_ 하지 않았습니까?" 순간. 나는 기술을 거의 복음화하지 않지만 솔직히 말하면 변경 가능한 날짜 개체에 대한 장점을 볼 수 없습니다.

그래서, 예.... 이 스레드가 +1로 넘쳐나는 것이 싫지만, 문제의 진실은 Moment가 생성하지 않는 경우 다른 누군가가 불변 JS 날짜 라이브러리를 생성할 것이라는 점입니다.

나는 최근에 JodaTime API(예: Java 8 날짜)의 많은 부분을 JS로 이식한다고 주장하는 새로운 npm 모듈을 발견했습니다.

이것은 노드와 브라우저에 불변성, LocalDate 및 LocalTime과 같은 것을 가져올 것입니다.

Java에서 이러한 개념으로 작업한 후에는 다른 모든 것이 복잡하고 버그가 발생하기 쉽습니다.

링크?

2015년 12월 11일 금요일 오후 4시 30분 Andrew Schmadel [email protected]
썼다:

나는 최근에 많은 것을 이식한다고 주장하는 새로운 npm 모듈을 우연히 발견했습니다.
JodaTime API(예: Java 8 날짜)를 JS로 변환합니다.

이것은 불변성, LocalDate 및 LocalTime과 같은 것을 가져올 것입니다.
노드와 브라우저.

Java에서 이러한 개념으로 작업한 후에는 다른 모든 것이 kludge-y로 느껴집니다.
버그가 발생하기 쉽습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/moment/moment/issues/1754#issuecomment -163964349.

워트.
(모바일로 타이핑, 간결한 변명)

나는 아직 차임벨을 울리지 않았기 때문에 순간 3.0의 불변성에 찬성한다고 말할 것입니다. 주로 moment 와 같은 객체는 _value 객체_로 간주되므로 불변으로 구현하는 것이 가장 좋은 DDD 학파 출신이기 때문입니다.

상당한 성능 저하가 있더라도 여전히 해야 할 일입니다. 모멘트는 다른 사람의 디자인에 자연스럽게 맞아야 합니다. 직관적인 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 나는 이것이 이것이라고 가정합니다 : https://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는 아직 어리고 저자의 목표와 의도가 라이브러리에 대해 무엇인지 불분명합니다. 특히 그는 라이선스를 선택해야 하며 Joda Time 또는 JSR-310을 충실히 재구현하여 일반적인 JS 개발자의 요구 사항을 충족할 수 있는지 여부를 고려할 수 있습니다.

불변성을 위해 +1을 하고 결과적으로 더 정확한 코드를 만듭니다.

그것은 큰 노력이 될 것이므로 그것을 가능하게 할 (그리고 그렇게 해왔을) 사람들에게 진심으로 감사합니다.

Moment는 @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를 사용할 때 발견하는 버그를 수정하는 데 도움을 줄 의향이 있습니다. 그 버그가 제 것이든, 순간이 변경되지 않을 가능성을 전혀 고려하지 않은 다른 순간 플러그인이든 상관없이 말입니다. frozen-moment에 문제를 제출하면 살펴보겠습니다. 그리고 나는 여전히 정지된 순간과 같은 것에 대한 커뮤니티의 노력이 불변의 순간으로의 전환의 고통을 이해하고 완화하는 데 도움이 될 수 있다고 생각합니다.

1. moment가 3.0에서 불변성을 구현한다면, 누군가가 불변 3.x API 위에 mutable moment 2.x API를 구현하는 래퍼를 작성하고 유지 관리하는 것은 매우 간단할 것입니다. 개념적으로 이것은 실제로 frozen-moment와 매우 유사하게 보일 것입니다. frozen-moment가 암시적으로 clone() 모든 곳에서 이 가변성 래퍼는 대신 암시적으로 내부 참조를 새로운 불변 ​​모멘트 값으로 변경합니다. 이것은 또한 대규모 코드베이스에서 moment를 사용하는 사람들을 위한 전환을 쉽게 하는 데 도움이 될 수 있습니다.
2. 원하는 경우 잠재적인 문제에 대해 생각하고 순간 3에서 불변성을 구현하는 데 기꺼이 도움을 줄 것입니다.
3. js-joda는 BSD 라이선스를 사용하여 JSR-310 을 JavaScript로

@butterflyhug - frozen-moment를 만들어 주셔서 감사합니다! 나는 그것을 발견했을 때 기뻤지만, 지원이 중단되면 불변의 순간에서 변경 가능한 순간으로 변경하는 것이 내 코드에서 큰 일이 될 것이라는 점을 감안할 때 내 프로젝트에서 frozen-moment로의 종속성을 도입하는 것에 대해 걱정했습니다. 당신의 목표가 피드백을 받는 것이고 당신이 그것을 적극적으로 지원한다면 나는 그렇게 하는 것이 더 편합니다. :-)

얼마나 많은 다른 사람들이 같은 사고 과정을 겪었는지 모릅니다.

여기 사람들이 성능상의 이유로 Date 개체에 대한 종속성을 깨는 개념(또는 일종의 지연 평가 추가)과 함께 불변성을 탐구해야 한다고 생각하는지 궁금합니다.

@schmod에서 한 번에 한 단계씩 진행하는 것이 좋습니다. 이것은 이미 (분명히) 큰 변화입니다

@RobertMcCarter 넵, 불변성을 위한 일부 옵션이 핵심 라이브러리에 구현될 때까지/

불변성에 대해 +1, endOf()를 처음 사용한 후 내 앱에 무슨 일이 일어났는지 알아내는데 30분이 소요되었습니다. 문서를 주의 깊게 읽지 않았다는 점을 감안할 때 나는 그 이름을 가진 메서드가 예를 들어 endOf 월을 반환하고 순간 인스턴스는 영향을 받지 않는 상태로 둘 것이라고 가정했습니다. 솔직히 말해서 놀라운 일이며 이런 일이 일어나지 않는다는 것이 우스꽝스럽습니다. 또는 제 생각에는 대부분 변경 불가능한 API를 사용하는 것의 엄청난 이점에 제 머리가 너무 익숙합니다.

불변성을 위해 +1 :)

나는 불변성에 신경쓰지 않는다. 이 훌륭한 라이브러리를 그냥 내버려 둬라!

@es6Test 불변성에 동의하지 않는 근거는 무엇입니까? 변화에 대한 저항 외에 구체적인 이유가 있나요?

+1
내 코드가 .clone() 메서드로 가득 차 있고 때때로 변경 가능성으로 인해 버그를 찾기가 매우 어렵다면 변경할 수 없는 경우 라이브러리 사용이 쉬워질 것이라고 생각합니다.

+1 불변성을 높여주세요 ^_^

@danpantry 몇 가지 앱을 더 만들고 나서 생각이 바뀌었습니다. 나는 불변성을 선호한다.

그러나 여전히 일부 변수를 변경 가능하게 만들고 싶습니다. 저는 종종 순간에 며칠을 추가하고 결과를 유지하기 위해 더 많은 변수를 생성하고 싶지 않습니다.

@es6Test let 를 _정말_ 싫어하면 사용하시겠습니까?

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

저도 불변성에 찬성합니다. 이것이 Python의 datetime 라이브러리의 한 가지 기능으로 정말 빛을 발합니다. 문자열과 마찬가지로 개체를 수정하는 것에 대해 걱정하지 않고 개체를 던질 수 있습니다.

React/Redux 세계에서 불변성은 매우 중요합니다. 순간이 본질적으로 불변하지 않기 때문에 이미 몇 가지 짜증나는 문제에 부딪쳤습니다. 성능은 완화될 수 있으므로 여기에서는 관련이 없습니다. Facebook의 ImmutableJs 라이브러리는 성능 저하 없이 immutable을 수행할 수 있음을 증명합니다.

나는 또한 불변성에 대해 +1을 할 것입니다. 그때까지는 불변성의 이점을 얻을 수 없으므로 중간에 수행하는 것은 의미가 없습니다.

불변성과 함수형 프로그래밍은 그 어느 때보다 더 많이 사용되고 있습니다(그리고 저는 그것을 좋아합니다). 나는 이 이니셔티브에 기여하기 위해 시간을 할애할 것입니다. 기여자는 저에게 연락하여 제가 어떻게 도울 수 있는지 알려주세요.

우리가 많은 관심을 가지고 있었기 때문에 팀은 이에 대한 업데이트를 제공하고 싶었습니다.

현재 귀하의 우려 사항을 들었음을 알려드립니다. 전체 유지 관리자 팀은 우리가 처음부터 라이브러리를 작성한다면 변경할 수 없도록 선택할 것이라는 데 동의합니다. 그러나 지금은 그렇지 않습니다.

그대로, 우리는 다른 채널을 통해 순간을 얻는 데 의존하는 셀 수없는 수의 사용자와 함께 한 달에 4백만 개의 NPM 다운로드가 있습니다. 이 모든 사용자는 현재와 같이 변경 가능한 순간을 예상하는 코드를 가지고 있습니다. 또한 변경 가능한 순간에 의존하는 많은 플러그인이 있습니다.

코드는 작성하기 충분히 쉽지만 이러한 종류의 변경에 대한 지원 요구는 여가 시간에 이 작업을 수행하는 소규모 팀으로 수행하기 어렵습니다. 즉, 우리는 그것을 고려할 용의가 있습니다. 하지만 우리는 궁금합니다:

• 정지된 순간 플러그인이 요구 사항을 충족하지 않는 이유는 무엇입니까?
• 변경할 수 없는 API(항상 복제를 반환하는 API)만 필요합니까, 아니면 어떤 이유로 내부적으로 개체를 변경하지 않아야 합니까?
• 현재 코드에 변경할 수 없는 두 번째 API를 추가하면 요구 사항을 충족할 수 있습니까?

frozen moment 플러그인의 문제는 옵트아웃이 아니라 옵트인이라는 것입니다. 모든
moment() 는 변경할 수 없도록 .freeze() 가 필요합니다.

불변성의 요점은 객체 X가 있을 때
명시적으로 변경 가능하게 만들지 않는 한 변경되지 않아야 합니다.
하지 않고 내부적으로 객체를 변경할 수 있는 모든 공용 기능
명시적 변경이 문제입니다.

한 가지 해결 방법은 여러 가지를 수행하는 것입니다.

1. 현재 코드에 두 번째 변경할 수 없는 API 추가
2. 변경 불가능한 모드로 설정된 경우 전역 moment() 설정이 있습니다.
   생성된 moment() 인스턴스는 변경할 수 없습니다. 변경 가능한 호출이 시도되면
   변경되지 않고 대신 불변을 사용하기 위한 적절한 메시지와 함께 오류가 발생합니다.
   API 호출.

모두를 만족시킬 것이라고 생각합니다. 어떻게 생각하나요?

2016년 5월 23일 월요일 오후 12:11, Maggie Pint [email protected]
썼다:

우리가 너무 많은 것을 가지고 있기 때문에 팀은 이것에 대한 업데이트를 제공하고 싶었습니다.
관심.

현재 귀하의 우려 사항을 들었음을 알려드립니다. NS
전체 유지 관리자 팀은 우리가 라이브러리를
근본적으로, 우리는 그것을 불변으로 만들기로 선택할 것입니다. 그러나, 그것은 방법이 아닙니다
바로 지금입니다.

현재 상태로, 우리는 한 달에 4백만 개의 NPM 다운로드를 가지고 있습니다.
다른 사람을 통해 순간을 얻는 데 의존하는 셀 수 없는 사용자 수
채널. 이 모든 사용자는 다음과 같이 변경 가능한 순간을 예상하는 코드를 가지고 있습니다.
오늘이다. 또한 순간에 의존하는 많은 플러그인이 있습니다.
변하기 쉬운.

코드는 작성하기 충분히 쉽지만 이러한 종류의 지원이 필요합니다.
작은 팀이 우리의 여유 공간에서 이것을 하기 때문에 변화를 받아들이기가 어렵습니다.
시각. 즉, 우리는 그것을 고려할 용의가 있습니다. 하지만 우리는 궁금합니다:

• 정지된 순간 플러그인이 요구 사항을 충족하지 않는 이유는 무엇입니까?
• 변경할 수 없는 API(항상
  클론), 또는 어떤 이유로 내부적으로 진정으로 돌연변이를 일으키지 않아야 합니까?
  사물?
• 현재 코드에 변경 불가능한 두 번째 API를 추가하면
  필요?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/moment/moment/issues/1754#issuecomment -221062274

Gmail 계정의 Eric Lau

@maggiepint에 응답해 주셔서 감사합니다.

1. 고정 순간 플러그인과 관련된 몇 가지 문제: 기본값이 아니며 사용하려면 추가 작업이 필요하며 적극적으로 유지 관리될 가능성이 적습니다. 불변으로 구축되었습니다. 가장 큰 문제는 특히 많은 엔지니어가 있는 대규모 프로젝트에서 사용하는 것을 잊는 것입니다.
2. API는 부작용이 없어야 합니다. 복제본을 반환하는 것은 좋지만 원래 개체도 수정하면 부작용이 발생합니다. 다음 코드는 끝을 선언할 때 시작을 수정해서는 안 됩니다.

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를 사용하려는 사람들에게는 변경이 덜 필요합니다.

우리는 코드 부작용을 없애려는 모든 의도를 가지고 있습니다. 기본 패턴은 현재 함수에 연결하여 클론을 호출한 다음 해당 클론에서 작동하는 것입니다.

하지만 기술적으로 정말 변경할 수 없는 코드를 만드는 경우 개체는 변경되지 않는 값으로 구성되어야 합니다. 그렇게 하면 이 변경을 수행하는 데 어려움이 증가합니다. 클론을 호출한 다음 이전에 하던 일을 하는 것이 훨씬 쉽습니다.

나는 Drew의 아이디어를 두 번째로:

"순간/불변" 가져오기;
시작 = 순간();
끝 = start.add(10, '분'); // add의 불변 버전

그것은 불변의 옵트 아웃이고 변경 사항이 없기 때문에 좋을 것입니다.
함수 이름.

2016년 5월 23일 월요일 오후 12시 53분, Maggie Pint [email protected]
썼다:

우리는 코드 부작용을 없애려는 모든 의도를 가지고 있습니다. 기본
패턴은 현재 함수에 연결하여 클론을 호출하도록 하는 것입니다.
그런 다음 해당 클론에서 작업합니다.

엄밀히 말하면, 진정으로 변경할 수 없는 코드를 만들고 있다면 객체는
변경되지 않는 값으로 구성되어야 합니다. 그렇게 하면
그러나 이 변경을 수행하는 데 어려움이 증가합니다. 훨씬 쉽습니다
클론을 호출한 다음 이전에 하던 작업을 수행합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/moment/moment/issues/1754#issuecomment -221076796

Gmail 계정의 Eric Lau

@ericlau-솔리드

1. 변경 불가능한 모드로 설정된 경우 전역 moment() 설정이 있습니다.
   생성된 moment() 인스턴스는 변경할 수 없습니다. 변경 가능한 호출이 시도되면
   변경되지 않고 대신 불변을 사용하기 위한 적절한 메시지와 함께 오류가 발생합니다.
   API 호출.

페이지에 있는 2개의 라이브러리가 순간적으로 다른 동작을 예상하면 중단됩니다. 예를 들어 변경 가능한 순간을 예상하는 datepicker를 사용하고 자신의 코드는 변경 불가능한 순간을 예상합니다. 작동하지 않습니다.

변경할 수 없는 API 사용(얼라 얼어붙은 순간)

플러그인이 작동하지 않기 때문에 이것도 완벽하지 않습니다. 사실, 불변성을 도입하고 기존의 모든 플러그인을 기능적으로 유지하는 방법은 없습니다. 플러그인은 누군가가 작동하도록 시간을 보내기 전에는 전혀 작동하지 않거나 변경 불가능한 순간에 작동하지 않습니다.

"순간/불변" 가져오기;

따라서 이것은 기본적으로 유사한 인터페이스를 가진 다른 라이브러리를 제안하는 것입니다. 물론, 코드를 손상시키지는 않지만 혼란을 야기하고 일부 프로젝트에 2개의 버전이 설치되도록 만들 수 있습니다(예를 들어 datepicker는 변경 가능한 버전을 사용하고 코드는 변경 불가능한 버전을 사용합니다).

가장 좋은 방법은 API를 현재 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

다른 라이브러리는 아니지만 그렇습니다. 두 가지 별개의 고유한 유형의 순간이 있습니다. 변경 가능하고 변경할 수 없는 순간 개체가 "내부"에서 상당한 양의 코드를 공유한다고 가정하면 두 구문을 모두 사용해야 하는 개발자를 위해 라이브러리 크기를 크게 늘릴 필요가 없습니다. 애플리케이션이 하나의 구문만 사용하는 경우 트리 쉐이킹 을 사용하여 최적화된 빌드를 생성할 수 있습니다.

라이브러리를 분기하면 대부분의 개발자가 로드해야 하는 코드 크기가 잠재적으로 두 배로 늘어나 대부분의 웹 응용 프로그램에 바람직하지 않습니다.

플러그인이 "즉시 사용 가능한" 변경 불가능한 순간과 함께 작동한다고 가정하는 것은 좋은 생각이 아니며 합리적인 요구 사항으로 간주하지 않습니다.

또한 변경 가능한 API와 변경 불가능한 API가 동일해야 한다는 합리적인 요구 사항/가정이 아니라고 생각합니다. 우리는 업그레이드 경로를 가능한 한 매끄럽게 만들기 위해 노력해야 하지만 어색한 구문에 얽매여서는 안 됩니다.

또한 "불변" API가 어떻게 생겼는지에 대한 논쟁/논쟁의 여지가 많다고 생각합니다. 빌더 패턴? 생성자 인스턴스화? 가치 개체? 현재 API를 구현하지만 "setter" 메서드가 복제본을 반환합니까?

저의 한 가지 요청은 새로운 API가 우리가 작업하고 있는 어떤 순간에 대해 명확하고 모호하지 않아야 한다는 것입니다. IMO, freeze 는 해당 테스트에 실패하고 내가 잠시 지나갈 때마다 clone() 를 호출하는 것 외에는 거의 보호 기능을 제공하지 않습니다.

따라서 이것은 기본적으로 유사한 인터페이스를 가진 다른 라이브러리를 제안하는 것입니다. 물론, 코드를 손상시키지는 않지만 혼란을 야기하고 일부 프로젝트에 2개의 버전이 설치되도록 만들 수 있습니다(예를 들어 datepicker는 변경 가능한 버전을 사용하고 코드는 변경 불가능한 버전을 사용합니다).

별도의 라이브러리가 아니라 동일한 라이브러리를 둘러싸고 있는 얇은 래퍼일 뿐입니다. 한 가지 버전의 moment만 설치하면 됩니다. '순간/불변'을 가져올 수 있고 datepicker는 문제 없이 동일한 프로젝트에서 '순간'을 가져올 수 있습니다.

변경할 수 없는 순간을 처리하도록 업데이트되지 않은 경우 순간을 가져오거나 반환하는 플러그인과 인터페이스하는 데 문제가 있을 수 있습니다.

현재로서는 변경할 수 있는 것으로 취급하는 플러그인에 변경할 수 없는 순간을 전달한다고 가정해 보겠습니다. 플러그인이 업데이트 될 때까지 플러그인에 잠시 시간이 주어지기 전에 변경 가능으로 변환하는 방법이 필요합니다. 이상적으로는 프로젝트 메인테이너가 불변성을 지원할 시간을 가진 후에 더 이상 사용되지 않습니다. 또한 불변성을 감지하는 방법이 필요할 수도 있습니다(플러그인 작성자의 경우).

반대로 불변 인터페이스를 사용하도록 업데이트하고 사용자에게 불변의 순간을 반환하는 라이브러리는 불변을 사용하지 않고 불변의 순간을 기대하지 않는 사람들을 버릴 수 있습니다. 나는 이것이 더 이상 사용되지 않는 변환 방법으로도 처리할 수 있다고 생각합니다. 플러그인은 전달된 것과 동일한 유형의 순간을 반환해야 합니다.

@maggiepint 예, 귀하의 요점을 이해하지만 너무 큰 도약이라고 생각합니다. 개인적으로 나는 단순히 clone 가 커튼 뒤에 있는 접근 방식으로 괜찮을 것입니다. 특히 꼬임이 해결되는 동안.

@tacomanator 저도 하고 싶은 일입니다. 내부적으로 모든 것을 변경할 수 없도록 다시 실행하는 것은 그다지 유지하기 어렵습니다.
나는 단지 어떤 이유로 사람들이 그것을 원했는지 몰랐습니다.

@schmod freeze 가 명확하고 모호하지 않은 API라고 생각하지 않는 이유에 대해 간략하게 설명해 주시겠습니까?

함수 이름이 너무 귀여우면 Frozen Moment의 메서드 이름을 해당 저장소의 문제로 바꾸는 데 대한 논쟁을 고려해 보겠습니다. 반면에 변경 가능에서 변경 불가능으로(그리고 그 반대로) 변환하는 것이 가능하지 않아야 한다고 생각한다면 여기에서 약간의 토론이 필요할 수 있다고 생각합니다. 하지만 저는 Frozen Moment도 기꺼이 받아들일 의향이 있습니다. 그것이 더 나은 API가 될 것이라는 대략적인 합의를 얻는다면 그 방향으로.

@maggiepint 기본적으로 Frozen Moment의 일부 또는 전체를 핵심 라이브러리와 번들로 묶는 것으로 "현재 코드에 두 번째, 변경할 수 없는 API 추가"를 읽는 것이 맞습니까? 도움이 된다면 Frozen Moment 또는 그 아이디어의 일부를 순간 조직으로 마이그레이션하고(공식 플러그인 또는 핵심 라이브러리의 일부로) 새로운 컨텍스트에서 유지 관리를 돕겠습니다.

@butterflyhug @ichernev 가 생각한 것을 정확히 말씀하고

@butterflyhug

freeze 는 좋은 이름이라고 생각합니다. 순간의 _모든 단일_ 호출 후에 이 이름을 사용하는 것을 기억해야 한다는 것은 정말 짜증나는 일입니다.

나는 또한 import 'moment/immutable' 에도 같은 문제가 있다고 생각합니다. 잊어 버리기 쉽습니다.

솔직히, 당신은 semver를 따르고 있습니다. 올바른 접근 방식은 모든 것이 _기본적으로_ 불변을 사용하도록 하고 이 변경 사항을 자체 주요 버전으로 릴리스하는 것이며 일정 기간(12개월?) 후에 더 이상 이전 버전을 지원하지 않을 계획입니다. 새로운 기능/수정 사항은 변경 가능한 버전을 사용하는 사용자에게 제공된 마이그레이션 계획과 함께 변경 불가능한 트랙과 변경 가능한 트랙 모두에 병합될 수 있습니다.

앞서 언급한 12개월 후에 이전 버전은 _여전히_ 작동하지만 TLC를 받지 않습니다.

물론 이것은 많은 오버 헤드이지만 이전 버전과의 호환성을 위해 변경하려고 시도하는 것보다 올바르게 변경하는 것이 더 낫다고 생각합니다. 또한 변경을 훨씬 더 복잡하게 만들어 핵심 개발 팀의 관심을 끌 수 있습니다. 몰라.

이 접근 방식의 또 다른 잠재적인 단점은 사용자가 CDN에서 이 스크립트를 사용하고 명시적 버전을 지정하지 않는다는 것입니다(어떤 이유로든). 이로 인해 이전 버전과 호환되는 API가 출시되면 사이트가 중단될 수 있습니다. 내가 말할 수 있는 것은 "당신에게 그렇게 말했어요."라는 말뿐이지만, 이것이 현재로서는 받아들일 수 있는 위험이 아닐 수도 있다는 점을 이해합니다.

동일한 라이브러리의 두 가지 버전을 갖는 것은 전역 개체에 의존하고 freeze() 계속 사용하는 것 외에는 실제로 깔끔한 방법이 없는 경우에만 문제가 됩니다.

TLDR은 해결하려는 문제가 이미 사용 중인 semver에 의해 해결된 것처럼 들립니다. 그냥 사용해야 하는 대로 사용하지 않는 이유는 무엇입니까? 주요 변경 사항에 대한 주요 버전입니다. 이것이 중단되는 유일한 경우는 전역 moment 변수에 의존하고 CDN을 사용하는 경우이지만 여기서 변경하면 어쨌든 중단됩니다.

내 투표는 semver 및 불변 3.0 릴리스에도 있습니다.

나는 freeze 이름에 반대하지 않지만, 순간이 고정되어 있는지 여부에 대해 안전한 가정을 하는 것이 어렵다는 것이 본질적으로 문제가 있음을 발견했습니다. ( Object.freeze() 에 비슷한 문제가 있습니다.)

불변의 순간은 동결되지 않아야 하며, 동결 여부에 대해 의심의 여지가 없어야 합니다. 이것은 빌더 패턴의 엄격한 변형을 통해 수행될 수 있습니다(예: .build() 가 호출될 때까지 _only_ 객체에는 setter가 있고 그 후에는 _only_에 getter가 있습니다). 모든 setter가 복제본을 반환하여 인스턴스화됩니다.

예를 들어:

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

첫 번째 예는 자바와 매우 유사하지만 모멘트가 어떻게 구성되고 모멘트로 무엇을 할 수 있는지에 대한 모호함이 거의 없습니다. 또한 오버헤드가 거의 없는 새로운 모멘트를 구성할 수 있는 효율적이고 직관적인 경로를 제공하며 현재 대부분의 사람들이 모멘트를 사용하는 방식을 밀접하게 따릅니다.

빌드된 모멘트의 설정자가 예외를 throw하도록 하면 이 동작이 모호성을 더욱 줄이고(자세한 내용을 희생하면서) 개발자가 새로운 모멘트를 생성할 때마다 인정하도록 강제하기 때문입니다.

두 번째 예는 많은 개체를 생성(및 폐기)하고 있기 때문에 훨씬 더 많은 오버헤드가 있는 것처럼 보입니다. 그러나 최적화의 여지가 많습니다. 현대 GC는 꽤 좋습니다. 게으른 평가가 도움이 될 수 있습니다. Moment 객체를 가능한 한 가볍게 만들 수 있습니다(기본 Date ). (비교를 위해 이 패턴은 JavaScript에서 문자열을 처리하는 방식과 다르지 않습니다)

저는 semver의 팬이지만 브라우저 사용 사례는 변경 사항을 문제로 만듭니다. 왜냐하면 모듈 로더 없이 같은 페이지에 두 가지 버전의 moment가 있을 수 없기 때문입니다.

앞서 언급했듯이 Moment에 의존하는 _많은_ 레거시 코드가 있습니다. 최소한 원활한 전환 기간을 허용하려면 두 패턴을 모두 지원하는 릴리스가 필요합니다.

새로운 순간을 반환하는 구성 가능한 메서드의 경우 +1입니다. 나는 그것들이 불변인지도 상관하지 않는다. 구성을 제공하면 메서드를 함께 연결하거나 한 줄(2개 대신)에 변형된 순간을 할당할 수 있습니다.

@alexyuly 복제가 작동하지 않는 이유는 무엇입니까? 인라인으로 작성하려면 다음과 같이 할 수 있습니다.

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

또는 무엇이든.

@maggiepint 글쎄요, 저는 어리석은 것 같습니다. 당신이 모든 방법을 구성할 수 있을 것 같습니다. 팁 고마워. 문서에서 조금 더 명확하게 만들 수 있습니까? 예: http://momentjs.com/docs/#/manipulating/start -of/ <- 반환 값에 대한 언급 없음.

약간의 업데이트 - 이 블로그 게시물은 현재 이 문제에 대한 내 입장입니다: https://maggiepint.com/2016/06/24/why-moment-js-isnt-immutable-yet/

나는 나머지 팀에 대해 말하지 않지만 그들은 그것을 보았고 일반적으로 우리 모두가 비슷한 위치에 있다고 말할 것입니다.

@maggiepint 훌륭하고 매우 유효한 포인트

감사합니다. redux에서는 불변성이 왕이므로 js-joda로 확실히 전환하겠습니다. 나는 상대적인 시간을 위해 여전히 순간을 유지할 수 있습니다.

에릭 라우 - Gmail

2016년 6월 24일 금요일 오전 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 인스턴스를 Redux 상태 개체에 전혀 넣지 않기 때문에 이것이 놀라울 정도로 작은 문제라는 것을 알았습니다. 날짜 문자열 또는 타임스탬프만 렌더 메서드에서 Moment를 사용하여 날짜 문자열을 다른 문자열로 변환합니다.

내가 이 작업을 하는 이유는 추가 작업 없이 상태를 직렬화 및 역직렬화하는 것이 쉽기 때문이지만 또한 React 및 Redux에서 돌연변이를 멋지게 숨길 수 있습니다.

이번 주말에 이 업데이트를 제공하기 위해 최선을 다하고 있습니다. 계획이 있지만 실행하기 전에 모든 것이 제대로 진행되는지 확인해야 합니다. 유감스럽게도 다음 주에 미니애폴리스에서 시애틀로 이사를 하기 때문에 시간이 조금 더디겠지만 앞으로 나아가고 싶습니다.

블로그 게시물이 여전히 트래픽을 받고 있다는 것을 알았기 때문에 더 큰 업데이트를 준비하기 위한 작은 업데이트입니다. 현재 Babel을 사용하기 위해 모멘트 빌드를 재작업 중입니다. 이것은 우리가 @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/frozen-moment#20에 대한 내 의견에 따라 정적 메서드를 고려합니다. RFC 리포지토리에 대한 PR을 열 때 RFC에 대한 링크를 여기와 해당 문제에 게시할 것이며 그 당시 제안에 대한 커뮤니티 피드백을 환영할 것입니다.

RFC 초안 작성을 마치고 PR을 열었습니다 .

부분적으로는 이 기능을 사용자에게 어떻게 제공할 것인지에 대한 몇 가지 해결되지 않은 질문이 있기 때문에 부분적으로는 상당히 긴 문서이므로 다양한 접근 방식의 장단점을 강조하려고 합니다. 그러나 구현 아이디어는 꽤 견고하다고 생각하므로 제안된 사용자 대면 API에 대해 예약이 있는 경우 여기 사람들의 의견을 듣고 싶습니다.

답변해야 할 주요 질문이 포함된 RFC 요약: https://maggiepint.com/2016/07/16/immutability-its-happening/

@maggiepint 해당 글에 댓글을 어쩐지 삼켜 버렸네요 . 내가 쓴 내용은 다음과 같습니다.

이러한 변경 사항에 대한 가장 큰 우려는 커뮤니티의 불균형적으로 목소리를 높이고 표현하는 부분에 반응한다는 것입니다. 이 토론이 진행되고 있다는 사실조차 모르는 일반 개발자의 조용한 방벽을 피하는 것입니다.

GitHub의 스레드는 더 넓은 개발 커뮤니티의 축소판이 아닙니다. 이 사이트는 웹상의 많은 포럼과 동일한 참여 편향을 겪고 있으며 특정 유형의 개발자에게 편향되어 있습니다. 응용보다 아이디어에 관심이 있습니다. 그리고 감히 나는 사회적으로 인기 있는 트렌드를 중심으로 결집하는 경향이 있다고 말할 수 있습니다. 이러한 개발자는 불변성 및 함수형 프로그래밍과 같은 철학적 명제에 자연스럽게 끌리고 다른 어떤 그룹보다 귀하에게 더 가까이 접근할 수 있습니다. 그들은 이 방에서 가장 큰 목소리를 낼 것이며 이러한 변화를 외칠 것입니다. 그러나 더 넓은 세상은 어떻습니까?

더 넓은 세상은 효과가 있는 것을 원합니다. 현재 사용하는 라이브러리가 계속해서 업데이트를 받을 것이라는 사실을 알고 싶어 합니다. 최소한 버그 수정이지만 이상적으로는 삶을 더 좋게 만드는 작은 점진적 개선입니다. 그러나 이러한 포럼을 적극적으로 찾지 않고 트렌드에 반대하는 목소리를 내려면 두꺼운 피부가 필요하기 때문에 그렇게 말하지 않습니다.

만약 당신이 이 변화를 의도한다면, 나는 당신이 이 변화가 그들의 삶을 더 좋게 만드는 이유를 이 사람들에게 매우 분명하게 설명해야 한다고 생각합니다. 업그레이드해야 하는 이유 레거시 프로젝트가 간접적인 버그 수정을 받지 않을 것이라고 걱정할 필요가 없는 이유는 무엇입니까? 그리고 본질적으로 - 현재 할 수 없었던 일을 지금 할 수 있습니다.

또한 이 변경 사항의 중요성을 실제 용어로 확인하는 데에도 매우 주의해야 한다고 생각합니다. 이 변경 사항을 플러그인 또는 래퍼로 릴리스하고 트렁크에 병합하기 전에 몇 개월 동안 주의 깊게 사용을 모니터링해야 하는지 궁금합니다. 불변성이 틈새 시장의 관심사로 과도하게 표현되어 왔다면 라이브러리 전체를 변경하지 않고도 이러한 보컬 사용자를 만족시킬 수 있는 방법을 찾았을 것입니다.

처음 사용자로서 나는 startOf endOf로 잃어버린 시간 후에 여기에서 끝났습니다. 이 방법들은 놀랍게도 돌연변이를 일으키고 있습니다!

완전한 불변성을 위해 +1

아마도 또 다른 해결책은 momentjs의 객체가 변경 가능하다는 것을

또 다른 솔루션, 가변성을 원한다면 객체 지향 개념을 사용하고 NEW 키워드 대 moment() 팩토리 패턴을 사용하여 객체 생성을 생성하십시오.

더 넓은 세상은 효과가 있는 것을 원합니다.
...이 변화가 그들의 삶을 더 낫게 만드는 이유를 이 사람들에게 매우 명확하게 설명해야 합니다.

내가 순간을 처음 목격한 사람들은 모두 "순간"이 돌연변이되는 함정에 빠진다.
3년의 사용 기간 후에도 여전히 "오 젠장, 여기에서 .startOf를 사용하고 있습니다. 복사본이 필요한 경우 두 번 확인하는 것이 좋습니다"라고 스스로에게 말해야 합니다.

현재 동작은 직관적이지 않으며 이는 오랜 시간이 지난 일입니다.
array.filter/map을 변경하고 그것이 얼마나 재미있는지 확인하십시오.

에 관하여...
성능/메모리: 순간에 2개 이상의 func를 연결한 적이 없으며 일반적으로 .set().get()
의사 불변성: java-pass-by-ref-gen이 종료될 때까지 많은 세대가 걸릴 것입니다.

나는 OOP 또는 불변성을 찾고 있는지 여부를 선택하는 것에 대한 @AdamHess 의 아이디어를 좋아합니다.

우리가 혼란스러워하는 이유에 대한 두 가지 센트는 이것이 바로 반환값입니다. moment.add('1', 'days') 가 JS의 변경 가능한 함수가 일반적으로 하는 것처럼 정의되지 않은 것을 반환하면 혼란이 사라질 것입니다. 적어도 나에게 동일한 객체를 반환한다는 것은 새 복사본이 있음을 의미합니다. 물론, 그것은 연결 가능성을 깨뜨릴 것입니다.

더 많은 개발자에게 메모리 사용 문제가 발생할 가능성은 낮다고 생각합니다(특별한 사용 사례 제외). 순간의 가변성은 이미 저를 물었습니다. 날짜는 문자열이나 숫자와 같은 값으로 처리되어야 합니다.

기본적으로 변경할 수 없는 경우 +1

그런데 PHP에도 이와 동일한 문제가 있습니다. PHP처럼 되고 싶습니까?! 😆

PHP에서는 DateTimeImmutable (일반 DateTime 추가)를 제공하여 문제를 해결합니다.

기본 동작을 변경할 수 없도록 변경하지 않으면 imoment / momenti (또는 무엇이든)과 같은 일급 대체 API를 고려해야 합니다. 나는 말 그대로 항상 그것을 (변경 가능한 API를 통해) 사용하고 내가 사용할 다른 라이브러리도 변경 불가능한 버전/API를 사용하기를 바랍니다.

저도 불변성에 투표합니다. 그것이 계획이라면 구현을 도울 의향이 있습니다. 덧셈과 뺄셈을 할 때 이미 가변성 문제에 부딪쳤습니다. 더 혼란스럽게 만드는 것은 이러한 메서드가 연결로 인해 인스턴스를 반환한다는 것입니다.

그런데 복제 기간은 어떻습니까? 그렇게하는 가장 좋은 방법은 해킹되지 않은 것을 찾을 수 없었습니다.

@ngerritsen 가장 좋은 옵션은 moment.duration(existingDuration) 입니다.

Re: 구현, #3548은 여전히 ​​활성 PR입니다. 코드 수준 작업이 많이 남아 있지 않기를 바라지만 큰 변경 사항을 확인하기 위해 더 많은 눈을 갖는 것은 결코 나쁠 것이 없습니다. 이와 같은 변경 사항을 릴리스하는 데 필요한 주요 버전 범프를 수행하기 전에 문서 및 기타 작업도 수행해야 합니다. 이 목록 중 하나라도 도움이 되셨다면 감사하겠습니다. 😀

.startOf()가 원래 날짜를 변경하여 발생하는 미묘한 버그를 식별하는 데 한 시간을 보냈습니다... 노고에 감사드립니다. momentjs는 JS를 위한 훌륭한 날짜 라이브러리를 빌드하는 방법을 보여주는 훌륭한 작업을 수행했지만 전환 중입니다. 이런 종류의 버그가 매우 미묘하기 때문에 그리고 (주로 React, Redux 및 ELM 덕분에) 몇 가지 일반적인 FP 개념을 소개한 후 불변성의 일반적인 이점을 이해하기 시작했습니다.

그만한 가치가 있기 때문에 lodash는 이미 lodash/fp를 사용하여 더 많은 FP 접근 방식을 따랐습니다. lodash/fp가 모든 것을 다시 작성하는 대신 기존 기능을 래핑하기 때문에 lodash/fp가 구현된 방식을 살펴보는 것이 좋습니다. Lodash 사람들은 또한 성능에 대해 매우 우려하고 있습니다.

나는 또한 @mull에 동의합니다. 진짜 문제는 이 경우 뿐만 아니라 더 일반적으로(예: jQuery) IMO에 몇 가지 큰 설계 결함이 있는 연결 API 때문입니다. 날짜를 변경하는 메서드가 정의되지 않은 값을 반환하면 나에게 더 좋을 것입니다(적어도 이것이 내가 작성한 코드에 적용하는 일반적인 규칙입니다)

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 를 확인

변경이 가능하다는 사실에 매우 놀랐습니다!

룩슨 은 대체품이 되기까지 어느 정도입니까? 내가 Moment.js를 사용하는 이유 중 하나는 시간대 지원입니다. 이것은 내 프로젝트에 필수입니다.

@alamothe 그 질문은 웹 사이트에서 명확하게 답변됩니다: https://moment.github.io/luxon/docs/manual/moment.html

닫습니다. 다른 사람들이 지적했듯이 대부분 변경 불가능한 API를 원한다면 Luxon을 사용하십시오. 감사 해요.