Pull to refresh

Comments 90

>> var halloween = moment([2011, 9, 31]); // October 31st

Юзабельно блин…
Я не на формате заострял внимание, а на то, что как и в стандартном Date отсчет месяцев ведется с 0, а дней с 1. То есть никакого улучшения тут библиотека не привнесла.
Стандарты лучше не ломать, даже если они кривые (
Тогда какой смысл в обертке? Стандартный класс даже локализацию умеет.
Ну не заменой нумерацией месяца живы )
Не знаю, я уже привык, мне теперь месяц с единицы начинать — не юзабельно :)
9-й месяц — сентябрь, а не октябрь, как это отмечено в комментарии к коду.
Речь о строке:

var halloween = moment([2011, 9, 31]); // October 31st
Расширением встроенных классов как минимум.
А вы можете назвать хотя бы один аргумент (именно аргумент, а не религиозную чушь) против этого?
Да без проблем.
Например если человек видит
var now = moment();
console.log(now.format('dddd, MMMM DD YYYY, h:mm:ss'));

и
// Set to 8:30 AM on the 15th day of the month
Date.today().set({ day: 15, hour: 8, minute: 30 });

Во втором случае явно видно использование сторонней библиотеки.

Для меня этого достаточно.
Прошу прощения — в первом случае.
явно видно использование сторонней библиотеки.

И что? Какая разница, библиотека добавляет свойство в объект window или в объект Date?
Различия в ожидании поведения объектов.

Например на текущем проекте болталось две либы: datejs и еще одна, которая расширяет свойства. В итоге вычленять этот мэшап из разных частей кода вышло достаточно затратно.

Или же например получая method not defined у Date можно долго чесать затылок ища этот несуществующий метод в ECMA.
Всё равно аргументы непонятны. Если либа подключена, то где взялся «method not defined»? Если не подключена, то тем более.
Я говорю о том что если не подключена то найти проблему будет сложнее.
И что? Какая разница, библиотека добавляет свойство в объект window или в объект Date?

Это с точки зрения семантики — никакой.
С точки зрения расширения существующего класса или добавления нового в контекст global есть.

Вообще странно видеть подобные вопросы от человека, который ищет js разработчика.
И кстати хотелось бы увидеть встречные доводы, а то сейчас я вижу какие-то нонконформистские высказывания без обоснования.
Вы бы ещё мои топики почитали, перед тем, как судить негативно.
Просто я до сих пор не видел ни одного серьёзного аргумента против расширения прототипов.
Все какие-то религиозные.

Это удобно, быстро, коротко. Это соответствует всей идеологии JS. Этим пользуются все JS фреймворки. Даже jQuery, хотя и не расширяет встроенные прототипы, но плагины для него пишутся именно расширением прототипа.
Это не религия. Это здравый смысл для больших проектов.
Вы используете «быстро и коротко» здесь и сейчас, рискуя напороться на грабли позже.
Как минимум лучше сделать класс-наследник и работать с ним. Или как в либе топика оберткой.
И лучше не путать плагины с классами. Это совершенно разные вещи.
Именно, JS ведь не компилируемый (в IDE), это не Java где можно двумя кликами отследить всю иерархию наследования и вызовов любых методов, тут в илеале нужно держать всю иерархию в голове, а это не всегда возможно.

Как минимум 2 аргумента:
— Более явный вызов расширенных методов, легче отслеживать, рефакторить.
— Гарантия отсутствия «конкурирования» за одноименный методы/поля при подключении разных библиотек

Мне приходилось рефакторить веб часть больших проектов (JEE/J2EE), и я вполне понимаю и принимаю приведенную аргументацию.
Не соглашусь с вами. Расширять встроенные типы можно, но не все, например прототип Object я бы трогать никогда не стал, прототипы DOM элементов тоже. А, например, Data и Array вполне успешно поддаются расширению.

