Верно ли, что элементы верхнего уровня должны управлять нижними и не наоборот?

Question

[andreyqin]

Возник спор с коллегой, он утверждает, что элементы верхнего уровня в DOM дереве должны управлять нижними и никак иначе, т.е. хождение вверх по дереву - плохая практика. Например, плохая практика, по его мнению:

$(document).on('click', 'button', function() {
    $(this).closest('.wrapper').addClass('selected');
});

=== UPD ===

Вариант решения данной задачи коллегой:

$('.wrapper').each(function() {
    var item = $(this);
    item.find('button').click(function() {
        item.addClass('selected'); 
    });
});

==========

Ребят, ну ведь двигатель управляет автомобилем, а человек - компанией, а не наоборот. Ваше мнение по этому вопросу?

Comments

[mistamao]

Слышал что на (document) вешать отслеживание события не хорошая практика в плане производительности. Нужно вешать на конкретные элементы.

Answer 1

[Rad1calDreamer]

Вместо этого, как он утверждает, мы должны отслеживать события внешних элементов и менять внутренние.

бред. (с) Валерий Карпин

Answer 2

[Сергей Протько]

мы должны отслеживать события внешних элементов и менять внутренние.

Если ваш коллега сможет решить задачу, которую хорошо решает приведенный вами код своим методом - пусть продемонстрирует. Даже любопытно стало.

Comments

[andreyqin]

Добавил в вопрос. В данном случае мы не используем хождение вверх по дереву, зато мы отказываемся от делегирования, навешиваем обработчик в цикле и просто неоправданно усложняем код.

[Сергей Протько]

andreyqin: ну как, если .wrapper по дереву расположен сильно далеко то код будет работать эффективнее конечно. Но при единичном взаимодействии это спички.

[andreyqin]

Сергей Протько: чаще всего .wrapper расположен на пару уровней выше, а то и вообще является ближайшим родителем

[Сергей Протько]

andreyqin: я ответил комментарием на вопрос выше - это сродни выбора подхода к обработке данных:

У вас есть дерево нод, нужно по изменению ноды чилдрена менять аттрибут у ноды парента. Есть два варианта.
1) ваш вариант, по изменению ноды мы траверсим по дереву в поисках нужного парента и меняем атриубуты. Медленно, но нет оверхэда по память и снижаются риски течки в замыканиях. Ну и проще да, можно делигировать события и использовать все преимущества ивент балбинга.
2) хранить мэпу ребенок - парент и тогда у нас нет необходимости траверсить дерево, наиболее быстрая работа алгоритма, но большой оверхэд по памяти (в зависимости от вложенности) и усложняется реализация. Так же отпадает возможность использовать ивент балбинг и увеличивается количество листенеров что на большом дереве придет к лагам.

[Сергей Протько]

andreyqin: то есть все очень сильно зависит от задачи.

[Сергей Протько]

andreyqin: единственное чем стоит руководствоваться - масштабирование. Ваш вариант справляется с этим чуточку лучше чем вариант вашего коллеги. Проблем с тем что у вас ребенок управляет поведением парента (хотя на самом деле это не так, ни тот ни другой не управляет поведением, на основе атрибутов оных принимаются решения не больше).

[andreyqin]

Сергей Протько: тут даже не в каких-то преимуществах речь, коллега приводит свои слова как аксиому, как "правильный" подход.

[Сергей Протько]

andreyqin: без понятия откуда он эту аксиому вытащил.

Answer 3

[vasIvas]

Если говорить о ооп и программировании, то Ваш собеседник прав.
Верхний уровень на прямую должен менять нижние, а те в свою очередь
должны слать события, на которые вышестоящие могут среагировать, а могут и нет.

И я не знаю, кто создал jQuery, но могу сказать только одно,
не один разработчик html -> css -> js не знает и не понимает полностью принципы и основы программирования.
Могу добавить от себя что то, что в разработке ПО и игростроении считается нормой, в web считается глупым и нелепым и обосновывается только тем, что "я так не делаю". Все нововведения которые появляются в последние время делают программисты java -> c...
Что говорить, если даже mvc для сайтов не такое, как для онлайн игр.

Comments

[Виктор Корейша]

А Вы не могли бы подробнее расписать, в чем разница? Пара кейсов бы не помешала.

[Виктор Корейша]

И про mvc хотелось бы, ибо с игростроем не знаком совсем. Но особенно интересно про "то, что в разработке ПО и игростроении считается нормой, в web считается глупым".

[vasIvas]

Iktash: если Вы о mvc, то оно у Вас такое или Вам эта картинка кажется бредовой?

[vasIvas]

Хотя картинка и здесь немного неправильная, не понимают mvc d', программисты. Представление лишь события шлёт, а здесь написано, что вызывает методы.

[vasIvas]

