Comments 16
Такая запись позволяет немного упростить форматирование и улучшить читаемость, но даже здесь приходится упоминать название зависимостей несколько раз. Кроме того, этот синтаксический сахар добавляет очередное усложнение в виде ещё одного способа обращения к зависимостям.
Вы неправы. Достаточно вот такой записи:
define(function (require) {
var dep1 = require('dep1'),
dep2 = require('dep2'),
dep3 = require('dep3'),
dep4 = require('dep4'),
dep5 = require('dep5'),
dep6 = require('dep6'),
dep7 = require('dep7');
// ...
});
это плохо.
Уже есть 3 варианта, которые являются стандартами де-факто
1) AMD модули, которые использует, например, require.js
2) CommonJS модули, которые решают зависимости синхронно (например node.js, или для браузеров browserify).
3) И модули из стандрта ES6.
Для 1 и 2 есть куча плагинов, возможность загружать шаблоны, стили и так далее. И есть стандарт из будущего, который УЖЕ можно использовать, используя компиляторы соответствующие, или же на node.js, запущенным с определенным флагом.
Не нужно больше велосипедов, и изучайте инфраструктуру языка на котором пишите, это гораздо важнее самого языка.
Уже есть 3 варианта, которые являются стандартами де-факто
1) AMD модули, которые использует, например, require.js
2) CommonJS модули, которые решают зависимости синхронно (например node.js, или для браузеров browserify).
3) И модули из стандрта ES6.
Для 1 и 2 есть куча плагинов, возможность загружать шаблоны, стили и так далее. И есть стандарт из будущего, который УЖЕ можно использовать, используя компиляторы соответствующие, или же на node.js, запущенным с определенным флагом.
Не нужно больше велосипедов, и изучайте инфраструктуру языка на котором пишите, это гораздо важнее самого языка.
Если бы создатели этих вариантов следовали тогдашним «стандартам де-факто», не было бы сейчас ни нода, ни commonjs. Был бы бэкэнд на php и инклюд через script
стандартов никаких не было, до того момента пока они не понадобились, ровно до этого момента. и то что эти решения выжили это именно потому что они что то дают, людям их использующих.
и появление нод.жс никак не зависело от системы модулей, вообще.
инфрастукрные велосипеды от обычных отличаются тем, что писать их надо только в том случае если понимаешь профит того что они дадут, а страдать not invented here лучше не надо, в таких случаях.
и появление нод.жс никак не зависело от системы модулей, вообще.
инфрастукрные велосипеды от обычных отличаются тем, что писать их надо только в том случае если понимаешь профит того что они дадут, а страдать not invented here лучше не надо, в таких случаях.
Так этот пост собственно и есть почти целиком про профиты. Вы правы в том, что мне было скорее интересно сделать эту штуку, но если бы не было профита — я бы наверное и не начинал.
Ну или можно объявить киллерфичей возможность запуска приложения в nodejs и в web без изменений и трансляции. У меня есть мысли развить проект как раз в эту сторону.
Ну или можно объявить киллерфичей возможность запуска приложения в nodejs и в web без изменений и трансляции. У меня есть мысли развить проект как раз в эту сторону.
Глядя на всё это, начинаешь ещё больше любить CommonJS модули.
Тогда уж посмотрите на библиотечку StealJS. Она предлагает такой формат:
По мне так это еще компактнее, чем Helios Kernel + нет этого магического вызова функции с именем «init».
steal(
"path/to/fooLibrary.js",
"path/to/barLibrary.js",
function() {
// использование
foo.doSomething();
});По мне так это еще компактнее, чем Helios Kernel + нет этого магического вызова функции с именем «init».
«Собирающий» модуль будет выглядеть как
Управление зависимостями библиотек, незнающих про зависимости выглядит так:
Менять код самих библиотек не нужно.
steal('deps/dep1.js','deps/dep2.js','deps/dep3.js');Управление зависимостями библиотек, незнающих про зависимости выглядит так:
steal('jquery.js').then('jquery.ui.js');Менять код самих библиотек не нужно.
Спасибо, интересная библиотека, может быть по способу записи ближе всего к Helios Kernel. Только странно, что у steal столько разнообразного функционала: у меня впечатление, что некоторые вещи должны быть в виде отдельных серверных инструментов (steal.clean).
Про формат записи это же вопрос вкуса. Мне кажется, тут нужно стремиться не к компактности и минимальному размеру кода, а к ясности. Конкретно в steal такое место — аргументы функции steal, которые могут менять свой смысл (быть путём или колбэком) в зависимости от их количества. Ну то есть я бы не стал определять например тело модуля в виде анонимной функции прямо в перечислении аргумента только лишь потому, что язык позволяет этим способом сделать запись более компактной.
По такой же причине я однажды убрал поддержку нескольких аргументов в функции include() — в итоге каждый новый модуль перечисляется отдельным вызовом этой функции. Не потому, что мне было запарно пробегать по массиву аргументов, а потому что удобней читать, когда знаешь, что один вызов инклюда = одна зависимость.
А функция init() в некотором смысле даже аналогична сишному int main(). Её логичнее было именно определять в теле модуля, а не передавать в качестве аргумента как раз потому что это не колбэк.
Про формат записи это же вопрос вкуса. Мне кажется, тут нужно стремиться не к компактности и минимальному размеру кода, а к ясности. Конкретно в steal такое место — аргументы функции steal, которые могут менять свой смысл (быть путём или колбэком) в зависимости от их количества. Ну то есть я бы не стал определять например тело модуля в виде анонимной функции прямо в перечислении аргумента только лишь потому, что язык позволяет этим способом сделать запись более компактной.
По такой же причине я однажды убрал поддержку нескольких аргументов в функции include() — в итоге каждый новый модуль перечисляется отдельным вызовом этой функции. Не потому, что мне было запарно пробегать по массиву аргументов, а потому что удобней читать, когда знаешь, что один вызов инклюда = одна зависимость.
А функция init() в некотором смысле даже аналогична сишному int main(). Её логичнее было именно определять в теле модуля, а не передавать в качестве аргумента как раз потому что это не колбэк.
Как вариант: библиотека MicroRequireJs github.com/dsheiko/micro-requirejs.
Очень простое и легкое (1K) решение. Не требует адаптации зависимых модулей:
Очень простое и легкое (1K) решение. Не требует адаптации зависимых модулей:
rjs.define("//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js", "jQuery");
rjs.require(['jQuery"], function(){
var $ = window.jQuery;
});
include("path/to/myLibrary.js");
init = function() {
// здесь библиотека подключена и можно её использовать
myLibrary.writeHello();
}
а как насчет use strict?
Sign up to leave a comment.
Классический подход к управлению зависимостями в сравнении с RequireJS