Comments / Profile of bsdemon / Habr

bsdemon Feb 25 2014 at 03:55

ОК, я пропустил что ymaps ещё требуется инициализация (ждет DOM или ещё что-то там?). Тогда конечно чистым AMD не получится.

Но на мой взгляд все равно не имеет смысла делать такую функциональность частью системы модулей. Остаются следующие вопросы — как будет обработана ошибка если ymaps.ready не может быть выполнена? Если делать это с помощью промисов/коллбэков, то код, который должен работать с ymaps может эту ситуацию поправить нужным для себя образом (покажет красивое сообщение об ошибке, например).

ymaps:

define('ymaps', function() {
    return loadYMapsAndInitAndReturnPromise();
});

ComplexLayer:

define('ComplexLayer', ['inherit', 'ymaps'], function(inherit, ymaps) {
    return ymap
      .then(
        function(api) { 
          return inherit(api.Layer, ...);
        },
        function(err) {
          if (err.isFlashBlocked) {
            showNotification("please disable flashblocker or something...");
          } else {
            ...
          }
        });
});

bsdemon Feb 24 2014 at 17:23

Я не говорю, что ваш подход не работает, просто тут на хабре что ни неделя, то появляется статья про новую систему модулей в JS, которая 1) не совместима с существующим кодом (AMD, CommonJS) 2) выглядит так, как будто автор не делал анализ существующих решений.

P.S. Это ещё вроде разработка из Яндекса? Тогда мне это вообще странно.

bsdemon Feb 24 2014 at 17:21

Как это помогает, в плане асинхронности, наследованию моего модуля от класса, предоставляемого из апи? Приведите пример описания модуля ComplexLayer для AMD из статьи.

Вы указываете в конфигурации AMD-загрузчика, что модуль ymaps находится под таким URL (map.yandex.ru/api/...) потом ComplexLayer просто его указывает в зависимостях и использует (прям как у вас в коде).

bsdemon Feb 24 2014 at 16:58

Можете привести пример кода для AMD, иллюстрирующего модуль, которые экспортирует класс, который наследуется от класса из API Яндекс.Карт? Тот же пример, который в статье разобран.

По URL config.hosts.ymaps + '/2.1.4/?lang=ru-RU&load=package.full&coordorder=longlat&format=AMD' отдается AMD модуль.

А что в YM этому сейчас препятствует? В этом плане он ничем не отличается ни от CommonJs, ни от AMD.

Нельзя ответить на вопрос «когда?».

bsdemon Feb 24 2014 at 16:08

Ок, смотри.

Мне кажется это смешивание системы модулей и загрузчика модулей в одно целое. Более того, не самое удачное.

Самое удачное — это ES6 modules, где можно просто использовать асинхронную стратегию загрузки для каких-то модулей и не мучаться. Понятно, что с ES6 сейчас так не получится работать — нет поддержки в рантайме. Но никто не мешает сделать тоже самое с AMD — необходимо просто «асинхронную» часть модуля вынести в отдельный модуль, который не будет забандлен (в production) со всем остальным кодом, а будет подгружаться асинхронно (генерироваться бэкендом). Непонятно, что мы получаем реализую «загрузку» модуля (provide) внутри самого модуля, а не системой модулей.

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

-1

Стрелочные функции (Arrow functions) в ECMAScript 6

bsdemon Feb 24 2014 at 15:03

короткий синтаксис — посмотрите на последний скриншот в посте — от такого короткого синтаксиса слёзы наворачиваются

В статье вообще какое-то форматирование кода странное — то запятая в начале строки, то => переносится на другую строку. Интересно, это внутри компании такой styleguide.

bsdemon Feb 24 2014 at 15:00

Я бы сказал, что это ненужное усложнение системы модулей.

-4

bsdemon Feb 19 2014 at 16:51

На самом деле забегайте в #browserify на irc.freenode.net — обсудим ваши сценарии использования и, возможно (даже вероятно), browserify вам подойдет.

bsdemon Feb 19 2014 at 16:50

NIH? :p

bsdemon Feb 19 2014 at 16:37

Ещё раз, если вы используете browserify/webpack/…

вы не скачиваете билд библиотеки, вы устанавливаете пакет из npm/bower/github/....
в пакете — оригинальные исходники ввиде отдельных модулей
вы собираете свое приложение, которое использует библиотеки (сборщик узнает об этом анализирую require() вызовы)
на выходе имеет билд своего приложение + source map (внутри сам source map + оригинальные исходники, можно настроить это отдельно, чтобы исходники подгружались по необходимости)

bsdemon Feb 19 2014 at 16:00

> Смысл не в байтах, а в читаемости финального кода и максимальной приближенности к оригиналу.

С source maps (которые кстати генерирует browserify) вы это все получаете в полном объеме — при ошибке будут видны строки оригинального файла и при клике в devtools вам покажутся оригинальные исходники.

Видимо вы не пробовали пользоваться browserify/webmake/…

bsdemon Feb 19 2014 at 15:59

C browserify мне надо сделать это в одном месте и место это — код, где будут эти модули использоваться. Зачем делать какие-то make module1 module2 ... при этом мне непонятно.

bsdemon Feb 19 2014 at 15:55

jQuery кстати есть на npm, жаль что там не модуляризованный билд… Но вот например lodash — var assign = require('lodash/compat/objects/assign') если нужна всего одна функция.

bsdemon Feb 19 2014 at 15:52

То есть для каждого модуля библиотеки мне надо будет делать make modulename? Спасибо, я лучше browserify/webmake попользуюсь.