Глупым считается постижение ооп ( мне неоднократно советовали забить на принципы, что говорит о его цене в глазах d', разработчиков ), паттерны ( я постоянно слышал, что о них вообще думать не стоит ),
тот же mvc, использование готовых решение делает из людей верстальщиц, которых называют программистами.
И тому подобное, я не хочу несколько часов сидеть и писать и по этому описал все в общих чертах.

[Alexander Sydorenko]

vasIvas: Вы только что одним махом (не один разработчик html -> css -> js не знает и не понимает полностью принципы и основы программирования), сравняли наверное добрую половину классных верстальщиков, фронтендеров, веб программистов, которые реально понимают что такое БЭМ, MCSS, почему они появились, и на каких принципах основаны; зачем LESS и SASS и т.д.. Которые начинали с ООП, паттернов но потом забили и ушли в веб, либо занимаются вебом как хобби помимо основной работы, либо же помимо бекенда с ООП и паттернами любят иногда разрядится на фронте, отдохнуть в его простоте, и в то же время красоте. Благодаря именно им, знающим ООП и паттерны, появляется на фронте нестандартные элегантные решения, best practices, методологии и подходы которые упрощают работу остальным. А вы говорите "не один" :)

ИМХО без основ программирования, алгоритмизации, понятия композиции, наследования НЕВОЗМОЖНО стать _хорошим_ верстальщиком.

[andreyqin]

vasIvas: спасибо за ваш ответ. В данном случае вопрос больше исходит из контекста jQuery, коллега утверждает, что примеры, подобные приведенному мной - плохо.

[vasIvas]

Alexander Sydorenko: извиняюсь перед всеми, так как "ни один", это я как-то не подумав сказал, я сам плохо ещё в плохо разбираюсь и мне сложно отличить программиста от верстальщика...

[Сергей Протько]

vasIvas: мне кажется что у вас MVC головного мозга. Все намного проще, не MVC мир един (я вообще не понимаю как вы выплыли на ООП, тут нет ничего связанного с этим). Фронтэндщикам ближе MVVM и MVP (как и всем тем кто с GUI работает). MVC (и все ответвления) это идея разделения приложения на отдельные зоны ответственности. Один слой отвечает за вывод данных, второй - за обработку пользовательского ввода и т.д. Нет смысла замарачиваться и париться по поводу соблюдение всех эттих паттернов и т.д. если в итоге вы теряете суть зачем это нужно.

Что до вопроса вверху - У вас есть структура данных древовидная. Вам нужно изменить атрибут ноды в зависимости от состояния дочерней ноды. Одна структура. Никаких классов, никаких паттернов. Просто алгоритмизация. У вас есть выбор - хранить мэпу нод - ребенок - парент или траверсить дерево по изменению ноды.

[vasIvas]

Сергей Протько: слыша, что mvc это не парадигма призванная отделить логику от представления, я пришел к выводу, что у Вас точно не mvc мозга.

По второму могу только сказать, что когда я слышу древо нод,
то представляю древовидный список, состоящий из нод, каждая из которая имеет ссылки на next и prev ноду. Сортируют их одним из... Мне только пять алгоритмов сортировки вспоминается, НО! Их сортируют! Объект не может сортировать сам себя.
Это первое. А второе - в словах ТС я увидел событие, которое сразу отметает структуру списков и навевает мне историю с банальной композицией. А в композиции ( лист вроде называется, а не узел )
вобщем не должен вызывать методы листьев находящихся вверху по композиционной ветви.
Для того, чтобы лист сообщал вверх и придуманы события, которые если находят свой лист, то лист вправе это событие прервать.
В двух словах.

[Сергей Протько]

vasIvas: ноды в дереве не вызывают методов друг друга. Есть некий отдельный объект который отслеживает состояние нод (через ивенты которые имитят эти самые ноды) и дергает методы у других нод.

Что до MVC - именно логику работы с данными и логику представления данных оно и призвано разделить. Но не логику и представление. Люди начинают упрощать и потом усложняют понятия. Более того, не зная основных принципов ООП не понятно откуда все эти идеи берутся и что дают, в результате появляется огромная армия людей которые знают много но не знаю зачем и откуда это все взялось. В итоге по незнанию применяют то или иное решение не к месту или не правильно.

[vasIvas]

Мне остается только прекратить диалог о нодах, так как в самом начале я упомянул, что именно работу jQ не знаю. Но если она работает по Вашему примеру, то мне сложно что-либо сказать.
Прочту книгу о DOM c которым, как я понимаю работает jQ и в будущих темах или в этой напишу.

Что до mvc - Вы как шпион, а не помощник. Из Вас слова вытягивать нужно. Я сейчас только было хотел написать, что Вы мои слова описываете, а оказалось, что если и предыдущие Ваше сообщение прочитать, то оно тоже верное, если к нему за уши притянуть мое.

