Разделяем и именуем отталкиваясь от функционала, который файл реализует.
Про window, естественно кинуть в window один объект и все за него спрятать это правильно и мы к этому идем. Но на данный момент не могу этим похвастать очень много легаси кода и путь будет длинный.
Вижу сарказм. Сразу говорю что зря. Я понимаю что хочется показать свое я, но это не профессионально. На первый раз отвечу с полной ответственностью, сделав вид что сарказм не заметил.
Подходы не устарели несколько лет назад, а появились несколько лет назад и эти годы показали что не зря.
Цитата из статьи «первый раз эту тему я освещал в 2007 году». За 5-ть с лишним лет методология выкристаллизовалась и стало понятно что лишнее, а что нет. Более того я в статье несколько раз говорил что если у вас возникла задача на client-side посмотрите на sever-side 99% она была решена еще в 60-х.
Про mail.ru, написано что придя в mail.ru я увидел что этими паттернами давно и активно пользуются, что меня еще раз порадовало.
Про ошибки это вообще отдельная большая тема, надеюсь расскажем. У нас в принципе мониторятся ошибки много и часто. Более того мы контактируем в той или иной степени с разработчиками браузеров. Опере посчастливилось иметь прямо представительство в России. Так вот из Вадима Макеева я пару раз душу вынимал по поводу багов оперы.
Зависимости в шаблонизаторе. Тут мне не понятно, я предлагаю хранить зависимости внутри виджета, что не мешает строить дерево зависимостей. Вы предлагаете снаружи, да еще и копировать заивисимости при каждом подключении компонента в новом шалоне?
По поводу initWidgets([id1, id2, id3]), я выкинул это из статьи но упоминание такого подхода есть в видео. Это нормально и часто правильно, но это детали не меняющие подход.
По поводу фейсбук и остальных. Конкретно с разработчиками фейсбук я не общался, пока, но часто общаюсь с разработчиками лидирующих Российских сайтов, например Яндекс, разработчиками Google, NodeJS и т.д. Уж поверьте мы внимательно друг друга слушаем. Потому что не слушать разработчиков которые отвечают за работоспособность сайта перед 20 000 000 уникальных пользователей в день странно. Более того я внимательно выслушал вас и ответил. Поэтому, на будущее, в разговоре со мной не указывайте на решения других приводите в пример свои решения с продакшена.
Как правило, важно в разработке иметь мало маленьких файлов, а на продакшене один большой. В данном случае конфигом может быть не результирующий html, а шаблоны (так сделано на почте mail.ru). Синтаксис require простой и однозначный, поэтому написать на сервере скрипт, которых обходит шаблоны страниц и строит нужный js файл не сложно. Если что-то удаляется из шаблона это автоматом пропадает из собраного js.
Про ленивую загрузку. Эта задача решается параллельно и никак не противоречит подходу. Если в загруженном компоненте по таймауту или действию пользователя вызвать require, то все догрузится и выполнится. Более того если с сервера получить html размеченный компонентами, вставить его в дом и полученную ноду пропустить через инициализирующий скрипт, скрипт найдет компоненты, поймет что надо догрузить из еще не догруженного и все заработает из коробки.
Нет, ошибок не будет, если события вешаются ТОЛЬКО в компонентах. js ядро находит элемент до инициализации обрабатывает onclick и стирает все упоминания о нем. Дальше в компонент попадает чистенькая dom node.
Тогда этот вопрос не принципиален. Просто я уже давно не делал проекты которым меньше 10 лет и которые еще поддерживать и поддерживать. В этих условиях лучше сразу заложиться на структуру.
Смысл в том что, нет навешиваний событий через аттрибуты. Поэтому атрибуты освободились и оказались кстати для прокидывания входных данных. Какой именно использовать без разницы.
data-type хороший вариант, но опять же это строки. Плюс не забываем про старые браузеры, для них нужно будет писать поддержку. Повторюсь, onclick не имеет этих недостатков.
onclick дает из коробки всю выразительность JS. Как только вы начинаете передавать данные на вход одних строк становится мало, захочется отдать структуру. Если свой аттрибут, то однозначно строка которую потом захотите прогнать через eval. onclick это все инкапсулирует.
Ок попробую 4-й раз. Другая парадигма. В JS все объекты и вызывается не 3-й предок, а конкретный метод конкретного объекта. Значит у абъекта есть имя и надо его и использовать.
Про window, естественно кинуть в window один объект и все за него спрятать это правильно и мы к этому идем. Но на данный момент не могу этим похвастать очень много легаси кода и путь будет длинный.
Подходы не устарели несколько лет назад, а появились несколько лет назад и эти годы показали что не зря.
Цитата из статьи «первый раз эту тему я освещал в 2007 году». За 5-ть с лишним лет методология выкристаллизовалась и стало понятно что лишнее, а что нет. Более того я в статье несколько раз говорил что если у вас возникла задача на client-side посмотрите на sever-side 99% она была решена еще в 60-х.
Про mail.ru, написано что придя в mail.ru я увидел что этими паттернами давно и активно пользуются, что меня еще раз порадовало.
Про ошибки это вообще отдельная большая тема, надеюсь расскажем. У нас в принципе мониторятся ошибки много и часто. Более того мы контактируем в той или иной степени с разработчиками браузеров. Опере посчастливилось иметь прямо представительство в России. Так вот из Вадима Макеева я пару раз душу вынимал по поводу багов оперы.
Зависимости в шаблонизаторе. Тут мне не понятно, я предлагаю хранить зависимости внутри виджета, что не мешает строить дерево зависимостей. Вы предлагаете снаружи, да еще и копировать заивисимости при каждом подключении компонента в новом шалоне?
По поводу initWidgets([id1, id2, id3]), я выкинул это из статьи но упоминание такого подхода есть в видео. Это нормально и часто правильно, но это детали не меняющие подход.
По поводу фейсбук и остальных. Конкретно с разработчиками фейсбук я не общался, пока, но часто общаюсь с разработчиками лидирующих Российских сайтов, например Яндекс, разработчиками Google, NodeJS и т.д. Уж поверьте мы внимательно друг друга слушаем. Потому что не слушать разработчиков которые отвечают за работоспособность сайта перед 20 000 000 уникальных пользователей в день странно. Более того я внимательно выслушал вас и ответил. Поэтому, на будущее, в разговоре со мной не указывайте на решения других приводите в пример свои решения с продакшена.
Как правило, важно в разработке иметь мало маленьких файлов, а на продакшене один большой. В данном случае конфигом может быть не результирующий html, а шаблоны (так сделано на почте mail.ru). Синтаксис require простой и однозначный, поэтому написать на сервере скрипт, которых обходит шаблоны страниц и строит нужный js файл не сложно. Если что-то удаляется из шаблона это автоматом пропадает из собраного js.
Про ленивую загрузку. Эта задача решается параллельно и никак не противоречит подходу. Если в загруженном компоненте по таймауту или действию пользователя вызвать require, то все догрузится и выполнится. Более того если с сервера получить html размеченный компонентами, вставить его в дом и полученную ноду пропустить через инициализирующий скрипт, скрипт найдет компоненты, поймет что надо догрузить из еще не догруженного и все заработает из коробки.
var modal = {
hide: function(){};
}
function Text(){
this.hide = function(){
modal.hide.bind(this);
....
}
}
Text.prototype = modal;
vat text = new Text();
function Warning(){
this.hide = function(){
text.hide.bind(this);
....
}
}
Warning.prototype = text;
warning = new Warning();
3-й разпишу bar.method.bind(this) будет лучше.
Дальше вроде холивар начался из раздела «мне нравится» и «мне не нравится» думаю по делу мы уже поговорили.