Одностраничный магазин с корзиной на Phalcon + AngularJS + Zurb Foundation

[Rus_Z]

Совсем незачем юзеру говорить будет страница перезагружена или нет, ему это фиолетово. Не усложняйте.

[posledam]

Действительно, это выглядит как демонстрация: «Ура! Пользователь, ты представляешь? Мы, наконец, осилили Ангуляр!» :)

[posledam]

Хотя может быть и правда на Камчатке всё так плачевно. Средний пользователь с вечера ставит на загрузку десятки страниц во вкладках, чтобы потом в течение следующих суток их почитать.

[chuikoffru]

Так было 5 лет назад, 1мб GPRS связи 7 рублей. Сейчас лучше, 3500 рублей за скорость 400 кбит/сек.

[chuikoffru]

Спасибо за фидбэк, но как дать пользователю визуально понять, что не будет загружена новая страница при клике?

[posledam]

Я думаю, что это совершенно ненужная для пользователя информация, следовательно мусор. Средний пользователь просто не поймёт, о чём вы ему хотите сказать, из оставшихся только единицы смогут оценить. Тем более 99,9% интернета как-то прекрасно обходились загрузкой страниц даже во времена диалапа, и никто при этом не страдал.

[vytya]

может быть ховер на картинку какойнибудь. возможно чтото вроде этого.
ну или подчеркивание на заголовках из точек. последнее правда не столь очевидно будет на фоне картинки.

[posledam]

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

[milar]

+ отъезжание иконок вверхв-низ, под которой видно, что что-то есть более подробное
+ подчеркнуть названия пунктиром?

[vaseninm]

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

[posledam]

Так же такой формат позволил избежать хранения товаров корзины в сессиях, localStorage или же в базе данных. Так как мы точно знаем, что человек никуда не уйдёт с этой страницы, мы храним данные корзины в объекте javascript.

Я правильно понял, что если я случайно закрою вкладку, то все мои товары в корзине будут навсегда потеряны? Придётся оформлять заказ заново? Не слишком ли опрометчивый подход?

Подозреваю, что на самом деле вам было банально лень делать человеческую корзину.

[Glebcha]

Кстати да, зачем избегать localStorage мне не совсем понятно. Туда можно кэшировать стили, в которых «мелкая» графика в base64. И опять таки в localStorage можно собирать объект, который пригодится для аналитики.

[chuikoffru]

В нашем случае нет, средний пользователь не открывает больше 5 вкладок. У меня сейчас открыто 10, потому что я их не закрываю, чтобы потом снова не загружать. А вообще цель статьи была описать общий процесс работы с корзиной, если кто-то захочет развить тему, это его решение. Мы зная наш рынок стараемся делать проще, и конечно же если АБ тесты и вебвизор покажет что 20% пользователей случайно закрывают вкладки, то сделаем с localStorage.

[posledam]

Дело не только в случайно закрытой вкладке. Я могу начать заказывать, затем отвлечься, закрыть браузер, потом захочу вернуться и тут меня ожидает сюрприз. Это просто некрасиво, я считаю, сегодня обманывать ожидания пользователя. А пользователи привыкли к персистентному состоянию корзины, потому что это абсолютная норма. Даже не знаю, почему вы решили иначе. Но дело ваше, конечно, ваши пользователи.

[posledam]

Никакие тесты не покажут случайность закрытия вкладки. Даже не знаю, к счастью это, или к сожалению :)

[Anisotropic]

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

[vaseninm]

Представьте, что 3% купивших бы товар случайно закрыли вкладки и посчитайте сколько потеряет магазин. А потом посчитайте сколько строчек кода вам понадобится что бы внедрить хранение корзины :)

[Timmmm]

Можно же в куки положить всю корзину

[Glebcha]

Зачем если в localStorage до первой зачистки может жить «жирный» объект со статистикой, чтобы напомнить о незакрытом заказе или предложить акцию если после нескольких раз человек так и не решился сделать заказ.

[Glebcha]

Слишком много «но» и «если», чтобы можно было с такой уверенностью отказываться от абсолютного не требующего затрат полезного инструмента. Но конверсия почти точно будет лучше при условии хранения списка/истории заказа.

[akalend]

Если бы я писал такую статью, то убрал бы в главной картинке название фирмы и телефон заказа, а то администраци Хабра посчитает это как реклама или убираем все рубрики WEB разработки, ООП и Добро пожаловать в «Я ПИАРЮСЬ!».

[akalend]

Главная задача моего поста решена, теперь на Хабре есть материал, о том как сделать добавление товаров в корзину и подсчёт суммы заказа на AngularJS

Эта задача была бы решена, если бы ты оформил все в ввиде модуля библиотеки и выложил это на гитхаб. А как сделать карзину товаров, знает любой WEB разработчик, проработавший более 6 мес.