Ещё дело в том, что я рассматривал mvc, а не логику модели,
логику представления и логику контроллера. Если ещё начать в детский сад, то можно в оправдание сказать, что у кнопки, тоже логика есть.. Но повторю сказанные Вами словами - мы все взрослые люди, что говорит о том, что не стоит придираться к словам.
Модель === логика приложения === логика, вью === визуализацией приложения === представление. А все остальное в контексте mvc это придирки к словам, которые армия людей повторяет, основываясь на неизвестно чем, что порождает ещё большую армию.

И мне интересно с чего Вы взяли что я не знаю принципов ооп
и к чему мне знать то, что было тридцать лет назад. Меня не интересует, как писали на магнитные ленты и если Вы из тех времен,
то я могу сказать, что я за малый отрезок времени смог получить столько информации, сколько Вам открылось лишь за тридцать лет.
Время на месте не стоит и программирование развивается.
Я не буду говорить, что Ваши слова безосновательны, так как уверен, что Вы приведете название "Вашего первоисточника", в котором утверждается, что слова "отделить логику от представления" являются неправильными. После чего я Вам укажу на "свой первоисточник".

Вот если я скажу - "логика контроллера", это же смешно, согласитесь? Но ведь у контроллера есть же логика, но вот только не в контексте mvc.

В js я мало понимаю, но ооп и mvc, это другое...

Answer 4

[Tashiro]

попробуйте на CSS изменить стиль родителя...

Comments

[andreyqin]

Дело не в этой конкретной задачи, это просто пример. Дело в подходе - как будет верно.

[Tashiro]

andreyqin: Верно - так как удобнее и легче потом поддерживать будет, вообще да движение вверх по DOM дереву изначально - порочное, но в вашем случае, подход коллеги неоправданно сложен и избыточен.

Answer 5

[Alexander Sydorenko]

Есть ряд задач, которые не возможно решить с верху - вниз. Вы же навели сразу и контр-пример :) изменение родителя, в связи с действием в потомке. Мне кажется, что еще и потому, что не все можно в css, появилась такая сильная библиотека для манипуляции DOM как jQuery. И пока в ней есть методы на подобие .closest() не стоит заморачиваться по поводу "православности". Тем более если иначе все равно, либо нельзя, либо можно, но намного хлопотнее.

Answer 6

[YemSalat]

Православный метод - вешать листенер на родителя и по таргету определять потомка.
При этом jQuery сохраняет элемент который вызвал событие в переменную delegateTarget обьекта event.

Перефразирую:

$('.wrapper').on('click', 'button', function(event) {    
    $(event.delegateTarget).addClass('selected');
});

Обоснование: Производительность. Зачем что-то искать (closest/find) если и так все есть.

Так что у вас обоих неправильно :)

Comments

[andreyqin]

В таком случае у вас отсутствует делегирование, так как навешиваются обработчики на все обертки кнопок, которых может быть много, вместо того, чтобы навешивать его на одного общего родителя.

[YemSalat]

andreyqin: Не понял. Почему отсутствует делегирование? $('.wrapper') - не общий родитель?

[andreyqin]

Нет, лучше было бы его назвать .button-wrapper, но я думаю, из примера это было понятно.

[YemSalat]

andreyqin: Нафига вешать на "общий родитель", если потом придется вручную искать какие-то элементы??
Делегирование тут не отсутствует, а наоборот, на нем основан пример.

[andreyqin]

YemSalat: почитайте что такое делегирование

[YemSalat]

andreyqin: вы почитайте, а заодно про .on() в jQuery и про то что это и есть делегция событий.

[YemSalat]

andreyqin: event.delegateTarget - вам само название переменной ни о чем не говорит?

[andreyqin]

YemSalat: использование .on() еще не означает использование делегирования. Если бы в вашем примере .wrapper был общей оберткой для всех кнопок, тогда да. Но, как я уже сказал, у каждой кнопки своя обертка.

[YemSalat]

andreyqin:

Но, как я уже сказал, у каждой кнопки своя обертка.

вы это ни разу не сказали, я думал внутри одного .wrapper'a может быть несколько кнопок.
Если так - то конечно не стоит вешать так обработчики.
Про on() я говорил в рамках данного примера. Делегирование событий тут присутствует.

[YemSalat]

andreyqin: PS если у вас правда у каждой кнопки свой wrapper - то у вас задача совершенно не типовая, потому что никто так не делает.
Обычно ограничиваются одним элементом для кнопки, и ей же вешают класс "selected"

[andreyqin]

YemSalat: в комментарии выше я написал, что .wrapper - не общий родитель. Что касается задачи, то она просто выдумана, с сохранением сути: у нас есть много похожих элементов на странице, у каждого элемента есть одинаковый родитель (не общий, а свой у каждого!), и нужно при клике на элемент производить какие-то манипуляции с родителем.