А чесать голову при ошибке не придется, т.к. достаточно взглянуть на список методов в mdn, да и небольшой он, чтобы в нем путаться. В этом случае not defined на родном объекте ничем не отличается от такого же сообщения на любом другом.
Думаю что опытный проектировщик / архитектор / просто разработчик (в exUSSR бывает что это одно лицо) основываясь на своем и чужом опыте не станет использовать (только по той причине что «так сделать можно» и что так проще и быстрее) конструкции/методы/приемы/структуры которые по своей сути допускают проблемы.

Зачем изначально залаживать в разработку приложения опцию «кому-то придется лишний раз смотреть в mdn, а то и не только в mdn» когда этого можно избежать. Да и not defined не единственная особенность, другая проблема в пересечении функционала, если утрировано то типа как запустить вместе Mootools и Prototype :)

Вопрос не только в том чтобы сделать, но и в дальнейшей поддержке/развитии проекта при условии что разработку ведут разные люди/команды. Каждый из этих разработчиков может захотеть добавить в проект своих плюшек модифицирующих базовые классы. При этом если этот разработчик (любящий расширять базовые классы) ответственный ему придется смотреть все другие «чужие» исходники и проверять и тестировать не будет ли его код конфликтовать с чужими расширениями базовых классов. Думаете кто-то пойдет на это, или лучше выберет путь автономных самодостаточных расширяемых модулей?

Пример. Начальство дает задачу интегрировать в проект уже готовый функционал из другого проекта (скопипастить по простому, не в отдельном фрейме). Первый основной проект использует Mootools, второй Prototype, интегрировать нужно за один день, у начальства ведь такое понимание что если готово где-то уже, то берем и приклеиваем без проблем, однако не вегда так получается. Пример немного притянут за уши, но смысл думаю понятен.

Разумеется в принципе расширять базовые классы можно, вопрос в том насколько разумно это делать.
Вы слышали про проблему Prototype.js и getElementsByClassName?
Слышал. Аналогично с .bind. И что? jQuery не расширяет прототипы, но всё-равно имеет обратную несовместимость и ломается в новых браузерах. Я уж молчу о том, что до сих пор большинство фреймворков работают не согласно спецификации querySelectorAll.

А старые версии некорректно работают в новых браузерах. У меня есть скрипты, которые плохо работают в IE9 из-за того, что в фреймворке, на котором я их писал не учтено, что может появится новый IE, который похож на остальные современные браузеры. А не могу перейти на новую версию из-за нарушенной обратной совместимости. И не в расширенных прототипах дело.

Да, мир меняется, вводятся новые стандарты, если код не поддерживать, то высока вероятность, что он не будет работать в новых браузерах. И расширение прототипов никак не меняет эту вероятность.
jQuery имеет обратную несовместимость с самим собой, это нормально. Вы контралируете обновление jQuery.

А насчёт «ломается в новых браузерах» я бы хотел цитату.
И даже если и правда иногда ломается, разумеется, расширение прототипов является дополнительным риском и меняет эту вероятность в большую сторону.
Как-то лениво вы пользуетесь поиском. Настоящая ссылка.

Этот баг — это баг. Т.е. разработчики допустили оплошность и потом исправили.
Баги с расширением прототипов — это неправильные архитектурные решения. Их исправить сложно.

К примеру, случилась такая проблема, как у prototype.js — что делать? Старый код зависим от старого поведения, а новый код (особенно, внешний) — от нового.
Как догадаться, какой метод нужен вызывающему коду?
UFO landed and left these words here
Да религия она такая, все крутится вокруг веры, понимать не нужно или невозможно. Но к счастью в JS религии дела обстоят немного по другому, некоторые адепты все же смогли постигнуть нирвану :)
Давай представим одну очень простую ситуацию.
1. Я(Самый умный, хозяин СВОЕГО кода) подключаю тебя(супер пупер библиотеку)
2. Ты расширяешь какие-то мои(МОИ!) прототипы.
3. Все падает.
Почему?
ответ: потому что я, самый такой умный, хозяин своего кода, кроме тебя подключил еще 10 библиотек, к тому же самостоятельно расширил интересные мне обьекты.
После чего пришол ты и часть моих изменений перетер.

