Все потоки
Поиск
Написать публикацию
Обновить

Комментарии 31

Very nice.
Рейтинг скрыт
А в чем преимущество перед CommonJS?
Рейтинг скрыт
Если речь именно о загрузке, то для тех кто знает как правильно готовить CommonJS — то никаких наверно.
Но тут ведь не только загрузчик.

Ну и под разные задачи — разный инструмент.
Ниже я написал почему для меня на данный момент не актуально на разрабатываемом проекте ES6 и подобное.
Рейтинг скрыт
НЛО прилетело и опубликовало эту надпись здесь
boot.js в принципе самостоятелен, а вот classes зависит от processor в одном месте.
Рейтинг скрыт
Зачем оно, если есть es6 и webpack?
Загрузка модулей прям как в умирающем requirejs. Зачем, если есть стандарт и commonjs?
Классы и прокси есть в es2016. Опять же, стандарт.
Рейтинг скрыт
Тогда когда делалась основа проекта (> 4 года назад) ажиотажа на es6 и всякие webpack`и не было, поэтому всё пилилось в таком виде, а в дальнейшем только дорабатывалось под конкретные задачи.
Исключение только в boot.js, но опять таки если начинать переписывать что-то на es6 то тогда уж весь проект, а он очень уж не маленький.
Поэтому работал с тем что есть, и что знаю.
Рейтинг скрыт
Когда стандарта не было, все развлекались как могли. Сейчас же куда лучше писать в соответствии со стандартом подключая полифилы при необходимости (тем более, что темп развития JS/ES резко, увеличился). Ведь в один прекрасный момент полифилы можно будет убрать, и код без изменений будет работать нативно. Если же использовать дубликаты каких-то фичей, но с другим синтаксисом, то может получится то, что у вас: куча легаси-кода который очень трудно рефакторить и поддерживать. Тем более, что гиганты веба (MS в частности) наконец сдвинулись с места и новые спецификации появляются намного быстрее.

Кстати, RequireJS "реализует" AMD. Какие модули предоставляет ваша библиотека? Если там что-то неизвестное широким массам, то опять же, незачем использовать несовместимые и неизвестные решения.
Я это к тому, что webpack умеет загружать те же AMD, так что процесс перехода со старой модульной системы к новой может происходить постепенно и прозрачно.
Рейтинг скрыт
Сейчас же куда лучше писать в соответствии со стандартом подключая полифилы при необходимости (тем более, что темп развития JS/ES резко, увеличился). Ведь в один прекрасный момент полифилы можно будет убрать, и код без изменений будет работать нативно.

Я не сколько не против, а только за. Только вот даже как-то нет времени и опыта чтоб начать что-либо переделывать (Я думаю Вы сами можете представить сколько сил нужно на то чтоб переделать то что уже давно функционирует, и всё это после переработки — заставить работать. Ну и ситуация с проектом такая что мне нужно хоть как-то продвигаться по работе, а не останавливаться на "переработке" старого кода).

Но это только моя ситуация, остальных могу только призвать — использовать новые инструменты, с новыми возможностями если такая возможность есть (простите за каламбур).

Кстати, RequireJS «реализует» AMD. Какие модули предоставляет ваша библиотека?

Никаких. Модули которые предоставляет наша библиотека — относительные. Они из себя представляют только список загружаемых/зависимый и инициализируемых скриптов. Использовать в принципе можно любые скрипты/модули которые можно загрузить браузером. Я конечно сильно не вникал в это, но посмотрите пожалуйста на пример и скажите если это не так.
Рейтинг скрыт
Все это есть сейчас. Лучше бы рассказали с какими трудностями столкнулись продолжая использовать данное решение.
Ничего плохого нет в том, чтобы выкладывать свои наработки в открытый доступ, но зачем делать из этой богом забытой библиотеки анонс?
Рейтинг скрыт
Да нет трудностей вроде как, всё работает как надо для тех задач под которые это и писалось.
Рейтинг скрыт
Очень не хватает работающих (!) примеров. Попытался реализовать пример перехвата функций, но ничего не выходит:
http://jsbin.com/tumayopuje/edit?html,console,output

В js уже включена возможность проксей, вот пример:
http://jsbin.com/vocuzoxegi/edit?html,console,output
Но хочется "поюзать" и вашу реализацию.

Также, как мне кажется, было бы лучше, если бы вы разделили свою библиотеку на три (по функциональности), а не "все в кучу".
Рейтинг скрыт
Дело собственно в следующем (я это совсем упустил из виду при описании, нужно некоторые моменты уточнить в документации видимо):
К тем объектам которые создаются в TOM.js добавляется параметр scopeName, именно он выступает в качестве "имени стартового объекта", при перехвате.
Варианта тут 2, либо добавлять scopeName к проксируемому объекту (что собственно не особо красиво и нужно), либо же просто писать так: 

TOM.processor.proxy( 'объект', 'имя объекта по которому будут происходить "всплытия" событий' );
TOM.processor.proxy( MyObject, 'MyObject' );

Исправленный пример: http://jsbin.com/yexexogadi/1/edit?html,console,output

Также, как мне кажется, было бы лучше, если бы вы разделили свою библиотеку на три (по функциональности), а не «все в кучу».

Я собственно думал в эту сторону, просто тот-же classes в одном месте зависим от processor (для верного перехвата создания класса). В остальном зависимостей каких-то особых — нет.
Рейтинг скрыт
НЛО прилетело и опубликовало эту надпись здесь
Proxy включен в стандарт ES-2015 и на текущий момент (еще пока) поддерживается далеко не всеми браузерами.
Поэтому меня очень и заинтересовала реализация перехвата функций в библиотеке TOM.js
Указанный мной пример точно будет работать на браузере Мозилла.
Полный список поддерживающих Proxy браузеров можно глянуть здесь: https://kangax.github.io/compat-table/es6/
Рейтинг скрыт
Как вообще можно было связать загрузчик и наследование?

Связка там только в одном месте, и убирается удалением 2х строчек:

newClass = function( )
{
    var args = Array.prototype.slice.call( arguments, 1 ),
        constructorFullName = ( ( this.__classScopeName__ !== '') ? this.__classScopeName__ + '.' + this.__className__ : this.__className__ ) + '.constructor';

    // Дополнительные "костыли" для TOM.processor, которые возволяют определять момент создания класса 
---->  TOM.processor.signal( 'pre', constructorFullName, this, args );
    classConstructor.apply( this, arguments );
---->  TOM.processor.signal( 'post', constructorFullName, this, args );
};

Сделано это для возможности перехвата события по созданию класса, более элегантного решения для подобного не нашёл.
Рейтинг скрыт
Особо порадовал TravisCI, который просто запускает сборку проекта, никаких тесто у либы нет ;]
А их стоило бы написать, даже не вооруженным взглядом в исходниках видно потенциальные баги, просто в банальном for-in без hasOwnProperty.

Ну и главное, посмотрите на реализацию тех же RequireJS или SystemJS, эти ребята про загрузку JS много чего могут поведать: тык, тык и у вас. Загрузка CSS тоже доверия не вызывает.
Рейтинг скрыт
Особо порадовал TravisCI, который просто запускает сборку проекта, никаких тесто у либы нет ;]
А их стоило бы написать, даже не вооруженным взглядом в исходниках видно потенциальные баги, просто в банальном for-in без hasOwnProperty.

Сборка через TravisCI добавлена исключительно для GitHub и перенесена из другого проекта.
А тесты да, неплохо бы сделать.

Ну и главное, посмотрите на реализацию тех же RequireJS или SystemJS, эти ребята про загрузку JS много чего могут поведать: тык, тык и у вас. Загрузка CSS тоже доверия не вызывает.

Спасибо, изучу.
Рейтинг скрыт
'{pre или post}-имя функции вызова которой ждём'

Чем вызвано такое странное, если не сказать хуже, решение именования?
Почему не 2 параметра: pre|post и нормальное имя функции, а лучше ссылка на нее.
Рейтинг скрыт
Простите, не понял вопроса.

Если для чего использовать вообще pre|post в имени функции? То для вот такого:

TOM.processor.bind( 'pre-core.Button.create post-core.TestButton.create', function( ) {} );

То-есть перехват нескольких функций при помощи одного обработчика.
Рейтинг скрыт
Почему это — строка, которая потом, вероятно, парсится?
Не лучше ли

TOM.processor.bind( 'pre', core.Button.create post-core.TestButton.create, function( ) {} );
Рейтинг скрыт
Ну я показал пример почему.
Как быть в случае когда обработка идёт нескольких функций?
В вашем случае получается "по умолчанию" — для всех идёт pre, и для избранных — post, вроде как это неразбериху добавляет.

А так вообще идёт по умолчанию post (если пишется просто имя функции, без приставки).
Рейтинг скрыт
Пардон, я post не заметил:

TOM.processor.bind( {'pre' : core.Button.create, 'post' : core.TestButton.create}, function( ) {} );

или даже

TOM.processor.bind( {'pre' : [core.Button.create], 'post' : [core.TestButton.create]}, function( ) {} );
Рейтинг скрыт
Как вариант конечно, интересная идея — спасибо.
А про обработку ссылок — нужно подумать можно ли это безболезненно внедрить.
Рейтинг скрыт
Примечание: Я знаю что arguments.callee это плохо, и оно не работает в strict mode, но пока удобной замены не придумал.

https://habrahabr.ru/company/wargaming/blog/271357/#comment_8671617
Не портит стек-трейс, не ударяет по производительности и не использует сомнительных возможностей. Но, впринципе, уже пора переходить на ES6 Classes.
Рейтинг скрыт
TOM.js — особая библиотека, для особых случаев

Не ТОМ.js оригинальная библиотека называется, а feel.js, от слова "чувство", так как реагирует на взаимодействие с html, сначала реагирует, потом выполняет анализ ситуации. Смысл библиотеки — построить алгоритм работы веб-приложений, визуально напонимающих Flash приложения, путем парализации переходов по ссылкам коротким скриптом. Лично ручками писал.

Рад что тебе интересны мои работы, жаль что без разрешения их берешь.
Рейтинг скрыт
Что? Вы о чём?
При таких громких заявлениях, будьте добры предоставить ссылки.
Рейтинг скрыт
Благодарю.
Элегантно и лаконично написано.
Рейтинг скрыт
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2026, Habr