Да, наглядность получившегося кода - хуже, чем foreach, согласен. Но я просто обожаю такие красивые лаконичные решения :) Боюсь что не смогу удержаться от использования Пайплайна. Спасибо брат ты красавчик! Лучи добра тебе
Автор верно сказал что, в данном случае профита нет. В одном из проектов мне довелось очень удачно ввести пайплайн для сложной проверки оформления заказа. Так как в проекте используется rest api, данные с фронта необходимо перепроверить. Первым этапом проверяем товары из корзины: цены, кол-во. Затем проверяем акционные товары, так же на цены, на то, могут ли товары из разных акций совмещаться между собой. Затем мы проверяем ранее проверенные товары на зоны доставки, входят они или нет, автоматически определяем филиал и стоимость доставки. Далее подарочные товары. И в целом так далее. Вот мы и приходим к пайпу. Берем заказ, поочередно проверяем его, каждый класс - ответственен за свою логику. И самое важное, что бы мне в будущем добавить какую либо новую проверку, достаточно создать класс и передать его в пайплайн
Спасибо что уделили внимание моему комментарию :) Очень приятно :) Видео познавательное и интересное, но все равно мне показалось мало информации о пайпах: где и почему используются в ларе. Если кому-то интересно почитать доступную статью с примерами на данную тему, почитайте у demiart статью, там три части. Благодаря ей я узнал о что такое пайпы и с чем их едят) Ну и комментарий о том, что другой, не очень опытный, программист не поймёт что это и как это работает - притянуто за уши. Эта тему очень довольно просто доступно объяснить, а уж загуглить тем более)
It's like a decorator and the same style is used in Laravel middleware. And of course, your last comment was on point, it's not that readable. But still thank you, cause it was a good example.
Тут самое же главное, что как в middleware (которые под капотом через пайпы и реализованы), мы можем решать, вызвать нам next, не вызывать, когда вызывать, что делать с результатом и т.п.
Не понял, изменили нижнюю границу диапазона стоимости с 0 до 400, и не нашлось ни одного результата, но до применения фильтра полным полно терапевтов со стоимостью выше 400. Объясните, пожалуйста.
Мидлваров может быть сколько угодно, их и по умолчанию больше чем фильтров а фильтры сами дополняют query builder условиями, строят sql запрос и в процессе никакой нагрузки нет Не верьте ощущением, доверяй фактам
@@CutCodeRu Ну если бы фильтров реально было много, всё равно бы стек перегрузился... Можно, в принципе, эксперимент поставить, но тут наполнение стека - как при достаточно глубокой рекурсии, можно даже сказать, что в каком-то смысле она и есть. Этими $next мы всё глубже и глубже уходим. Пых просто способен достаточно глубоко уходить. Но учитывать это надо
![[LIVE] : ONE ลุมพินี 90 | คู่เอก "ก้องไกล vs แอนตาร์"](http://i.ytimg.com/vi/VugIvOstzRI/mqdefault.jpg)
Вижу cutcode, ставлю лайк не глядя 👍
Спасибо
Не надо не глядя 👆🏻
Да, наглядность получившегося кода - хуже, чем foreach, согласен. Но я просто обожаю такие красивые лаконичные решения :)
Боюсь что не смогу удержаться от использования Пайплайна.
Спасибо брат ты красавчик! Лучи добра тебе
Супер! Мне очень понравилось то видео про рефакторинг фильтров, а про пайпы я и не знал, спасибо!
Спасибо за полезный урок) Радует что у вас растет уровня и качество контента.
Стараемся по полной)
Спасибо, познавательно :) 👍
Пока не понял его пользы, но за труд спасибо!
Еще много раз к ним вернемся
Автор верно сказал что, в данном случае профита нет.
В одном из проектов мне довелось очень удачно ввести пайплайн для сложной проверки оформления заказа. Так как в проекте используется rest api, данные с фронта необходимо перепроверить. Первым этапом проверяем товары из корзины: цены, кол-во. Затем проверяем акционные товары, так же на цены, на то, могут ли товары из разных акций совмещаться между собой. Затем мы проверяем ранее проверенные товары на зоны доставки, входят они или нет, автоматически определяем филиал и стоимость доставки. Далее подарочные товары. И в целом так далее.
Вот мы и приходим к пайпу. Берем заказ, поочередно проверяем его, каждый класс - ответственен за свою логику. И самое важное, что бы мне в будущем добавить какую либо новую проверку, достаточно создать класс и передать его в пайплайн
@@АндрейОринин-б2э да с процессами обработки заказа отличный пример, ну и мидлвары также работают через пайплайн
Удобно для вызова последовательной цепочки действий. Например, загрузка, обработка файла и т.д.
Спасибо что уделили внимание моему комментарию :) Очень приятно :) Видео познавательное и интересное, но все равно мне показалось мало информации о пайпах: где и почему используются в ларе. Если кому-то интересно почитать доступную статью с примерами на данную тему, почитайте у demiart статью, там три части. Благодаря ей я узнал о что такое пайпы и с чем их едят)
Ну и комментарий о том, что другой, не очень опытный, программист не поймёт что это и как это работает - притянуто за уши. Эта тему очень довольно просто доступно объяснить, а уж загуглить тем более)
у каждого своё мнение
@@CutCodeRu никто этого не отрицал. Для этого и созданы комментарии )
Не поймёт! Я джунам объяснял - и было им тяжко.
Это уже скорее мидловская тема
It's like a decorator and the same style is used in Laravel middleware. And of course, your last comment was on point, it's not that readable. But still thank you, cause it was a good example.
как всегда лайк 🙂 Автору большое спасибо за ваши труды, очень интересно смотреть 🙂😃
Тут самое же главное, что как в middleware (которые под капотом через пайпы и реализованы), мы можем решать, вызвать нам next, не вызывать, когда вызывать, что делать с результатом и т.п.
Вау) это очень круто)
У нас на канале много всего интересного!
Дык это же паттерн Chain of Responsibility (Цепочка обязанностей) походу! На рефакторинг.гуру есть пример.
А так то спасибо за краткое хорошее овервью
спасибо за видос )
Наверное стоило упомянуть о паттерне цепочка ответственности, по сути пайплайн реализация этого паттерна, но с небольшими наворотами.
тоже думал что к этому сведет Данил в итоге..
Не было такой цели)
@@CutCodeRu а зря. Если ознакомится с этим паттенрном, то и пайплайны станут понятнее и с мидлварами тоже проще будет.
можно фильтрацию просто через цепочку обязанностей сделать, а можно еще через декорацию. У каждого варианта свои +/-
Про статистику: И 50% кто подписан не смотрят) Спасибо за труды!
Вот хулиганы)
Классное видео. А в handle при применении apply не надо получать ответ чтобы дальше его пробросить?
Может выгода этого подхода и не велика, но для расширения сознания нужно попробовать.
Добрый день. Подскажите, пожалуйста, будет ли туториал по написанию полноценного функционала данной (или похожей) фильтрации у Вас на канале? Спасибо.
Добрый, будет огромный курс, где мы рассмотрим фильтры и многое другое
Самой простой пример pipline это Gulp
🤔
Интересно, а pipline которые сам фреймворк использует это те-же piplines что в видео рассматривают?
Да
Пусть просвящаются)
👍
Не понял, изменили нижнюю границу диапазона стоимости с 0 до 400, и не нашлось ни одного результата, но до применения фильтра полным полно терапевтов со стоимостью выше 400.
Объясните, пожалуйста.
Там не только фильтр с ценой применяется
@@CutCodeRu стоят какие-то дефолтные галочки/ползунки, которые не применяются при загрузке страницы?
Стек не офигеет от таких пайплайнов?
На какой-то цифре наверняка. Но она, думаю, достаточно большая. Middleware под капотом как раз через пайпы работают.
@@МихаилКрамер-н7ш, мидлваров там не так много, все-таки. А здесь есть ощущение, что можно доиграться.
Мидлваров может быть сколько угодно, их и по умолчанию больше чем фильтров а фильтры сами дополняют query builder условиями, строят sql запрос и в процессе никакой нагрузки нет
Не верьте ощущением, доверяй фактам
@@CutCodeRu Ну если бы фильтров реально было много, всё равно бы стек перегрузился... Можно, в принципе, эксперимент поставить, но тут наполнение стека - как при достаточно глубокой рекурсии, можно даже сказать, что в каком-то смысле она и есть. Этими $next мы всё глубже и глубже уходим. Пых просто способен достаточно глубоко уходить. Но учитывать это надо
@@МихаилКрамер-н7ш учитывать надо все
Пример о трубах на дороге вообще плохой. уж лучше конвейер на заводе привести.
Ну на мой взгляд отличный пример, поэтому его и использовал)
Спасибо, познавательно :) 👍