Тут, так уж получается, лучше ум самому проверять тот же String.trim(Array.each\map\bind\....) на то что они native, а не просто есть.
Поддерживаю. Мне тоже не нравится когда всякие либы засерают встроенные классы. Готов мирится с теми что добавляют не хватающих методов браузерам типа старых IE (типа each и тд), то есть приводят поведение к некоторому стандарту, все остальное пихать в свои обертки (неймспейсы/замыкания).

Представьте что будет если всякая либа захочет расширять встроенные классы, одна, вторая, третья, и наступит неминуемый хаос, библиотеки начнут перетирать методы друг дружки меняя ожидаемое поведение, будет весело :)
Вы преувеличиваете. В тех же рубях все нормально с этим.
Рубисты на свой код пишут тесты чтобы избежать вышеуказанных проблем.

По поводу расширения прототипов vs заварачивания:

_(_(somethingsomething + _($(something)).pluck(_($(olo).attr(trololo)).detect(something)))))

может кому то нравится этот недо-лисп но я бы в своем проекте держал бы методы из underscore в прототипах.

Пишите бля тесты и не ссыте.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Это аргумент, чтобы конкретно не заниматься расширением прототипа Object
Приведите, пожалуйста, пример, когда все может развалиться, если расширен прототип Array
var a = [12, 14, 13, 6];
Аrray лучше пробегать так
for(var i = 0, i < a.length; ++i){
  console.log(i, a[i]);
}

это куда быстрей и не влечет тех проблем о которых вы говорите
ну на крайний случай так
a.forEach(function(v,i){
  console.log(i, v);
});
Ну у меня везде for разумеется.
Но этот вариант тоже имеет право жить.
PS Ваш второй вариант не работает без патчинга.
UFO landed and left these words here
Потому, что удобный вам синтаксический сахар предназначен для того, чтобы пробегать по свойствам объекта, а не по элементам массива, для второго есть forEach.
UFO landed and left these words here
for in — это, мягко говоря, не естественный способ обходить массив.
UFO landed and left these words here
No offence, но по личным наблюдениям виновато большое комьюнити и jQuery.
Куча дизайнеров, которым нужно допилить плагин или прикрутить мигающую штуку делают свое дело.
В питоне же средний уровень разработчика на порядок выше, и соответственно если ты просишь совета, то чаще всего тебе не только скажут но еще и в целом совета дадут по общей архитектуре.
Пример с тримом чудесный. Находясь в десятом замыкании (желательно, что бы в каждом было по пачке переменных) и вызывая трим в цикле можно наблюдать как яваскрипт ищет трим по всем областям видимости каждый раз. String расширять не сильно плохо, вот за Object надо мучительно убивать. А пихнуть в Date то что связано с работой с датой и нужно в синглтоне — вполне логично.
UFO landed and left these words here
Библиотека выглядит хорошо, актуально и разумно. Но вопрос переписывания всего кода проекта заставляет задуматься…
Ну я полагаю текущий проект — не последний ;)
Подумал о том же, то есть поменять библиотеку с Datejs (на то время ничего больше не попалось готового) на Moment. Проблема в том что Datejs расширяет встроенный класс и так просто отловить все ее добавки по всему проекту не получится (проект делался не одним поколением людей, и не все они были разработчиками судя по коду). Но в нашем случае весь «не стандартный» функционал либы Datejs используется только через свою обертку (типа CommonUtils.Date.format) так что поменять имплентацию на Moment не должно быть сложно :)
Читаю доки не вижу ни одного слова про таймзоны, а без них такие примеры типа такого

moment().add('hours', 1).fromNow()

выглядят наивно
В Вашем примере будет использоваться текущая зона (new Date()).
Проблемы будут когда будет использован массив

moment([2011, 11, 15, 17, 11]).add('hours', 1).fromNow()

Так как в документации сказано что используется как обертка для Date.UTC

