Part of the problem is that moment would both mutate the underlying object and return the object.
const a = moment()
const b = a.add(1, 'second')
Both b and a are now the same object. I've lost a few hours to the design choice.Part of the problem is that moment would both mutate the underlying object and return the object.
const a = moment()
const b = a.add(1, 'second')
Both b and a are now the same object. I've lost a few hours to the design choice.Else: a.add(1, ‘second’).add(1, ‘day’).subtract(2, ‘minute’) would create 3 more objects that are not needed. Creating a new moment object is expensive, it happened to me to work with a lib that grew exponentially slow when using above N dates because they where constantly recreating moments instead of using them wisely so creating a new one on every operation would be quite bad.
That’s why the method .clone() exists, so you can declare that explicitly:
const a = moment()
const b = a.clone().add(1, ‘second’)
PS: don’t take RTFM as an offense, I just happen to like it a lot and we use it frequently at work, I don’t mean to be disrespectful towards you :)If `a` is mutated by the `.add()` method, then it should probably return void rather than returning a copy of the object.
Is the immutable DX still better in this specific example? Probably. But the above at least would help developers avoid the major footgun with mutability.