How to become an author
Search
Write a publication
Pull to refresh

Comments 31

Если речь именно о загрузке, то для тех кто знает как правильно готовить CommonJS — то никаких наверно.
Но тут ведь не только загрузчик.

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

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

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

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

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

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

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

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

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

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

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

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

Связка там только в одном месте, и убирается удалением 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 );
};

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

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

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

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

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

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

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

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

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

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

А так вообще идёт по умолчанию post (если пишется просто имя функции, без приставки).
Rating is hidden
Пардон, я 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( ) {} );
Rating is hidden
Как вариант конечно, интересная идея — спасибо.
А про обработку ссылок — нужно подумать можно ли это безболезненно внедрить.
Rating is hidden
Примечание: Я знаю что arguments.callee это плохо, и оно не работает в strict mode, но пока удобной замены не придумал.

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

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

Рад что тебе интересны мои работы, жаль что без разрешения их берешь.
Rating is hidden
Что? Вы о чём?
При таких громких заявлениях, будьте добры предоставить ссылки.
Rating is hidden
Благодарю.
Элегантно и лаконично написано.
Rating is hidden
Sign up to leave a comment.

Articles

Your account

Sections

Information

Services

Support
© 2006–2025, Habr