Комментарии 45
Совсем незачем юзеру говорить будет страница перезагружена или нет, ему это фиолетово. Не усложняйте.
Действительно, это выглядит как демонстрация: «Ура! Пользователь, ты представляешь? Мы, наконец, осилили Ангуляр!» :)
Хотя может быть и правда на Камчатке всё так плачевно. Средний пользователь с вечера ставит на загрузку десятки страниц во вкладках, чтобы потом в течение следующих суток их почитать.
Спасибо за фидбэк, но как дать пользователю визуально понять, что не будет загружена новая страница при клике?
Я думаю, что это совершенно ненужная для пользователя информация, следовательно мусор. Средний пользователь просто не поймёт, о чём вы ему хотите сказать, из оставшихся только единицы смогут оценить. Тем более 99,9% интернета как-то прекрасно обходились загрузкой страниц даже во времена диалапа, и никто при этом не страдал.
может быть ховер на картинку какойнибудь. возможно чтото вроде этого.
ну или подчеркивание на заголовках из точек. последнее правда не столь очевидно будет на фоне картинки.
ну или подчеркивание на заголовках из точек. последнее правда не столь очевидно будет на фоне картинки.
Точечное подчёркивание, обычно, означает вызов диалога, вместо навигации. В данном случае примерно это и происходит, так что если для автора это настолько сильно важно, то это самый верный способ.
+ отъезжание иконок вверхв-низ, под которой видно, что что-то есть более подробное
+ подчеркнуть названия пунктиром?
+ подчеркнуть названия пунктиром?
Вы же делаете магазин одностраничным не для того, что бы пользователь порадовался, что он одностраничный, а для того что бы пользователь ощутил скорость работы, отсутствие тех самых признаков перезагрузки типа белого моргнувшего экрана. И вот когда он нажмет, то сам заценит. Он не поймет перезагрузилась страница или нет, но ему понравится)
Так же такой формат позволил избежать хранения товаров корзины в сессиях, localStorage или же в базе данных. Так как мы точно знаем, что человек никуда не уйдёт с этой страницы, мы храним данные корзины в объекте javascript.
Я правильно понял, что если я случайно закрою вкладку, то все мои товары в корзине будут навсегда потеряны? Придётся оформлять заказ заново? Не слишком ли опрометчивый подход?
Подозреваю, что на самом деле вам было банально лень делать человеческую корзину.
Кстати да, зачем избегать localStorage мне не совсем понятно. Туда можно кэшировать стили, в которых «мелкая» графика в base64. И опять таки в localStorage можно собирать объект, который пригодится для аналитики.
В нашем случае нет, средний пользователь не открывает больше 5 вкладок. У меня сейчас открыто 10, потому что я их не закрываю, чтобы потом снова не загружать. А вообще цель статьи была описать общий процесс работы с корзиной, если кто-то захочет развить тему, это его решение. Мы зная наш рынок стараемся делать проще, и конечно же если АБ тесты и вебвизор покажет что 20% пользователей случайно закрывают вкладки, то сделаем с localStorage.
Дело не только в случайно закрытой вкладке. Я могу начать заказывать, затем отвлечься, закрыть браузер, потом захочу вернуться и тут меня ожидает сюрприз. Это просто некрасиво, я считаю, сегодня обманывать ожидания пользователя. А пользователи привыкли к персистентному состоянию корзины, потому что это абсолютная норма. Даже не знаю, почему вы решили иначе. Но дело ваше, конечно, ваши пользователи.
Никакие тесты не покажут случайность закрытия вкладки. Даже не знаю, к счастью это, или к сожалению :)
Если корзина где-то сохраняется между заходами пользователя, — то это небольшой такой плюсик в карму магазина, = повышение лояльности. Вот логинюсь я на чайник, а там в корзине с лета лежат комплектующие.
Представьте, что 3% купивших бы товар случайно закрыли вкладки и посчитайте сколько потеряет магазин. А потом посчитайте сколько строчек кода вам понадобится что бы внедрить хранение корзины :)
Можно же в куки положить всю корзину
Слишком много «но» и «если», чтобы можно было с такой уверенностью отказываться от абсолютного не требующего затрат полезного инструмента. Но конверсия почти точно будет лучше при условии хранения списка/истории заказа.
НЛО прилетело и опубликовало эту надпись здесь
Если бы я писал такую статью, то убрал бы в главной картинке название фирмы и телефон заказа, а то администраци Хабра посчитает это как реклама или убираем все рубрики WEB разработки, ООП и Добро пожаловать в «Я ПИАРЮСЬ!».
Главная задача моего поста решена, теперь на Хабре есть материал, о том как сделать добавление товаров в корзину и подсчёт суммы заказа на AngularJSЭта задача была бы решена, если бы ты оформил все в ввиде модуля библиотеки и выложил это на гитхаб. А как сделать карзину товаров, знает любой WEB разработчик, проработавший более 6 мес.
<a href="#<?= $item['url'] ?>">
про шаблоны — ничего не знаем?
Моё небольшое ИМХО:
добавление в корзину через вставку инлайн 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).
Обучающий материал по написанию корзины товаров на AngularJS?! Вы это серьезно сейчас?
НЛО прилетело и опубликовало эту надпись здесь
А вообще любой «самый быстрый фреймворк» можно замедлить построением дерева категорий больше, чем за 1 запрос к бд.
Так как у нас тут пока ещё свобода слова, то пожалуй оставлю каплю своего негатива.
Никаких обид, говорю только по делу. Статью надо было назвать: «ура, я начал изучать angular js, смотрите что он умеет». Carts в переводе на русский будет тележки. Я не специалист по Phalcon/php, но SQL-запросы в циклах? Не эксперт по деревьям, но думаю тут лучше подошла бы MongoDB для приложения в целом. Больно смотреть на php внутри angular шаблонов, однако если вы настолько обеспокоены своей сео-оптимизацией, то может проще было взглянуть на решения вроде prerender.io? Если бы это был мой магазин, я бы сео-оптимизацией не беспокоил бы себя в принципе. Гораздо проще и выгоднее купить рекламу. А дальше сайт, если хороший — раскрутит себя самостоятельно. Задача сео в данном контексте как раз таки выдать сайт по запросу вроде «заказать пиццу онлайн караганда». Ну и к слову — надеюсь, что вы хотя бы проверяете на сервере что прислал клиент, и перезваниваете ему. Используя мощь AngularJS + localStorage можно чисто на стороне клиента, создать многофункциональный лендинг, который будет делать всё настолько красиво, что серверу останется лишь отдать ему товары (rest/rpc/inline-js) и принять заказ, предварительно его проверив. Какой у вас тут смысл от angular? На Vanilla JS можно то же самое написать и работать будет намного быстрее. Хранить картинки в базе идея плохая на мой взгляд. Да и если я правильно понимаю админов вы «angular'ом» обделили, оставив им «перезагружающиеся страницы». Админка к слову плохая. Внутри не дерево, а просто список аля «проследи кто у кого предок».
НЛО прилетело и опубликовало эту надпись здесь
Вопрос по prerender.io
Получается он прокликивает страницу и сохраняет html-снапшоты всех возможных состояний, которые и отдает в итоге поисковикам?
Получается он прокликивает страницу и сохраняет html-снапшоты всех возможных состояний, которые и отдает в итоге поисковикам?
Нет, не прокликивает.
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. Их можно шарить через соц сети.
А почему был выбран AngularJS? JQuery уже ведь грузится с Zurb Foundation
Я не понимаю, почему раньше чтобы набрать 9 плюсов надо было классную статью написать, а сейчас можно написать что угодно в любом качестве.
Тема не раскрыта.
Почему Phalcon + AngularJS + Zurb Foundation?
Корзина по хорошему, в рамках подобного проекта, пишется на javascript в несколько строк (можно вообще без ооп). В чем преимущество использовать связки эти и т.п.? Зачем в таком простом проекте использовать ORM?
В общем тема поста не соответствует действительности, после прочтения больше вопросов чем ответов. На недели делал одностраничный магазин, на голом php+mysql+javascript по времени ушло часов 10 (с версткой и доп.правками которых не было в макете, сам программинг часа 3-4 ).
Так в чем приемущество? Не будет ли проще, быстрей, понятней и удобней в мелких работах без фреймворков обойтись? Может и не пришлось бы запихивать запрос в цикл.
Почему Phalcon + AngularJS + Zurb Foundation?
Корзина по хорошему, в рамках подобного проекта, пишется на javascript в несколько строк (можно вообще без ооп). В чем преимущество использовать связки эти и т.п.? Зачем в таком простом проекте использовать ORM?
В общем тема поста не соответствует действительности, после прочтения больше вопросов чем ответов. На недели делал одностраничный магазин, на голом php+mysql+javascript по времени ушло часов 10 (с версткой и доп.правками которых не было в макете, сам программинг часа 3-4 ).
Так в чем приемущество? Не будет ли проще, быстрей, понятней и удобней в мелких работах без фреймворков обойтись? Может и не пришлось бы запихивать запрос в цикл.
Можно и без фреймворков вообще и без ORM. Вот сравнение «с фреймворком или без».
Я бы сказал — чем владеет, на том и делает.
В данном случае ORM не страшен, потому его в меру. А та часть Фалькона, которая реалиует микросервисы — очень хорошо подошла бы для Reach Client Application, которые данные с сервера забирают только через AJAX — код получается компактным, изящным.
Я бы сказал — чем владеет, на том и делает.
В данном случае ORM не страшен, потому его в меру. А та часть Фалькона, которая реалиует микросервисы — очень хорошо подошла бы для Reach Client Application, которые данные с сервера забирают только через AJAX — код получается компактным, изящным.
Опять куча фреймворков и как обычно получается «велик»…
А не проще ли использовать готовые решения. К примеру opencart.
Будет гораздо проще, а функционал на много порядков больше.
А не проще ли использовать готовые решения. К примеру opencart.
Будет гораздо проще, а функционал на много порядков больше.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Одностраничный магазин с корзиной на Phalcon + AngularJS + Zurb Foundation