тоже недавно фильтры для ИМ делал. только там фильтры в админке создавались и назначались на каждую категорию. а еще эти фильтры больше для SЕО, то есть нужно формировать для них урл, генерировать уник правильные заголовки, на некоторые комбинации добавлять уник тексты вручную. куча правил для того какие стр разрешено индексировать, а какие нет. и много других фишек. в общем было интересно :)
А я смотрю, если автора хвалят, он лайкает. А если критикуют (не важно по делу или нет) то автор ни как не реагирует. Молодец чё. Сам код ревьюит. А свой код считает идеалом.
Спасибо за материал! Хорошая работа, как всегда. Немного, правда, режет глаз полное отсувствие PHPdocs для написанного, ну да это не критичное замечание :)
Наверное когда сам кодишь, то все ясно и понятно. Мне допустим, базовый фильтр не совсем понятен, много кода получилось. Может логику сделать как в middleware, т.е. каждый фильтр это отдельный файл, который что-то делает и передает результат по цепочке вниз. А в базовом фильтре просто очередь прописать.
ты бы мог сделать класс фильтра унаследоваться его от blade component и имплементировать scope . для нового разработчика его применение было бы уже более очевидным
Очень интересная реализация, не подскажите ли в какую сторону документаций/книг посмотреть что бы подробнее познакомиться с реализацией подобных структурных решений и не городить сложно читаемые/поддерживаемые методы скоупов. Спасибо за внимание и возможные рекомендации.
Подскажите, пожалуйста, для совсем глупых)) Я в принципе во всем разобрался как работает этот подход к созданию фильтров и впечатлился, но не могу разобраться как сделать так чтобы грузились не все фильтры всегда, а только те что нужны для конкретной страницы. Ну например, есть у нас Товары, у них одни фильтры, а есть Фильмы, у них другие фильтры и т.д. Если я правильно понимаю то когда мы их регистрируем чем метод boot в сервис провайдере, они все создаются, т.е и нужные и ненужные. Получается мне нужно где-то по запросу вызывать фильтры, а не в методе boot? И имеет ли смысл их разносить по разным сервис провайдерам, если при таком подходе, насколько я понял, они все равно все вместе зарегистрируются в общем сервис провайдере?
Выглядит в целом неплохо, но есть один большой и очень скользкий момент - почему наша модель знает про контейнер и лезет туда за своими зависимостями? Будет удачнее либо передавать набор фильтров в этот скоуп, либо создать какой-то отдельный класс-сервис, который будет эти фильтры применять. Я бы предварительно выбрал первый вариант, в таком случае мы можем этот класс App заинжектить в метод контроллера и сразу получать набор доступных фильтров, передавая в скоуп. Таким образом мы избавимся от одной неявной зависимости.
Правильный подход, в отличие от первоначального кода. Заказчики с ума по этим фильтрам сходят. Как уже кто-то написал в комментарии - потом придет СЕОшник который заставит отдельные страницы с этими фильтрами делать и т.д. Если просто вывалить их скопом - потом всё равно переписывать придется. А указанным в видео методом всё выглядит лучше. Хотя и очень многословно (по коду, не по видео). Еще короче - на процедурах сделать. Но нонешняя молодёж так не умеет. Им абстракции надо. Ну что-ж, не зря вам по 100 тыщ платят.
Хочется задать вопрос, который меня очень мучает после просмотра этого видео)) Я постараюсь доступнее объяснить свое недопонимание, насколько это возможно. Для того, чтобы получить в сайдбаре доступные фильтры, Вы используете "...->all()->pluck". Такой запрос к БД достаточно быстрый, но при таком подходе выбираются все доступные значения. Но если я, к примеру, выбрал страну "Россия", а в России только 1 доступный терапевт Вася из Москвы, которому 25 лет, нам нужно в этот запрос добавить условие "->where('country', 'Россия')" и т.д. по остальным выбранным фильтрам. Во-первых такой запрос будет выполняться уже долго. А во-вторых, те значения, от добавления которых терапевтов не увеличится в нашей выборке нет смысла выводить. Возвращаясь к моему же примеру, если у нас в России только 1 терапевт Вася из Москвы 25 лет, зачем делать доступными фильтры такие как возраст от 23 до 30 лет, если фактически его возраст 25 и от изменений этого критерия ничего не изменится. Аналогично и по всем остальным атрибутам - зачем выводить пол женский, если нам доступен только атрибут мужчины, все города, если город только Москва и т.д. Или я чего-то не допонимаю?
Интересный подход. Почему бы вместо непонятного App класса, название которого пугает, не сделать базовый FilterGroup + TherapistFilterGroup и в них спрятать уже работу с этим всем?
@@CutCodeRu можно просто архив с этим всем) очень понравился код и хочу сам изучить и внедрять в свои пооекты) достаточно архива если это конечно возможно, спасибо!)
