Денис Кайназаров

id краткой и полной информации совпадают на сколько я понял.

В принципе можно на фронте создать дополнительную страницу
item/:id/details в этом и при показе страницы item/:id подставлять в details id из страницы самой карточки на ссылку подробнее.

Лучше конечно инициализировать объект - хранилище в котором можно сохранять таки промежуточные результаты. Особенно если id не будут совпадать.

var window.my-store.card.id = <текущий объект>

Сам же использую уже готовое решение чтобы не городить велосипеды в виде https://nuxtjs.org
Там сразу и готовый фронт-сервер для PWA с поддержкой SSR и Vue.js + VueX (то самое хранилище) и еще UI-kit один из 5 на выбор (например есть киты c material design и bootstrap).

Все зависит от того кто и как будет обращаться к backend.

Если это другой сервер, мобильное приложение или SPA то лучше использовать токены - JWT как самый распространенный вариант.

В случае обычного сайта или SPA возможно использовать сессии.

Если используем обычные статические страницы + http api тогда сессия вполне нормальный вариант в том числе и для приложения по типу web-view.

Если используем SPA с REST api / Graphql тогда токены удобнее.

Что касается где хранить id пользователя в токене то самом JWT есть заголовок для этого. Вообще Jwt это 2 json + хэш/ключь слепленные вместе через base64.

Первый json - служебный в нем идет алгоритм и тип ключа, второй - настраиваемый и может содержать что угодно, правда для некоторых моментов например id токена (jti) или id сессии (sid) есть предопределенные заголовки. Полный их список тут

В вашем случае есть 2 варианта

1 - доступ по сессии
API и SPA требует сессию для защищенных методов, авторизация эту сессию предоставляет. Авторизация - может быть выполнена как обычной статической html с формой так и отдельным SPA.

2 - доступ по токену
В этом случае Авторизация реализуется в виде api на стороне сервера, и в виде токена
+ формы + логики авторизации на стороне клиента (Vue). Если токен есть - тогда есть доступ, если нет - то доступ только к методам регистрации и авторизации.
Чтобы не палить код той части приложения где есть логика и фронт закрытой части - можно использовать code-splitting - сперва подгружается форма авторизации а остальное грузиться тогда когда это нужно.

Есть правда еще более извращенные варианты вроде SPA с SSR на том-же Nuxt/Next/Express где пользователю токен а бэку на Go/JAVA/PHP уже токен приложения + токен пользователя.
Иногда стоит использовать OAuth2.0 и LDAP которые тоже довольно интересны.
Первый хорош на все случаи жизни, но только если используется куча связанных приложений/микросервисов а второй просто рай для бизнес-пользователей с Windows для какой-нибудь коробочной CMS.

Проблема медленной загрузки не в js и даже не в php а в api/бд которые дергает
checkLibraryOne и checkLibraryTwo.

Если используется база - тогда оптимизируем её, если api - тогда
- Кешируем ответы api
- Создаем отдельные точки вызова для каждого метода
- Создаем объект в котором будет храниться список библиотек
- Создаем на каждую точку свой ajax запрос который модифицирует список
- При модификации списка обновляем и сам dom
- Если список пуст и запросы еще pending - тогда показываем spinner чтобы все видели что мы что-то грузим

При загрузке страницы по какой-то причине jquery событие не связанно с формой следовательно

$('.form form').submit(function(e) {
...

Не отрабатывает

Причина скорее всего в порядке загрузке скриптов, другой скрипт модифицирует dom формы в результате чего привязка к событию теряется. А таких скриптов я обнаружил более одного, но что они делают я не могу сказать так как они минифицированные.

Советую попробовать запускать этот скрипт в последнюю очередь, либо разобраться со сторонними скриптами которые влияют на dom этой формы.

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

У меня знакомые встраивали тэг аудио на сайте и запускали при событии js правда не для уведомлений.

Скорее всего при загрузке страницы на стороне сервера добавляется инкремент в таблицу. Отдельные запросы для этого достаточно редко используются.

Тут только пилить свое с нуля, в принципе достаточно не сложная вещь.

Во первых определить по каким критериям будет повышаться и понижаться рейтинг (like/dislike или 1-n звезд), кто может повышать/понижать рейтинг - толпа анонимов или только зарегистрированные пользователи, а может те кто вошел через логинзу и прочие сервисы соцсетей?

Самый простой вариант создать базу или хэш-таблицу с полями - id, пользователь, оценка, unix_time

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

спасибо всем, пришлось перекапать все исходники двух проектов но не зря. Нашел 4 шела и парочку скриптов которые и выдавали вирусы пользователям. В данный момент все отлично.