Модульная система должна заниматься модулями и разрешением их зависимостей, а вместо этого я вижу нечто, подобное этому:
curl(['js!nonAMD.js'])
.next(['dep1', 'dep2', 'dep3'], function (dep1, dep2, dep3) {
// do something before the dom is ready
})
.next(['domReady!'])
.then(
function () {
// do something after the dom is ready
},
function (ex) {
// show an error to the user
}
);
Спасибо за ваше интересное мнение. Но, в плане общее решение/своя альтернатива, я выделяю три стадии развития разработчика:
1. Когда он не использует общие решения, не понимая зачем они, под каждую задачу пишет свою альтернативу. Как правило, на этой стадии альтернатива гораздо хуже общего решения.
2. Когда он понимает, зачем общие решения, и использует их.
3. Когда он понимает, чем его не устраивает общее решение, что можно сделать лучше, и он пишет альтернативу. На этой стадии альтернатива имеет гораздо больше шансов оказаться лучше, чем общее решение.
Есть еще, конечно, момент с исправлением существующих общих решений, но: это далеко не всегда возможно, у авторов общих решений есть свое видение, как правило. не совпадающее с твоим; не всегда вообще можно общее решение доработать без потери обратной совместимости; и, что вообще не любят разработчики, надо потратить уйму времени на разговоры и объяснения, часто безрезультатные. Возможно, это 4-я стадия :)
А почему, то что ymaps это какой-то особый модуль должен знать именно потребитель этого модуля? Мой посыл в том, что все особенности модуля должны быть в самом модуле, а никак у его пользователей.
Не может ymaps сразу ничего вернуть, он использует дозагрузку своих собственных модулей.
Да и не нужна асинхронность, там где она не нужна, извините за тафтологию. Не нужно пользователю класса ComplexLayer знать о том, откуда и как он берется, вроде это очевидно. Если мне нужно написать:
var complexLayer = new ComplexLayer();
я должен так и писать, а не делать странные вещи типа:
var complexLayerPromise = ComplexLayerClassPromise.then(function(ComplexLayer) {
return new ComplexLayer;
});
и все последующие методы complexLayer звать только через промисы.
Я не уверен, что такая доработка будет обратносовместима со всеми инструментами вокруг AMD.
Плюс, в YM еще есть несколько отличий от AMD, которые на рассмотрены в статье, но для нас являются важными, например возможность додекларации/передекларации существующих модулей.
Ну это же очень странно. с точки зрения пользователей ComplexLayer, они все должны будут знать, что им не класс предоставляется, а какой-то промис, который будет зарезолвлен потом классом. Это, мягко говоря, неудобно.
выглядит так, как будто автор не делал анализ существующих решений.
Все модульные системы из статьи (CommonJS, AMD) я использую и использовал (собственно, для NodeJs алльтернативы CommonJS и нет), и именно из-за их недостатков была и сделана YM, а не потому что надо было сделать очередное «свое». Если бы хоть одна отвечала нашим потребностям, я бы никогда не стал писать свое.
Вы указываете в конфигурации AMD-загрузчика, что модуль ymaps находится под таким URL (map.yandex.ru/api/...) потом ComplexLayer просто его указывает в зависимостях и использует (прям как у вас в коде).
А вам не кажется, что это усложнение модульной системы? Более того тут есть нарушение принципов модульности, так как помимо самого модуля, мне еще что-то куда-то нужно дописывать.
И можно, все-таки, код увидеть? Как там обрабатывается, допустим, ситуация с ymaps.ready, которая наступает позже загрузки самого апи?
По URL config.hosts.ymaps + '/2.1.4/?lang=ru-RU&load=package.full&coordorder=longlat&format=AMD' отдается AMD модуль.
Как это помогает, в плане асинхронности, наследованию моего модуля от класса, предоставляемого из апи? Приведите пример описания модуля ComplexLayer для AMD из статьи.
Нельзя ответить на вопрос «когда?».
А зачем на него отвечать для статического анализа кода?
Мне кажется это смешивание системы модулей и загрузчика модулей в одно целое. Более того, не самое удачное.
Вы ошибатесь. Загрузчик — это всего лишь обычный, ни чем ни лучше других, модуль в модульной системе. Сама модульная система знает только про модули и разрешение зависимостей между ними, ничего более. Модуль-загрузчик приведен лишь в качестве примера, иллюстрирующего случай, когда нужен асинхронный провайд модуля.
Но никто не мешает сделать тоже самое с AMD
Можете привести пример кода для AMD, иллюстрирующего модуль, которые экспортирует класс, который наследуется от класса из API Яндекс.Карт? Тот же пример, который в статье разобран.
Далее, у меня мнение, что система модулей должна быть статически анализируема.
А что в YM этому сейчас препятствует? В этом плане он ничем не отличается ни от CommonJs, ни от AMD.
Судя по примерам на yuilibrary.com/yui/docs/yui/index.html, это выглядит все очень ненатурально, как будто подшито костылями уже постфактум. Руками где-то описываются вещи типа async: true, сам Loader, опять же, не является просто модулем, а зашит в глобальный объект. В общем, совсем не то, что хотелось от модульной системы.
В итоге, теплое смешано с мягким.
1. Когда он не использует общие решения, не понимая зачем они, под каждую задачу пишет свою альтернативу. Как правило, на этой стадии альтернатива гораздо хуже общего решения.
2. Когда он понимает, зачем общие решения, и использует их.
3. Когда он понимает, чем его не устраивает общее решение, что можно сделать лучше, и он пишет альтернативу. На этой стадии альтернатива имеет гораздо больше шансов оказаться лучше, чем общее решение.
Есть еще, конечно, момент с исправлением существующих общих решений, но: это далеко не всегда возможно, у авторов общих решений есть свое видение, как правило. не совпадающее с твоим; не всегда вообще можно общее решение доработать без потери обратной совместимости; и, что вообще не любят разработчики, надо потратить уйму времени на разговоры и объяснения, часто безрезультатные. Возможно, это 4-я стадия :)
Да и не нужна асинхронность, там где она не нужна, извините за тафтологию. Не нужно пользователю класса ComplexLayer знать о том, откуда и как он берется, вроде это очевидно. Если мне нужно написать:
я должен так и писать, а не делать странные вещи типа:
и все последующие методы complexLayer звать только через промисы.
Плюс, в YM еще есть несколько отличий от AMD, которые на рассмотрены в статье, но для нас являются важными, например возможность додекларации/передекларации существующих модулей.
И можно, все-таки, код увидеть? Как там обрабатывается, допустим, ситуация с ymaps.ready, которая наступает позже загрузки самого апи?
А зачем на него отвечать для статического анализа кода?
Можете привести пример кода для AMD, иллюстрирующего модуль, которые экспортирует класс, который наследуется от класса из API Яндекс.Карт? Тот же пример, который в статье разобран.
А что в YM этому сейчас препятствует? В этом плане он ничем не отличается ни от CommonJs, ни от AMD.