А вообще да, думаю стоит завести тикет на более прозрачную обработку зон.
Хотя нужно глянуть исходники
Может на самом деле там корректная обработка всего этого, и им просто нужно добавить таймзону в их конструктор.
А мне в этом примере не нравится строка 'hours', я бы вынес в константы типа moment.HOURS, moment.MILLISECONDS и тд.
Надеюсь аргументации не попросят :)
Если используешь mootools (как я), то там есть чудесный класс для работы с датами, который покрывает любые потребности.
[irony]Только DOM, только хардкор[/irony]
Который является мутулзной оберткой над date.js. И, кстати, этот класс в mootools.more.
var halloween = moment([2011, 9, 31]); \\ October 31st
Октябрь — десятый месяц вроде?
Но удобнее было бы сделать в конструкторе, чтобы второй аргумент совпадал с номером месяца. Тогда меньше путаницы.
Это для удобства переименования месяцев
var month = ['января', 'февраля'...]
var date = new Date();
alert(month[date.getMonth()]);

Вот только мне действительно не понятно почему в стандартном классе Date, getMonth/Hour/Minutes — вернуть месяц/часы/секунды и т.п., а getDay — вернуть день недели. День месяца же возвращатся getDate — что переводится вернуть дату, что как-то глупо и не логично
Да прям уж…
var month = ['', 'января', 'февраля'...]
и все дела.
В JS есть всроенный объект для работы с датами. Зачем утяжелять все лишними билиотеками, тем более в которую заложено 30 языков, из которых используется только 1. Никогда этого не понимал.
> В JS есть всроенный объект для работы с датами.

Прибавьте 2 дня к текущей дате или вычислите разницу в днях между двумя датами, используя встроенный объект. Потом замените дни на недели, месяцы, годы.
Видно, что у автора данного топика по сочинениям в школе было 5.
Голые примеры и пару строк отсебятины.
Неплохо было бы написать, кто автор, когда он написал её, где используется в больших проектах (если используется).
Извините, ничего личного.
Мне такой вид топиков наиболее информативен. Предназначение, примеры, ссылки на документацию.
И так информации куча лишней отовсюду.
Сначала нужно получить представление о инструменте (именно эта информация и представлена), а потом уже если он (инструмент) заслужил и если будет необходимость или просто интерес (по поводу того что либа понравилась или наоборот) смотреть кто автор. Зачем нам лишняя информация. Авторитет или просто известность автора и популярность инструмента не всегда решают.
И почему встроенный Date этого не умеет? Что, редко приходится с датой работать в js? Маразм…
А за либу спасибо, выглядит юзабельн и всего пару кб.
Наболело. Хотелось бы, чтобы для всех языков и платформ использовался один стандарт пользовательских формат дат (e.g. yy, MM, mm ss tokens). Иногда необходимо интегрировать, к примеру, (JS) jQuery(foo).datepicker({dateFormat:bar}) с (.NET) HttpContext.Culture.DateTimeFormatInfo.ShortDatePattern. И тут въезжает на сцену серебристый велосипед, рама — карбон, 24 скорости. Если кто знает хороший и готовый подход, приветствую статью, буду плюсовать и в хвост и в гриву
Нехорошо, зачем вы меня вводите в заблуждение? Это всего лишь примечание, которое консорциум опубликовал для обсуждения в 1997 году и не одобрял его с того времени.

И содержит очень узкий набор возможных паттернов форматирования, не отображающих современные нужды.

Поддержки дат в формате ISO 8601 нету, жаль. Я вменяемый парсер ISO даты на Javascript так и не нашел, увы :(
Библиотечка хорошая, взял на заметку, спасибо.
Вас именно что именно интересует? Парсинг?
Ну так самому можно же массив для парсинга накидать за пару минут из вики.
Хотелось просто поддержки «из коробки». ISO стандарт достаточно многообразен, простой массив не пойдет.
Хочется чтобы нормально воспринимались форматы как, например 2011-11-15T22:34:42Z, так и 2011-11-15Т22:34:42+03, без лишних телодвижений.
Only those users with full accounts are able to leave comments. Log in, please.