Комментарии 7
Просто не используйте эти модули. Пользуйтесь уже готовыми системами AMD, browserify, component.json, webpack, ES6-модули. Знать о таком подходе полезно, но в продакшн надо использовать только нормальным модульные системы, в которых уже отловили баги.
CommonJS модули стандарт де-факто. Component.json позволяет нивелировать разницу между commonJS и ES6.
CommonJS модули стандарт де-факто. Component.json позволяет нивелировать разницу между commonJS и ES6.
А если вам попалась замечательная статья Дмитрия Филатова, то помните, что ваша фирма не Яндекс. Т.к. для Яндекс.Карт действительно характерны особые кейсы в работе с модульной системой и создание собственного формата модулей оправданно. Однако это создает свои сложности в работе с модулями с другим форматом модулей типа CommonJS или AMD.
Если же вам модульная система нужна для создания своего мега-пупер фреймворка, который будет использовать другие модули, то обратите внимание на:
Ender
Если же вам модульная система нужна для создания своего мега-пупер фреймворка, который будет использовать другие модули, то обратите внимание на:
Ender
Все это было актуально 4 года назад. Сейчас, при наличии AMD/CommonJS, учить этому новичков, имхо, даже вредно.
Полезная статья, спасибо!
Я бы рекомендовал не заниматься ерундой с «изоляцией» пространств имён. Прям религиозный фанатизм.
1. Иногда всё-таки нужно залезть в потроха, потому что нужный метод не был вытащен в апи. И не надо рассказывать, что это нехорошо и я не должен этого хотеть. Мне нужно решить задачу здесь и сейчас, а не когда там разработчики библиотеки решат принимать мой патч ИЛИ НЕТ.
2. В целях дебага удобно опять же иметь доступ ко всем потрохам прямо из консоли, не занимаясь ерундой с расстановкой брейкпоинтов и исполнением своего кода в точке останова.
3. Тезис про то, что мы можем под Window в разных модулях понимать разные вещи — на самом деле очень вредный совет. Ибо легко запутаться, когда одна сущность в разных местах называется по разному и наоборот разные одинаково — лишняя путаница. Гораздо лучше, когда одна сущность имеет строго одно глобальное имя. Пространства имён рулят, «модули» не рулят.
4. Зависимости между модулями тут никак не отражены. Но если брать в пример попсовый RJS, то зависимости указываются как строки, являющиеся глобальным идентификатором модуля. Собственно какая разница, где будут глобально храниться все модули: в window или в require. Суть одна и та же.
5. У всех функций есть «отображаемое имя» — оно показывается в профайлере, консоли и вообще очень полезная штука при дебаге. Удобно, когда имя функции представляет из себя глобальный ее идентификатор. Например, при таком объявлении:
JSui.Div.prototype.title = function(){}
Имя функции будет «JSui.Div.prototype.title»
А при таком:
function getNewId(){}
Всего лишь «getNewId» и гадай потом из какого модуля эта веселая функция.
«one var statement» — антипаттерн, поработай с системами контроля версий и поймёшь почему.
«use strict» — разное поведение в разных браузерах. Нафиг оно надо. Защиту от протечек локальных переменных в глобальную область видимости обеспечит вам любой валидатор. Больше ничего полезного в этом стрикте нет.
Зачем заводить константы для литералов? Надо не для минификатора код писать, а для программистов. А умный минификатор может и сам сгруппировать одинаковые литералы в переменную.
В каждом файле у тебя лишних 8 строк копипасты. Я бы переписал эти монструозные divs.js и labels.js попроще:
//divs.js
this.JSui = JSui || {}
JSui.Div = function(){
…
}
//labels.js
this.JSui = JSui || {}
JSui.Label = function(){
…
JSui.Div()
…
}
1. Иногда всё-таки нужно залезть в потроха, потому что нужный метод не был вытащен в апи. И не надо рассказывать, что это нехорошо и я не должен этого хотеть. Мне нужно решить задачу здесь и сейчас, а не когда там разработчики библиотеки решат принимать мой патч ИЛИ НЕТ.
2. В целях дебага удобно опять же иметь доступ ко всем потрохам прямо из консоли, не занимаясь ерундой с расстановкой брейкпоинтов и исполнением своего кода в точке останова.
3. Тезис про то, что мы можем под Window в разных модулях понимать разные вещи — на самом деле очень вредный совет. Ибо легко запутаться, когда одна сущность в разных местах называется по разному и наоборот разные одинаково — лишняя путаница. Гораздо лучше, когда одна сущность имеет строго одно глобальное имя. Пространства имён рулят, «модули» не рулят.
4. Зависимости между модулями тут никак не отражены. Но если брать в пример попсовый RJS, то зависимости указываются как строки, являющиеся глобальным идентификатором модуля. Собственно какая разница, где будут глобально храниться все модули: в window или в require. Суть одна и та же.
5. У всех функций есть «отображаемое имя» — оно показывается в профайлере, консоли и вообще очень полезная штука при дебаге. Удобно, когда имя функции представляет из себя глобальный ее идентификатор. Например, при таком объявлении:
JSui.Div.prototype.title = function(){}
Имя функции будет «JSui.Div.prototype.title»
А при таком:
function getNewId(){}
Всего лишь «getNewId» и гадай потом из какого модуля эта веселая функция.
«one var statement» — антипаттерн, поработай с системами контроля версий и поймёшь почему.
«use strict» — разное поведение в разных браузерах. Нафиг оно надо. Защиту от протечек локальных переменных в глобальную область видимости обеспечит вам любой валидатор. Больше ничего полезного в этом стрикте нет.
Зачем заводить константы для литералов? Надо не для минификатора код писать, а для программистов. А умный минификатор может и сам сгруппировать одинаковые литералы в переменную.
В каждом файле у тебя лишних 8 строк копипасты. Я бы переписал эти монструозные divs.js и labels.js попроще:
//divs.js
this.JSui = JSui || {}
JSui.Div = function(){
…
}
//labels.js
this.JSui = JSui || {}
JSui.Label = function(){
…
JSui.Div()
…
}
Зачем делать из своей библиотеки дерьмо только ради того, что кому-то очень захочется залезть в потроха?
Очень надо — лезь в исходник, выноси в нужный метод.
Очень надо — лезь в исходник, выноси в нужный метод.
Полностью поддерживаю. Не надо превращать свою жизнь в боль. Одно дело, если ты пишешь для дяди и больше никогда не будешь редактировать свой код, другое дело, что ближайшие два года ты проведешь в обнимку со своим кодом со всей той грязью, что сделал.
Нарушение инкапсуляции это страшнейший смертный грех. Нужен метод? вынеси его в отдельный модуль. Тем более, что в npm есть практиччески любой модуль, который тебе нужен.
И конечно же надо использовать SinonJS для нормального покрытия кода тестами.
Нарушение инкапсуляции это страшнейший смертный грех. Нужен метод? вынеси его в отдельный модуль. Тем более, что в npm есть практиччески любой модуль, который тебе нужен.
И конечно же надо использовать SinonJS для нормального покрытия кода тестами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание модулей JS