«Так то оно так», но здесь явно просматривается каскад проблем. А про каскад проблем при проектировании можно писать большие статьи. Но в любом случае, как я могу видеть данная проблема решается лишь на самом верхнем уровне: уровне концепта, то это явно очень большая проблема. Конечно, это возможно не в этой ситуации, но при реальном проекте — это было бы, можно сказать, катастрофическая трудность. Я просто уже много раз слышал фразу «это вообще не проблема поправить», а потом оказывается что, утрирую, нужно пол проекта перелопатить.
artch частично прав, так как html/css/js это только слой ui компонент приложения, а любое приложение должно быть разделено на слои. Самые распространённые это: хэлперы, модели, бизнес логика, слой базы данных, сервисы, ui. Мы к дополнению делим любое приложение на проекты, это перекочевало у нас ещё с .net: есть solution и projects. Каждый проект это можно сказать одно законченное приложение, которое может соответственно зависеть от других проектов. Для примера могу привести недавно начатый полу-хобби проект: task scheduler. Хоть это и nodejs приложение, но структура идентична и для single-page. И вот то, что относится к ui, мы делим на компоненты/контролы и прочее, и вот там (видите как мы уже глубоко зашли), каждый отдельный юнит держится со всеми своими зависимостями и ресурсами. Как например ajax-loader. Огромным плюсом является, то что с таким подходом компоненты легко разрабатывать( это можно делать иногда вне контекста всего проекта), и переносить в другие приложения. А вот для релиза, когда собирается приложение, весь код и ресурсы которые вне проекта складываются в папку build.
Конечно же подобная структура зависит от технологий, а как мы знаем Web — это просто джунгли из языков, фреймворков и разных типов приложений, так что серебренной пули здесь нет.
Нужно обязательно также и в этом направлении двигаться: ограничение прав и midd прослойка. Иначе без первого, как по мне, вообще невозможно использовать commander на сервере — для этого есть sftp. Для десктопов есть родные менеджеры с более полным функционалом и портативными версиями. А вот для админ панелей подобная разработка подходит просто шикарно. Или я упускаю что-то?
И думаю вам не будет сложно сделать как минимум две вещи:
— options: `rootPath`, `cmdEnabled`
— exports.process = function(req, res, ctx /* current request options*/)
И вот с таким api уже можно делать многое.
Вещь очень хорошая, но для полноценного использования для серверных целей не нашел двух вещей:
ограничения прав (хотя бы на уровне приложения, а на пользователей)
назначение root директории: только CWD или свой путь
скрывать определённые пути/папки через regexpы
ограничения функционала
использование менеджера как модуля. Помимо основного приложения, у нас есть админ-приложение, и хотелось бы встроить ваш менеджер, как connect middleware например, или просто запросы пробрасывать.
Есть ли эти фичи уже или возможно планируется работа по ним?
Автора переполняют эмоции, хотя если разобраться, то окажется, что `Object.defineProperty` уже давно удовлетваряет всем желаниям. Единственное не возможно следить за добавлением/удалением свойств, но это крайне редкая необходимость по двум простым причинам:
1* Архитектурная — модели и классы должны быть полноценны и однозначны
2* Производительная
— добавляя-удаляя свойства обьекта, V8 как минимум, пересоздает скрытые классы для обьекта
— создается небольшой event flood, так как нужно фильтровать `changes`, что бы слушать только например `foo property update`
В наших проэктах давно уже завели себе Object.[add/remove]Observer Object.[lock/unlock]Observers которые добавляют ака proxy функции для сеттеров и ака breadcrumbs proxies для вложенных обьектов, как с примера для полимера.
var obj = { foo: { bar: 'baz' } };
Object.addObserver(obj, 'foo.bar', console.log.bind(console));
obj.foo.baz = 'qux';
//> qux
obj.foo = { bar: 'quxx' }
//> quxx
И ещё, `getNotifier` отлично заменяется `EventEmitter`ом. А что бы следить за массивом, достаточно обернуть его мутаторы, сново же, своим proxy методом.
Я никаким образом не хочу сказать, что O.o плох — напротив, и статья отличная, только много из этих вещей можно и нужно использовать уже сейчас! Ну, кто может себе позволить IE9+;
У вас очень мощный продукт. К сожалению, разработчики в массе очень инертны и очень скептичны к новым, пока ещё не популярным веяниям/инструментам, особенно в снг.
Также рекомендую присмотреться к atom.io, можно будет «выехать» на их волне популярности. Да и с разработчиками было бы хорошо связаться, возможно удастся придумать кооперацию. Уверен будет бомба.
К сожалению под «браузер» ничего другого толкового нет (насколько мне известно). Но скажу, что если не использовать фичи скрытые за флагами, как `let ` например, то очень он с остальным хорошо справляется. Хотя признаюсь, генераторы ещё не использую, как то страшновата мне их «стэйт-машина» в плане производительности — никак не находится время поближе взглянуть на реализацию и тесты.
Верно, уже давно можно начать пользоваться traceur, ведь кроме модулей в es6 других очень много плюшек. Так что, кто не хочет стоять на одном месте — пора переходить.
Понимаете, у меня в деве никаких тасков `а, б, в` нету. Открыл браузер, редактор и вперед. А так как у нас ещё к тому же компонентная архитектура приложений, то поддерживается лайфрелоуд не только стилей, но и js кода. Быстрый пример:
Youtube
Но здесь я не хочу вас переубеждать, что и как лучше — если вам удобнее так как вы описываете, то я только рад. Но для себя я определился и другим также советую — настраивать систему разработки так, что бы компиляция происходила на самом нижнем уровне — при чтении файла. Таким образом, будет казаться, что браузер поддерживают coffescript например `нативно`. (_подключил файл через `script` тэг и он работает_). И тогда останется выбрать лишь модульную систему которая загружает скрипты/стили. Для которой определённо уже имеется свой `builder`. А код может быть написан, хоть частично на typescript, частично на coffee, a остаток на es6 — все равно каждый файл в результате при чтении становится js, или css, или…. И это жуть как удобно )
Нет, я о httphandler как о обработчике запроса в общем, браузер запрашивает 'menu.sass', а запрос обрабатывает не static handler, а обработчик который предварительно компилирует ресурс. Такое реализуется на любом бэкенде, и asp.net здесь не причем. И для большинства уже все есть, ничего самому делать не нужно.
Скажите, а чем отличается server side компилирование Lessa от server sidе компилирования sassa? Препроцессор есть как для первого так и для второго.
Я лишь предлагаю более чистую архитектуру, а не велосипед.) А вы выступаете за комбайн который делает все сразу, но при этом в конфиге настраиваете компиляцию ресурсов и боретесь с прочими не нужными вещами.
Я также за рациональный путь) А всё очень просто — HttpHandlers или file reader hooks. Это вводит дополнительную абстракцию в систему чтения/запроса файлов. Понимаете системе сборки или браузеру абсолютно не важно, что в файле coffeescript, при чтении файла он автоматически превращается в javascript — эдакий file middleware. Также и со стилями, в файле less, а при чтении получаем `css`. Вот и получается, что о компиляции нам больше нигде не нужно беспокоится, и о ней можно забыть — это всего лишь файл, обычный javascript. Вот теперь как быть с этим javascript, где и как его собирать, какую модульную систему использовать — вот что важно. А здесь много разных вариантов — мы используем свое решение, в дев моде каждый файл загружает свои зависимости сам, через обычный <script src="/file.es6"></script> (с source maps конечно). А для релиза все собираем. Много чего ещё есть, на этом собаку сьели, так что, если есть другие рациональные вопросы, буду рад ответить.
Система сборки не должна заниматься компилированием ресурсов. Компиляция должна лежать на уровне ниже — чтение файлов. Таким образом, изменив `menu.css` на `menu.less`, или `collapser.js` на `collapser.es6` — это не должно затрагивать систему сборки — всё должно оставаться как есть и работать сразу. И такой подход нас «бесплатно» избавляет от длительных компиляций при `лайфрелоуде`.
А второе — (спорно, но важно) — в dev моде вообще не должно быть никаких процессов сборки. Стили, скрипты и шаблоны подгружаются в не собранном виде. То есть, ресурсы подгружаются отдельно и только те которые нужны в данный момент. Это упрощает разработку в разы — в developer tools у нас все файлы по отдельности, и только те которые используются в данном сценарии.
А система сборки применяется единожды перед деплоем.
Я вот тащусь от «in-editor REPL». Использую Komodo IDE; они поддерживают javascript макросы, и вот в команде создали несколько макросов для исполнения выделенного фрагмента или всего файла. Несказанно удобно, не только для быстрого тестирования, а вот например нужно узнать charcode символа, и что бы не искать где-то в интернете пишем, 'a'.charCodeAt(0), выделяем, жмём hotkey и тут же результат вставляется в editor.
Сейчас кажется все производители переходят на стандартизированный SDK — SmartTV Alliance. У нас есть пару проектов для смарт тв, и начинаем мигрировать. Toshiba, как минимум, сейчас поддерживает только его.
Видя в этом подвох и желание написать через промисы только запутают архитектуру вашего приложения. Данная проблема относится к ресурсам модуля и это должна на себя перенимать модульная система. Очень не логично, загружать модуль, а потом ещё ждать пока загрузятся зависимости модуля. Представьте, что вам нужно загрузить 5 таких асинхронных модулей, конечно вы можете промисы загнать в `when` и дождаться завершения всех загрузок, но это усложняет систему.
Плюс, данный метод отлично подходит, если вам вдруг нужно, что бы один из модулей, загружал данные/конфигурация (да что угодно) асинхронно, при этом не нужно будет изменять архитектуру «отцов».
Если эта статья лишь показать как работает `toString` в JS — тогда ОК ). А сам по себе метод хранения данных в комментариях в теле функции — ужас. Если данных много, то только в отдельных файлах, есть много модульных систем, которые подгружают помимо скриптов также и данные, а для релиза все будет собрано в один файл. Если нет возможности использовать модульную систему — есть другие варианты, где сборка происходит через // import data.yml с предварительной трансформацией.
Было бы интересно посмотреть на реализацию `docstrings` через комментарии, или на интересную технику с использованием комментариев с мета информацией для функций, аля аспектно-ориентированное программирование.
Конечно же подобная структура зависит от технологий, а как мы знаем Web — это просто джунгли из языков, фреймворков и разных типов приложений, так что серебренной пули здесь нет.
И думаю вам не будет сложно сделать как минимум две вещи:
—
options: `rootPath`, `cmdEnabled`—
exports.process = function(req, res, ctx /* current request options*/)И вот с таким api уже можно делать многое.
Есть ли эти фичи уже или возможно планируется работа по ним?
property | ?fom > to | easing duration delay. Пример модели:1* Архитектурная — модели и классы должны быть полноценны и однозначны
2* Производительная
— добавляя-удаляя свойства обьекта, V8 как минимум, пересоздает скрытые классы для обьекта
— создается небольшой event flood, так как нужно фильтровать `changes`, что бы слушать только например `foo property update`
В наших проэктах давно уже завели себе
Object.[add/remove]Observer Object.[lock/unlock]Observersкоторые добавляют акаproxyфункции для сеттеров и акаbreadcrumbs proxiesдля вложенных обьектов, как с примера для полимера.И ещё, `getNotifier` отлично заменяется `EventEmitter`ом. А что бы следить за массивом, достаточно обернуть его мутаторы, сново же, своим proxy методом.
Я никаким образом не хочу сказать, что O.o плох — напротив, и статья отличная, только много из этих вещей можно и нужно использовать уже сейчас! Ну, кто может себе позволить IE9+;
Также рекомендую присмотреться к atom.io, можно будет «выехать» на их волне популярности. Да и с разработчиками было бы хорошо связаться, возможно удастся придумать кооперацию. Уверен будет бомба.
Но здесь я не хочу вас переубеждать, что и как лучше — если вам удобнее так как вы описываете, то я только рад. Но для себя я определился и другим также советую — настраивать систему разработки так, что бы компиляция происходила на самом нижнем уровне — при чтении файла. Таким образом, будет казаться, что браузер поддерживают coffescript например `нативно`. (_подключил файл через `script` тэг и он работает_). И тогда останется выбрать лишь модульную систему которая загружает скрипты/стили. Для которой определённо уже имеется свой `builder`. А код может быть написан, хоть частично на typescript, частично на coffee, a остаток на es6 — все равно каждый файл в результате при чтении становится js, или css, или…. И это жуть как удобно )
Скажите, а чем отличается server side компилирование Lessa от server sidе компилирования sassa? Препроцессор есть как для первого так и для второго.
Я лишь предлагаю более чистую архитектуру, а не велосипед.) А вы выступаете за комбайн который делает все сразу, но при этом в конфиге настраиваете компиляцию ресурсов и боретесь с прочими не нужными вещами.
<script src="/file.es6"></script>(с source maps конечно). А для релиза все собираем. Много чего ещё есть, на этом собаку сьели, так что, если есть другие рациональные вопросы, буду рад ответить.А второе — (спорно, но важно) — в dev моде вообще не должно быть никаких процессов сборки. Стили, скрипты и шаблоны подгружаются в не собранном виде. То есть, ресурсы подгружаются отдельно и только те которые нужны в данный момент. Это упрощает разработку в разы — в developer tools у нас все файлы по отдельности, и только те которые используются в данном сценарии.
А система сборки применяется единожды перед деплоем.
'a'.charCodeAt(0), выделяем, жмём hotkey и тут же результат вставляется в editor.Плюс, данный метод отлично подходит, если вам вдруг нужно, что бы один из модулей, загружал данные/конфигурация (да что угодно) асинхронно, при этом не нужно будет изменять архитектуру «отцов».
// import data.ymlс предварительной трансформацией.Было бы интересно посмотреть на реализацию `docstrings` через комментарии, или на интересную технику с использованием комментариев с мета информацией для функций, аля аспектно-ориентированное программирование.