1. Чтобы обработчик сработал на перезагруженной странице его нужно вешать не на клик, а $('document').on('ready', cb).
2. Вам решать использовать preventDefault или нет. Он решает одну конкретную задачу — не допускает выполнения стандартного поведения определенных элементов (ссылки, кнопки, инпут-сабмит и подобные). Срабатывает в любом случае, если выполняется дело доходит до его исполнения. Если вам кажется что он не сработал, значит колбек, которые его содержит не был выполнен вообще.
ligisayan: тут нужно проговорить фундаментальные моменты, которые вы кажется упускаете.
1. Если происходит перезагрузка страницы по клику на ссылку, коей и является элемент .remove-item, то этот все что бы вы дальше не написали не сработает, потому что на рефрешнутой странице никто не сделал клика, на который вы расчитываете. Он был сделан на старой странице, которой уже нет.
2. Использование e.preventDefault() позволяет избежать перезагрузки. В этом случае не нужно открывать меню, оно вообще не закроется. Но разумеет ТОВАР НЕ БУДЕТ УДАЛЕН сам собой. О его удалении придется позаботиться вам. Нужно будет сделать запрос к серверу, который удалит товар из корзины пользователя и нужно будет удалить сниппет элемента со страницы. Повторюсь, магии не произойдет и само не удалиться.
ligisayan: Вообще, ЭТО НЕВОЗМОЖНО. Но раз это происходит, то у меня есть следующая теория. Во-первых, если элементы, на которые вы добавлили обработчик событий появляются на странице динамически, то есть в результате работы других скриптов, то ваш обработчик на них не сработает. В таких случаях нужно использовать делегирование $('родитель-нужных-элементов-который-точно-есть-на-странице-с-самог-начала').on('click', '.remove-item', function(e) { ...далее по списку... }); Без этого ваш обработчик вообще никогда не запускается, чтобы мы внутри него не прописали.
1. removeItem() - не смог найти такой метод в документации jQuery
2. .data('name') - возвращает именованное значение, привязанное к определенному элементу DOM, а не объект jquery через который можно манипулировать связанным элементом DOM
Ага, он точно также как и все остальные языка станет в webassembly замечательно компилироваться. И сделают это сильно раньше, чем для «востребованных back-end языков» :)
Написано только что
Роман: я не специально, просто последние несколько дней подробно читаю тостер и несколько огорчен тем, насколько здесь много «ответов» в которых кроме наездов ничего нет. На stackexchange.com совсем иная атмосфера. Решил не стоять в стороне, когда такой хороший ответ пропадает :)
Вы написали замечательный ответ, но его можно сделать еще лучше, сделав самую малость. Нужно убрать самое первое предложение. Из ответ исчезнет наезд и упрек, его будет психологически проще воспринять. Это пойдет на пользу сообществу.
Удивительно, но поиск по расширениям для хрома не помог найти что-то подходящее. Странно, ведь алгоритм не кажется сложным.
1. Проверить наличие класса у элемента. Если класса нет, то найти ближайший родитель у которого есть класс.
2. Проверить найденный класс на уникальность. Проверка на уникальность это отдельный разговор. Скорее всего придется смотреть не только страницу, но и css-файлы.
3. Таким путем найти уникальный класс и построить от него селектор до текущего элемента с минимальной вложенностью.
Работает эта фича, честно говоря так себе. Вместо класса присвоенного элементу возвращает что-нибудь бесполезное, а иногда даже и вредное, например #js-canvas > footer > img вместо .footer__pix
