Комментарии 32
Если потратить 15 минут на чтение документации, поведение сразу становится ожидаемым и мутирует он именно там где это описано https://momentjs.com/docs/
Но никакое чтение документации не упростит использование библиотеки там, где требуются неизменяемые объекты. А это Knockout, React, Mobx, Svelte, возможно даже Angular, даже $mol...
momentjscom.readthedocs.io/en/latest/moment/01-parsing/12-moment-clone
В том-то и дело, что при работе с moment в перечисленных мною фреймворках и библиотеках писать clone приходится каждый раз, и если забыть это сделать — будет трудноуловимая ошибка. А в luxon получается на один clone меньше.
const mutableMethods = ['startOf', 'endOf', 'add', 'subtract']
const immutableMethods = ['clone']
const ignore = Symbol('ignore')
const immutableAPI = [
...mutableMethods.map(name =>
[name, function (...args) {
this[name + '_ORIGINAL_'](...args)
return this.clone()
}]
),
...immutableMethods.map(name =>
[name, function (...args) {
return immuteMe(this[name + '_ORIGINAL_'](...args))
}]
),
]
const immuteMe = object => {
for (const [name, fn] of immutableAPI) {
object[name + '_ORIGINAL_'] = object[name]
object[name] = fn.bind(object)
}
return object
}
// Вызываем вместо moment
export const immutableMoment = param => immuteMe(moment(param))
// Тесты
let today = moment()
console.log('normal: ', today === today.startOf('day')) // true
today = immutableMoment()
console.log('immutable: ', today === today.startOf('day')) // false
И в итоге получаем нечто, что работает не так как написано в документации, зато медленно? Не проще ли luxon взять?
Ну мне например не проще взять luxon, поскольку к методам moment я привык, мне проще было написать несколько строк кода. Но я почитаю про luxon, спасибо.
Тут проблема не в самом копировании, а в том как вы переопределяете у объекта все методы. Хоть бы прототип подменяли! (хотя эта операция тоже не самая быстрая)
Прототипом у создаваемого через moment() объекта является класс, используемый moment-ом, подмена в нем методов крайне не рекомендуется методологически. По хорошему можно унаследовать класс и делать на нем, но если проигрыш во времени копеечный (2 десятых секунды на 100 000 созданий и вызовов метода) — можно и так оставить.
"Весь объект" — это всего-то 11 приватных свойств. А подменить вам надо около 30 методов. Плюс вы зачем-то сохраняете оригинальные методы в объекте, а не в замыкании, отсюда ещё двухкратное увеличение их числа. 60 значительно больше 11, так что да — затраты на подмену методов, по моей оценке, превосходят затраты на клонирование объекта.
Кстати, в luxon используется всего 6 приватных свойств.
Ну а что ещё делать с setXXX-методами? Оставлять как есть что ли? Запрещать использовать?
moment().hours(20).minutes(0).seconds(0)
Возможен же такой код? Если при вызове каждого метода объект будет копироваться, это будет странно. Я бы подменил только сам set, но это все дело вкуса. Смысл был показать, что приспособить moment под иммутабельность недолго и не критичные потери производительности. 100% полагаю для программирования ничто.
В погоне за уменьшением размеров бандла библиотека с набором отдельных функций выглядит привлекательней монолитного класса. Особенно, когда в проекте просто необходимо форматнуть пару дат, пришедших с бэкенда. Именно размер заставил меня отвернуться от moment в сторону date-fns
Moment — это компактная JavaScript-библиотека
Ha-ha
Добавьте в следующий такой же обзор luxon и date-fns.
Заходил в ожидании новых, свежих, набирающих популярность библиотек. Получил список того что и 5 лет назад было, про Express так вообще.
может и не в тему, но: typescript, ts-node, webpack, mocha
Что тут есть из 2020? Всё это было и в 2017.
Встроенный мидлвар express.json() базируется на body-parser, его не нужно ставить отдельно
Интересное наблюдение. Если в 2008 русские ребята писали сами качественные статьи и ревьювили код индусских программистов, то в 2020 переводят статьи с английского языка, написанные индусами.
23 полезнейших Node.js-библиотеки, о которых стоит знать в 2020 году