в кусок шаблона Vue нужно вставить кусок шаблона с сервера, где в него подставлены нужные данные после необходимой обработки - у вас начнутся проблемы при таком разделении
А в чём проблема запросить этот кусок по апи?
Это на мелком проекте можно весь мусор забросить в одну кучу, а на больших обязательно нужно разделять фронт и бэк, а не превращать проект в tarball. Тем более на фронте есть своя инфраструктура и им не зачем завязываться на фреймворк и php.
Александр Маджугин, ну так если можно ускорить в десятки тысячи раз - то это говорит об очень плохой архитектуре изначально. Битрикс - это платный коробочный продукт с готовым функционалом. Почему кто-то должен лезть в код и ставить костыли для оптимизации?
Вот в рамках данного проекта битрикс вовсе не имеет нужного функционала, зачем платить за пустую коробку? Даже на wordpress такое можно быстро собрать и это будет абсолютно бесплатно, работать быстрее и легче в поддержке и экономия даже на услугах хостинга.
DenisCern, так сами перейдите по ссылке и дочитайте документацию до конца.
Джойн ручной вам не нужен, просто пропишите relation в модели и доступ к связанной таблице через дот натацию.
Troodi Larson, зачем вам использовать id пользователя?
Добавьте поле isAdmin равное 1 для админа у модельки User, для тогда будет нормальная читаемая проверка Auth::user()->isAdmin. Можете заводить несколько админ аккаунтов, а не завязываться на уникальный id.
Андрей Бойченко Про локалсторадж я не совсем понимаю зачем он вам. Если у вас одностраничник без перезагрузок, то данные обычно можно хранить в памяти (переменная, redux и т.д.) Но у меня слишком мало информации о вашем кейсе, чтобы давать советы.
hidden был костылём для json сериализации до того, как во фреймворке появились ресурсы.
Так что если используете ресурсы, то лучше на hidden вовсе не смотреть и не использовать.
Evgeny Erofeev, это в простом приложений, там без разницы что использовать и даже глобальный стейт может быть удобным. А вот в большом этот стейт становится ветвистым и занимает мегабайты и очень сильно не хватает инкапсуляции присущей обычному подходу.
Я уже насмотрелся на разные флакс подходы в реальных приложениях, у нас больше десятка проектов и везде по мере роста вылазят траблы из-за разрастания стейта.
Здесь вопрос не о валидации, а о верификации. Не надо проверять каждый параметр, заменять на дефолтное значение или говорить какая именно ошибка. Это фильтр, не те поля послал, не то значение, получишь либо ошибку, либо пустой результат. Здесь не надо валидировать - вы искалали Вася в поле имя, а в таблице есть только Сергей и Дима.
Ян Минибаев: только с документацией есть тонкий момент - примеры демонстрируют конкретный компонент, а не хорошие практики. Например, не использовать статические вызовы, а использовать внедрением зависимостей.
Ян Минибаев: ну там же обычный php
parent::__construct - вызывается родительский конструктор в который передаётся объект $menu
Это экземпляр класса MenusRepository в конструктор которого передаётся объект \Corp\Menu
Vanya Huk: ой, не тот код вставил.
Тогда наверное лучше использовать второй параметр для select
Filter::select('*', \DB::raw("( SELECT COUNT(*) from filter_products
where product_id in ( select category_products.product_id from
category_products where category_products.category_id = :category
group by category_products.product_id
) and filters.id = filter_products.filter_id
) as total"), [ 'category' => $this -> category_id] )
А в чём проблема запросить этот кусок по апи?
Это на мелком проекте можно весь мусор забросить в одну кучу, а на больших обязательно нужно разделять фронт и бэк, а не превращать проект в tarball. Тем более на фронте есть своя инфраструктура и им не зачем завязываться на фреймворк и php.