Comments 45
Совсем незачем юзеру говорить будет страница перезагружена или нет, ему это фиолетово. Не усложняйте.
+19
Действительно, это выглядит как демонстрация: «Ура! Пользователь, ты представляешь? Мы, наконец, осилили Ангуляр!» :)
+9
Хотя может быть и правда на Камчатке всё так плачевно. Средний пользователь с вечера ставит на загрузку десятки страниц во вкладках, чтобы потом в течение следующих суток их почитать.
+1
Спасибо за фидбэк, но как дать пользователю визуально понять, что не будет загружена новая страница при клике?
0
Я думаю, что это совершенно ненужная для пользователя информация, следовательно мусор. Средний пользователь просто не поймёт, о чём вы ему хотите сказать, из оставшихся только единицы смогут оценить. Тем более 99,9% интернета как-то прекрасно обходились загрузкой страниц даже во времена диалапа, и никто при этом не страдал.
+7
Точечное подчёркивание, обычно, означает вызов диалога, вместо навигации. В данном случае примерно это и происходит, так что если для автора это настолько сильно важно, то это самый верный способ.
0
+ отъезжание иконок вверхв-низ, под которой видно, что что-то есть более подробное
+ подчеркнуть названия пунктиром?
+ подчеркнуть названия пунктиром?
0
Вы же делаете магазин одностраничным не для того, что бы пользователь порадовался, что он одностраничный, а для того что бы пользователь ощутил скорость работы, отсутствие тех самых признаков перезагрузки типа белого моргнувшего экрана. И вот когда он нажмет, то сам заценит. Он не поймет перезагрузилась страница или нет, но ему понравится)
+2
Так же такой формат позволил избежать хранения товаров корзины в сессиях, localStorage или же в базе данных. Так как мы точно знаем, что человек никуда не уйдёт с этой страницы, мы храним данные корзины в объекте javascript.
Я правильно понял, что если я случайно закрою вкладку, то все мои товары в корзине будут навсегда потеряны? Придётся оформлять заказ заново? Не слишком ли опрометчивый подход?
Подозреваю, что на самом деле вам было банально лень делать человеческую корзину.
+6
Кстати да, зачем избегать localStorage мне не совсем понятно. Туда можно кэшировать стили, в которых «мелкая» графика в base64. И опять таки в localStorage можно собирать объект, который пригодится для аналитики.
+6
В нашем случае нет, средний пользователь не открывает больше 5 вкладок. У меня сейчас открыто 10, потому что я их не закрываю, чтобы потом снова не загружать. А вообще цель статьи была описать общий процесс работы с корзиной, если кто-то захочет развить тему, это его решение. Мы зная наш рынок стараемся делать проще, и конечно же если АБ тесты и вебвизор покажет что 20% пользователей случайно закрывают вкладки, то сделаем с localStorage.
0
Дело не только в случайно закрытой вкладке. Я могу начать заказывать, затем отвлечься, закрыть браузер, потом захочу вернуться и тут меня ожидает сюрприз. Это просто некрасиво, я считаю, сегодня обманывать ожидания пользователя. А пользователи привыкли к персистентному состоянию корзины, потому что это абсолютная норма. Даже не знаю, почему вы решили иначе. Но дело ваше, конечно, ваши пользователи.
+1
Никакие тесты не покажут случайность закрытия вкладки. Даже не знаю, к счастью это, или к сожалению :)
0
Если корзина где-то сохраняется между заходами пользователя, — то это небольшой такой плюсик в карму магазина, = повышение лояльности. Вот логинюсь я на чайник, а там в корзине с лета лежат комплектующие.
0
Представьте, что 3% купивших бы товар случайно закрыли вкладки и посчитайте сколько потеряет магазин. А потом посчитайте сколько строчек кода вам понадобится что бы внедрить хранение корзины :)
0
Можно же в куки положить всю корзину
-1
Слишком много «но» и «если», чтобы можно было с такой уверенностью отказываться от абсолютного не требующего затрат полезного инструмента. Но конверсия почти точно будет лучше при условии хранения списка/истории заказа.
0
UFO just landed and posted this here
Если бы я писал такую статью, то убрал бы в главной картинке название фирмы и телефон заказа, а то администраци Хабра посчитает это как реклама или убираем все рубрики WEB разработки, ООП и Добро пожаловать в «Я ПИАРЮСЬ!».
0
Главная задача моего поста решена, теперь на Хабре есть материал, о том как сделать добавление товаров в корзину и подсчёт суммы заказа на AngularJSЭта задача была бы решена, если бы ты оформил все в ввиде модуля библиотеки и выложил это на гитхаб. А как сделать карзину товаров, знает любой WEB разработчик, проработавший более 6 мес.
-2
<a href="#<?= $item['url'] ?>">
про шаблоны — ничего не знаем?
+2
Моё небольшое ИМХО:
добавление в корзину через вставку инлайн PHP скриптов — плохо. Т.к. в идеале, Angular — MVC фреймворк, и в его виды, никто лезть не должен.
Когда контроллеры Angular пухнут, становится сложновато разобрать структуру. Лично для себя, выводил такие предопределенные структуры:
Для всех Agnular-тэгов, лучше подставлять префикс data-, data-ng-model, data-ng-click. Так валиднее, привет опять таки IE.
А еще есть https://github.com/johnpapa/angularjs-styleguide стайлгайд, к которому в принципе можно привыкнуть.
Большинство выводимых данных, лучше выводить через ng-bind или ng-bind-template или ng-bind-html (при наличии модуля $sce).
добавление в корзину через вставку инлайн PHP скриптов — плохо. Т.к. в идеале, Angular — MVC фреймворк, и в его виды, никто лезть не должен.
Когда контроллеры Angular пухнут, становится сложновато разобрать структуру. Лично для себя, выводил такие предопределенные структуры:
$scope.models = {
someModel:0
}
$scope.actions = {
someAction:function() { }
}
Для всех Agnular-тэгов, лучше подставлять префикс data-, data-ng-model, data-ng-click. Так валиднее, привет опять таки IE.
А еще есть https://github.com/johnpapa/angularjs-styleguide стайлгайд, к которому в принципе можно привыкнуть.
Большинство выводимых данных, лучше выводить через ng-bind или ng-bind-template или ng-bind-html (при наличии модуля $sce).
+1
Обучающий материал по написанию корзины товаров на AngularJS?! Вы это серьезно сейчас?
-2
UFO just landed and posted this here
А вообще любой «самый быстрый фреймворк» можно замедлить построением дерева категорий больше, чем за 1 запрос к бд.
0
Так как у нас тут пока ещё свобода слова, то пожалуй оставлю каплю своего негатива.
Никаких обид, говорю только по делу. Статью надо было назвать: «ура, я начал изучать angular js, смотрите что он умеет». Carts в переводе на русский будет тележки. Я не специалист по Phalcon/php, но SQL-запросы в циклах? Не эксперт по деревьям, но думаю тут лучше подошла бы MongoDB для приложения в целом. Больно смотреть на php внутри angular шаблонов, однако если вы настолько обеспокоены своей сео-оптимизацией, то может проще было взглянуть на решения вроде prerender.io? Если бы это был мой магазин, я бы сео-оптимизацией не беспокоил бы себя в принципе. Гораздо проще и выгоднее купить рекламу. А дальше сайт, если хороший — раскрутит себя самостоятельно. Задача сео в данном контексте как раз таки выдать сайт по запросу вроде «заказать пиццу онлайн караганда». Ну и к слову — надеюсь, что вы хотя бы проверяете на сервере что прислал клиент, и перезваниваете ему. Используя мощь AngularJS + localStorage можно чисто на стороне клиента, создать многофункциональный лендинг, который будет делать всё настолько красиво, что серверу останется лишь отдать ему товары (rest/rpc/inline-js) и принять заказ, предварительно его проверив. Какой у вас тут смысл от angular? На Vanilla JS можно то же самое написать и работать будет намного быстрее. Хранить картинки в базе идея плохая на мой взгляд. Да и если я правильно понимаю админов вы «angular'ом» обделили, оставив им «перезагружающиеся страницы». Админка к слову плохая. Внутри не дерево, а просто список аля «проследи кто у кого предок».
+6
UFO just landed and posted this here
Видимо товарищ никогда не работал в команде еще. Отсюда и такие грабли. И все эти магические цифры
которые потом он сам же, спустя полгода, будет мучительно разбирать, когда понадобится добавить еще одно условие доставки или поменять скидку
if($scope.delivery == 3)
{
delivery = 10/total*100*(-1);
}
которые потом он сам же, спустя полгода, будет мучительно разбирать, когда понадобится добавить еще одно условие доставки или поменять скидку
0
Вопрос по prerender.io
Получается он прокликивает страницу и сохраняет html-снапшоты всех возможных состояний, которые и отдает в итоге поисковикам?
Получается он прокликивает страницу и сохраняет html-снапшоты всех возможных состояний, которые и отдает в итоге поисковикам?
0
Нет, не прокликивает.
prerender.io отдаёт поисковому боту HTML, «сфотографированный» после того, как закончатся все AJAX запросы или по установке специального флага.
А вот поисковый бот потом уже «кликает» по ссылкам.
Мы тоже им пользовались почти полгода. Для проекта с 150 000 страниц он стал работать на редкость гадостно.
Взяли исходники, которые лежат на github в упрощённом виде, без веб-интерфейса и очередей, изучили и сделали свой github.com/icons8/impresser
Документация — не пинайте ногами, пожалуйста :( — нет вообще, даже в коде комментариями
Сейчас отрисовывает полмиллиона страниц, по 3-5 секунд на каждую, но делает это регулярно и поисковым ботам выдаёт результат за миллисекунды.
Требует выделенный сервер, потому что фантом очень жрёт процессор и на VDS упирается именно в производительность виртуальных процессоров. Мы взяли один в США, чтобы было максимально близко от серверов, на которых работают гуглоботы.
Зачем prerender/impresser, если гуглобот умеет исполнять Javascript?
Во-первых, гуглобот не понимает, что страница ждёт данных через AJAX — в результате в поисковый индекс попало много пустых страниц с крутящийся картинкой-загрузчиком. У prerender есть специальный флаг в javascript, чтобы подождать, пока страница не готова.
Во-вторых, Yandex, Bing, Yahoo и много других поисковых систем не умеют исполнять JS и видят вообще пустые страницы.
В-третьих, боты социальных сетей не умеют исполнять Javascript. В результате, например, Facebook не видит название страницы и иллюстрацию к ней, если теги Open Graph динамически заполняются через Angular.
Попробуйте сравнить результаты:
Инструкция take.ms/BzPOr черех Google Chrome.
Откройте страницу ic8.link/very_basic в одной обычной вкладке браузера и в другой вкладке в режиме эмуляции устройств с UserAgent = «googlebot».
HTML страницы загружаются быстрее и вообще не содержат никакого JS. Их можно шарить через соц сети.
prerender.io отдаёт поисковому боту HTML, «сфотографированный» после того, как закончатся все AJAX запросы или по установке специального флага.
А вот поисковый бот потом уже «кликает» по ссылкам.
Мы тоже им пользовались почти полгода. Для проекта с 150 000 страниц он стал работать на редкость гадостно.
Взяли исходники, которые лежат на github в упрощённом виде, без веб-интерфейса и очередей, изучили и сделали свой github.com/icons8/impresser
Документация — не пинайте ногами, пожалуйста :( — нет вообще, даже в коде комментариями
Сейчас отрисовывает полмиллиона страниц, по 3-5 секунд на каждую, но делает это регулярно и поисковым ботам выдаёт результат за миллисекунды.
Требует выделенный сервер, потому что фантом очень жрёт процессор и на VDS упирается именно в производительность виртуальных процессоров. Мы взяли один в США, чтобы было максимально близко от серверов, на которых работают гуглоботы.
Зачем prerender/impresser, если гуглобот умеет исполнять Javascript?
Во-первых, гуглобот не понимает, что страница ждёт данных через AJAX — в результате в поисковый индекс попало много пустых страниц с крутящийся картинкой-загрузчиком. У prerender есть специальный флаг в javascript, чтобы подождать, пока страница не готова.
Во-вторых, Yandex, Bing, Yahoo и много других поисковых систем не умеют исполнять JS и видят вообще пустые страницы.
В-третьих, боты социальных сетей не умеют исполнять Javascript. В результате, например, Facebook не видит название страницы и иллюстрацию к ней, если теги Open Graph динамически заполняются через Angular.
Попробуйте сравнить результаты:
Инструкция take.ms/BzPOr черех Google Chrome.
Откройте страницу ic8.link/very_basic в одной обычной вкладке браузера и в другой вкладке в режиме эмуляции устройств с UserAgent = «googlebot».
HTML страницы загружаются быстрее и вообще не содержат никакого JS. Их можно шарить через соц сети.
0
А почему был выбран AngularJS? JQuery уже ведь грузится с Zurb Foundation
-2
Я не понимаю, почему раньше чтобы набрать 9 плюсов надо было классную статью написать, а сейчас можно написать что угодно в любом качестве.
+1
Тема не раскрыта.
Почему Phalcon + AngularJS + Zurb Foundation?
Корзина по хорошему, в рамках подобного проекта, пишется на javascript в несколько строк (можно вообще без ооп). В чем преимущество использовать связки эти и т.п.? Зачем в таком простом проекте использовать ORM?
В общем тема поста не соответствует действительности, после прочтения больше вопросов чем ответов. На недели делал одностраничный магазин, на голом php+mysql+javascript по времени ушло часов 10 (с версткой и доп.правками которых не было в макете, сам программинг часа 3-4 ).
Так в чем приемущество? Не будет ли проще, быстрей, понятней и удобней в мелких работах без фреймворков обойтись? Может и не пришлось бы запихивать запрос в цикл.
Почему Phalcon + AngularJS + Zurb Foundation?
Корзина по хорошему, в рамках подобного проекта, пишется на javascript в несколько строк (можно вообще без ооп). В чем преимущество использовать связки эти и т.п.? Зачем в таком простом проекте использовать ORM?
В общем тема поста не соответствует действительности, после прочтения больше вопросов чем ответов. На недели делал одностраничный магазин, на голом php+mysql+javascript по времени ушло часов 10 (с версткой и доп.правками которых не было в макете, сам программинг часа 3-4 ).
Так в чем приемущество? Не будет ли проще, быстрей, понятней и удобней в мелких работах без фреймворков обойтись? Может и не пришлось бы запихивать запрос в цикл.
+2
Можно и без фреймворков вообще и без ORM. Вот сравнение «с фреймворком или без».
Я бы сказал — чем владеет, на том и делает.
В данном случае ORM не страшен, потому его в меру. А та часть Фалькона, которая реалиует микросервисы — очень хорошо подошла бы для Reach Client Application, которые данные с сервера забирают только через AJAX — код получается компактным, изящным.
Я бы сказал — чем владеет, на том и делает.
В данном случае ORM не страшен, потому его в меру. А та часть Фалькона, которая реалиует микросервисы — очень хорошо подошла бы для Reach Client Application, которые данные с сервера забирают только через AJAX — код получается компактным, изящным.
0
Опять куча фреймворков и как обычно получается «велик»…
А не проще ли использовать готовые решения. К примеру opencart.
Будет гораздо проще, а функционал на много порядков больше.
А не проще ли использовать готовые решения. К примеру opencart.
Будет гораздо проще, а функционал на много порядков больше.
-1
Sign up to leave a comment.
Одностраничный магазин с корзиной на Phalcon + AngularJS + Zurb Foundation