Comments 16
делегировать события от body — плохая практика. Нужно стараться привязывать обработчики к контейнеру, в котором происходит подмена контента. Во-первых производительность будет чуточку лучше, ну и просто можно проще распределить что к чему. Ну и опять же, без Pub/Sub (у автора в статье этот подход рассматривается как совершенно отдельный совет) для чего-то сложнее сайта-визитки все превращается в кашу. Так же делегированные события полезны при необходимости уменьшить количество обработчиков (если у вас есть большое количество однотипных элементов, на которых нужно обрабатывать какие-то действия. Особенно это актуально на мобильных девайсах).
По поводу кеширования… А чем http-кеширование не угодило? Способ автора подходит только для простых случаев со статическим контентом, который не меняется в краткосрочном периоде. Задержки при использовании http кеширования не настолько большие, и они позволяют быть уверенными, что мы получим актуальные данные с сервера.
Опять же вопрос по поводу разделения линков для ajax и не ajax можно решить более красиво, нежели проверять href. Мне нравится подход, при котором все внешние ссылки идут с target="_blank", которые так же можно отсекать через фильтр по селектору, ну и ненужно ничего хардкодить как в вашем примере.
По поводу кеширования… А чем http-кеширование не угодило? Способ автора подходит только для простых случаев со статическим контентом, который не меняется в краткосрочном периоде. Задержки при использовании http кеширования не настолько большие, и они позволяют быть уверенными, что мы получим актуальные данные с сервера.
Опять же вопрос по поводу разделения линков для ajax и не ajax можно решить более красиво, нежели проверять href. Мне нравится подход, при котором все внешние ссылки идут с target="_blank", которые так же можно отсекать через фильтр по селектору, ну и ненужно ничего хардкодить как в вашем примере.
Нужно стараться привязывать обработчики к контейнеру, в котором происходит подмена контента.
Не могу не удержаться еще раз попиарить библиотеку cornerJS, которая занимается именно этим. Точнее, все даже лучше — она привыязывается к подменяемому контенту.
Собственно, для решения этой проблемы я ее и пилил.
Кстати, как альтернатива — есть Mozilla x-tags (IE9+) и Google Polymer (IE10+), реализающие привязку к элементам — правда, не в формате директив, а в формате custom elements/web components.
Еще есть jQuery MX(про него, правда, только слышал), который предлагает помимо всего прочего регистрацию событий в формате
'.parent .container click', отвязывающийся от текущей структуры, и реализующий делегирование событий от body с удобным синтаксисом.
Кешировать AJAX запросы? Зачем?
Браузеры прекрасно справляются с этим сами.
10 почти одновременно вышедших запросов на один и тот же url на самом деле будут одним запросом.
Более того, если API возвращает правильные заголовки кеша — то и инвалидация будет правильной и в нужное время.
Все события на body? В плане производительности очень сомнительный совет… Все таки следить за созданием и подписываться-отписываться от событий более правильно. Body это легче в реализации для маленьких проектов, но слишком энерго-неэффективно и ненадежно для больших.
upd: опоздал :)
Браузеры прекрасно справляются с этим сами.
10 почти одновременно вышедших запросов на один и тот же url на самом деле будут одним запросом.
Более того, если API возвращает правильные заголовки кеша — то и инвалидация будет правильной и в нужное время.
Все события на body? В плане производительности очень сомнительный совет… Все таки следить за созданием и подписываться-отписываться от событий более правильно. Body это легче в реализации для маленьких проектов, но слишком энерго-неэффективно и ненадежно для больших.
upd: опоздал :)
Если вы делали AJAX блог, то интересно услышать что вы делали с индексацией сайта поисковиками? Потому что схемы (1 и 2) предлагаемые поисковиками требуют создания снапшотов, что приводит к необходимости использовать решения вроде этого или же вообще двойной реализации интерфейсов сначала в javascript'е, а потом на стороне сервера, оба варианта конечно навевают серьёзную тоску.
Снапшоты могут отличаться от того, что видит пользователь, так что это может сильно упростить реализацию серверной части. Во всяком случае это дешевле, чем дублировать полностью клиентскую логику на сервере (мол статическая и динамическая версии сайтов). А других способов прикрутить индексацию как бы и нету.
Изучите Backbone/Angular/Ember и все эти советы перестанут быть нужны! :-)
Тоже показался странным вообще посыл статьи для финала 2013 года на дворе. Пишешь крохотульку – пиши как угодно. Не запутаешься и будет оно работать. Пишешь монстра – пользуй серьезные обдуманные до тебя каркасы; иначе потонешь в своих пабсабах.
Ага, а ведь 350 человек добавили у себя в избранное
Лююююди! Это плохая отправная точка…
Лююююди! Это плохая отправная точка…
Специально поставил тег «новичкам» и хотел еще «сложных» поставить в кавычки… Советы спорные, но лично я бы не советовал «новичкам» начинать с фреймворков. Это тоже самое что начинать учить jQuery не зная JavaScript.
ИМХО в программировании нужно двигаться от простого к сложному. Если ты можешь написать велосипед, ты сможешь оценить + и — готового решения, которое ты собираешься применить в проекте. В противном случае мы получаем код в котором jQuery используется для вызова alert и человек не понимает что можно сделать быстрей оптимальнее и проще…
Из мира прикладного программирования встречал я такие примеры когда программа которая показывает окошко «Hello World» тянет за собой 70 мегабайтов библиотек для её запуска (.NET), когда так же программа вписывается в один вызов MessageBox Windows API и занимает в скомпилированном виде 1,3 Кб не теряя функциональности во всех версиях ОС.
ИМХО в программировании нужно двигаться от простого к сложному. Если ты можешь написать велосипед, ты сможешь оценить + и — готового решения, которое ты собираешься применить в проекте. В противном случае мы получаем код в котором jQuery используется для вызова alert и человек не понимает что можно сделать быстрей оптимальнее и проще…
Из мира прикладного программирования встречал я такие примеры когда программа которая показывает окошко «Hello World» тянет за собой 70 мегабайтов библиотек для её запуска (.NET), когда так же программа вписывается в один вызов MessageBox Windows API и занимает в скомпилированном виде 1,3 Кб не теряя функциональности во всех версиях ОС.
Тема document.body.onbeforeunload не раскрыта
Sign up to leave a comment.
6 советов для создания сложных AJAX сайтов