[akalend]

<a href="#<?= $item['url'] ?>">
про шаблоны — ничего не знаем?

[Yavanosta]

Вообще php изначально в общем-то язык-шаблонизатор. Зачем в нем использовать еще один шаблонизатор, который будет написан на каком-то еще мета-языке?

[quantum]

Чтобы не писать постоянно
<?= isset($item['url'])? htmlspecialchars($item['url']): '';?>
?

Тем более, что у phalcon есть volt.

[Fesor]

php был шаблонизатором (причем убогим) для c/c++ очень давно, во времена php1/2. Вспомните JS лет так 8-10 назад.

[steppefox]

Моё небольшое ИМХО:

добавление в корзину через вставку инлайн 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).

[AMar4enko]

Обучающий материал по написанию корзины товаров на AngularJS?! Вы это серьезно сейчас?

[quantum]

А вообще любой «самый быстрый фреймворк» можно замедлить построением дерева категорий больше, чем за 1 запрос к бд.

[karser]

или заюзать nested set/matherialized path

[student_ivan]

Так как у нас тут пока ещё свобода слова, то пожалуй оставлю каплю своего негатива.

Никаких обид, говорю только по делу. Статью надо было назвать: «ура, я начал изучать angular js, смотрите что он умеет». Carts в переводе на русский будет тележки. Я не специалист по Phalcon/php, но SQL-запросы в циклах? Не эксперт по деревьям, но думаю тут лучше подошла бы MongoDB для приложения в целом. Больно смотреть на php внутри angular шаблонов, однако если вы настолько обеспокоены своей сео-оптимизацией, то может проще было взглянуть на решения вроде prerender.io? Если бы это был мой магазин, я бы сео-оптимизацией не беспокоил бы себя в принципе. Гораздо проще и выгоднее купить рекламу. А дальше сайт, если хороший — раскрутит себя самостоятельно. Задача сео в данном контексте как раз таки выдать сайт по запросу вроде «заказать пиццу онлайн караганда». Ну и к слову — надеюсь, что вы хотя бы проверяете на сервере что прислал клиент, и перезваниваете ему. Используя мощь AngularJS + localStorage можно чисто на стороне клиента, создать многофункциональный лендинг, который будет делать всё настолько красиво, что серверу останется лишь отдать ему товары (rest/rpc/inline-js) и принять заказ, предварительно его проверив. Какой у вас тут смысл от angular? На Vanilla JS можно то же самое написать и работать будет намного быстрее. Хранить картинки в базе идея плохая на мой взгляд. Да и если я правильно понимаю админов вы «angular'ом» обделили, оставив им «перезагружающиеся страницы». Админка к слову плохая. Внутри не дерево, а просто список аля «проследи кто у кого предок».

[fetis26]

Видимо товарищ никогда не работал в команде еще. Отсюда и такие грабли. И все эти магические цифры

     if($scope.delivery == 3)
        {
            delivery = 10/total*100*(-1);
        }

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

[fetis26]

Вопрос по prerender.io

Получается он прокликивает страницу и сохраняет html-снапшоты всех возможных состояний, которые и отдает в итоге поисковикам?

[copist]

Нет, не прокликивает.
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. Их можно шарить через соц сети.

[mgkirs]

А почему был выбран AngularJS? JQuery уже ведь грузится с Zurb Foundation

[kostyl]

Я не понимаю, почему раньше чтобы набрать 9 плюсов надо было классную статью написать, а сейчас можно написать что угодно в любом качестве.

[KirEv]

Тема не раскрыта.
Почему Phalcon + AngularJS + Zurb Foundation?
Корзина по хорошему, в рамках подобного проекта, пишется на javascript в несколько строк (можно вообще без ооп). В чем преимущество использовать связки эти и т.п.? Зачем в таком простом проекте использовать ORM?

В общем тема поста не соответствует действительности, после прочтения больше вопросов чем ответов. На недели делал одностраничный магазин, на голом php+mysql+javascript по времени ушло часов 10 (с версткой и доп.правками которых не было в макете, сам программинг часа 3-4 ).

Так в чем приемущество? Не будет ли проще, быстрей, понятней и удобней в мелких работах без фреймворков обойтись? Может и не пришлось бы запихивать запрос в цикл.

[copist]

Можно и без фреймворков вообще и без ORM. Вот сравнение «с фреймворком или без».
Я бы сказал — чем владеет, на том и делает.
В данном случае ORM не страшен, потому его в меру. А та часть Фалькона, которая реалиует микросервисы — очень хорошо подошла бы для Reach Client Application, которые данные с сервера забирают только через AJAX — код получается компактным, изящным.

[maxic]

Опять куча фреймворков и как обычно получается «велик»…
А не проще ли использовать готовые решения. К примеру opencart.
Будет гораздо проще, а функционал на много порядков больше.