Для простоты можно и без бэма обойтись. Повторюсь, за позиционирование отвечает родитель. Это написано на сайте методологии. У этого есть основания. Т.е. позиционироваться может только элемент и соответственно его модификаторы, а не модификаторы блока.
В CSS по БЭМ стили, отвечающие за внешнюю геометрию и позиционирование, задаются через родительский блок.
Модификатор не отвечает за позиционирование, а микс может только потому, что мы можем смиксовать элемент. А что такое элемент? Это то, за что отвечает родительский блок, а не текущий.
И что будет, если я захочу использовать .sticker вне .stickers? Всё сломается. Потому что расположение определяет контекст родителя.
За позиционирование отвечает родитель, а не сам блок. Это написано даже на сайте bem.info. Смысл в том, что блок может находиться в разных местах, он понятия не имеет, где именно, и отвечает только за то, что происходит внутри него. А вот родитель уже позиционирует свой элемент, который по совместительству является блоком.
Сейчас у вас переиспользование блоков стремится к нулю. А смысл тогда разбивать всё на блоки и элементы? Можно и просто обозвать без всяких БЭМов. Всё так же будет хорошо жить.
Иногда кажется, что легче пропустить проверку на «null» и просто перехватывать соответствующие исключения.
Иногда лучше пропустить проверку на null и просто перехватить исключение. Есть то, что мы ожидаем и то, чего мы не ожидаем в нормальной работе приложения. Если мы ожидаем null, например, пользователь не включил чекбокс или это значение по умолчанию, то естественно это не исключение.
А если в длинной цепочке вызовов закралась ошибка и вдруг пришел null вместо ID пользователя, хотя тут явно должен был быть ID? Это как раз исключение. Мы выкидываем исключение и ловим его там, где нам надо обработать его (залогировать, сообщить пользователю об этом, откатить транзакцию и т.п.).
Исключения в нормальной ситуации должны происходить довольно редко по отношению к другим событиям. Из-за этого выигрыш будет минимальным.
3 и 4 способы ещё можно понять, но вот 1, 2 и 5 — это ж просто документация.
БЫСТРАЯ ПРАВКА: Поскольку это functional компонент, его контекст не существует, поэтому для доступа к props необходимо применить props.name — спасибо Динешу Мадханлалу за упоминание
Примечание: в версиях до 2.3.0 опция props необходима, если вы хотите использовать входные параметры в функциональном компоненте. С версии 2.3.0 и выше вы можете опустить опцию props и все атрибуты, найденные на узле компонента, будут неявно извлечены в качестве входных данных.
Ну не знаю, возможно, я один такой, но после 2-й смены полок в Ашане за пол года (учитывая, что ходил в Ашан раз в месяц) мне это надоело и я перешел на онлайн покупки к конкурентам.
Такую навигацию да в Ашан, Ленту или Окей. При чём желательно по позициям, хотя бы примерно. А то приходишь со списком и мечешься от одного угла к другому, т.к. макароны в одном месте, туалетная бумага в другом, крупы в третьем, ой забыл ватные диски взять возле туалетной бумаги…
Даже хотел подобное сделать своими силами, а потом понял, что они меняют полки местами чаще, чем я еду к ним :(
А так составил список покупок дома, пришёл в гипер, а за тебя уже маршрут построен. Прошелся быстро, всё понакидал в корзину и довольный пошёл домой с 10 пакетами. А если к этому добавить ещё и автоматическую оплату, как у амазона, то вообще улёт.
Не скажу за реакт, но у vue решили отказаться от реализации нативной поддержки классов для компонентов (сейчас у них через декораторы и не совсем красиво) в 3-й версии в пользу своего аналога хуков. Всё больше людей во фронте отдают предпочтение композиции вместо наследования.
Что-то я вчера разошёлся, видимо накипело из-за других статей по хукам.
В вашей говорится о конкретном случае использования. Для этого я бы тоже не стал использовать HOC или Render Props. Но в данном кейсе мне больше симпатизирует паттерн Container Component. Всё-таки если захотим использовать тот же компонент, но с другой логикой получения данных, то в вашем случае придётся создавать ещё один компонент, в который прокинем новый хук. В случае контейнера мы просто создаём новый контейнер, а сам компонент не трогаем. А вообще хуки — это конструкция фреймворка. Их можно совмещать со всеми паттернами, будь то HOC, Render Props, Container Component или любой другой из известных и не очень, которые мы используем для разделения зон ответственности и связанности кода.
Но касательно вашего примера — вы написали обычные слоты. Для слотов с ограниченной областью видимости как раз надо передать функцию, т.к. параметры в неё должен передать дочерний компонент. А это уже Render Props.
Это может понадобиться при создании универсальных компонентов, например, автокомплита, когда элемент списка в разных местах может иметь разный шаблон. Т.е. мы говорим, что родитель может передать кусок шаблона в дочерний компонент, но в нём можно использовать только определённый набор параметров (к примеру {id, name, title}).
Но HOC и Render Props больше, чем просто способ для повторного использования кода. Во всех статьях их показывают только с одной стороны, как они ужасны по сравнению с хуками в некоторых кейсах. А потом обязательно сделают вывод, что хуки крутые, а хоки и рендер-пропсы уже прошлый век.
Покажите мне простой пример паттерна декоратор или адаптер на хуках. Покажите мне аналог scoped-slots на хуках. Окажется ли это проще, чем с HOC или Render Props?
Балом правят паттерны (в прочем как и везде).
Захотел разделения бизнес логики и представления — используешь паттерн Container Component. Захотел изменить что-то в одном месте не меняя поведение в других — HOC. Захотел всё смешать в кучу — написал через хуки.
Только везде учат, что паттерны должны быть к месту, а не ради использования паттернов, но в React какой-то хайп идёт по каждому новому паттерну (или функционалу, который именуют очередным убийцей). То HOC самый лучший паттерн, который заменяет почти всё, потом появился убийца HOC'а — Render Props, а теперь уже и хуки, которые опять же сравнивают на полном серьёзе с HOC и Render Props как их замену.
Такое ощущение, что все просто поклоняются тому, о чём пишет Дэн Абрамов. Он написал, что HOC лучший — все это подхватили. Он написал, что HOC ужасен и Render Props теперь лучший — всё форсят Render Props.
Видимо молодость фронтенда даёт о себе знать. Когда-нибудь большая часть паттернов устаканится и их правильное применение осядет в головах, как это происходит в бэкенде. А сейчас идёт поиск серебряной пули.
Хуки очень круты, но почему все сравнивают с HOC? HOC же аналог декоратора для компонента. Он имеет очень классную особенность — позволяет менять поведение в рантайме и не трогать код основного компонента, тем самым не нарушив работу компонента во всём проекте, а может даже и нескольких. Иногда это жизненно необходимо.
Почему нельзя совмещать хуки и хоки? Просто нужно без фанатизма. Это не противостояние за власть, а разные инструменты для разных задач. Я как бы понимаю, что и микроскопом можно гвозди забивать, но лучше забивать гвозди молотком, а с микроскопом делать другое.
HOC — это паттерн. Как и с любым другим паттерном, если использовать его бездумно, то он будет только мешать.
Возьмём к примеру паттерн декоратор (на примере любого классического серверного языка, пусть даже PHP). Его концепция позволяет сделать то же самое — обернуть какой-нибудь объект в 10 обёрток, тем самым вызвать wrapped-hell. Но почему-то им до сих пор пользуются и пользуются успешно. Всё потому, что используют его там, где он принесёт много пользы, а не везде.
Нет идеального паттерна, есть хорошие паттерны для решения конкретных проблем.
В HOC в принципе можно сделать так, но он не требует этого и в нем нет готового механизма для этого.
HOC — это частный случай HOF (Higher Order Function). Вся концепция HOC — это получить один (на самом деле можно и несколько, но это особо не важно) компонент параметром и на основе полученных данных выплюнуть другой компонент. В целом вообще без разницы, что за код там будет внутри. Хотите как-то делить props? Пожалуйста, никто не запрещает. Хотите добавить какие-то сложные условия работы? Пожалуйста, никто не запрещает. Хотите с помощью HOC реализовать паттерн Container Component? Опять же, никто не запрещает.
Я видел этот подход автора статьи. Но у него есть ряд критических недостатков:
1) А если я не использую pug или другой шаблонизатор?
2) Появляется неявная зависимость в коде.
Решение выглядит как большой костыль в попытках расширить непредусмотренную функциональность extend.
Справедливости ради Evan You экспериментировал с хуками уже (естественно, после релиза от реакта). Даже ядро Vue не пришлось трогать :) github.com/yyx990803/vue-hooks
Вообще хуки прикольные, но они не заменят HOC на 100%. У них много общих задач, которые они решают, но есть и различия.
HOC — это лишь паттерн. У каждого паттерна есть своя зона применения. Если он не к месту, то он только ухудшит положение. Миксины и extends всё так же полезны, просто в некоторых моментах они проигрывают HOC, а в некоторых выигрывают.
Для простоты можно и без бэма обойтись. Повторюсь, за позиционирование отвечает родитель. Это написано на сайте методологии. У этого есть основания. Т.е. позиционироваться может только элемент и соответственно его модификаторы, а не модификаторы блока.
Ну как сказать:
Внешняя геометрия и позиционирование
Модификатор не отвечает за позиционирование, а микс может только потому, что мы можем смиксовать элемент. А что такое элемент? Это то, за что отвечает родительский блок, а не текущий.
И что будет, если я захочу использовать .sticker вне .stickers? Всё сломается. Потому что расположение определяет контекст родителя.
Сейчас у вас переиспользование блоков стремится к нулю. А смысл тогда разбивать всё на блоки и элементы? Можно и просто обозвать без всяких БЭМов. Всё так же будет хорошо жить.
Иногда лучше пропустить проверку на null и просто перехватить исключение. Есть то, что мы ожидаем и то, чего мы не ожидаем в нормальной работе приложения. Если мы ожидаем null, например, пользователь не включил чекбокс или это значение по умолчанию, то естественно это не исключение.
А если в длинной цепочке вызовов закралась ошибка и вдруг пришел null вместо ID пользователя, хотя тут явно должен был быть ID? Это как раз исключение. Мы выкидываем исключение и ловим его там, где нам надо обработать его (залогировать, сообщить пользователю об этом, откатить транзакцию и т.п.).
Исключения в нормальной ситуации должны происходить довольно редко по отношению к другим событиям. Из-за этого выигрыш будет минимальным.
Можно и микроскопом забивать гвозди, но зачем?
Примечание: в версиях до 2.3.0 опция props необходима, если вы хотите использовать входные параметры в функциональном компоненте. С версии 2.3.0 и выше вы можете опустить опцию props и все атрибуты, найденные на узле компонента, будут неявно извлечены в качестве входных данных.
Даже хотел подобное сделать своими силами, а потом понял, что они меняют полки местами чаще, чем я еду к ним :(
А так составил список покупок дома, пришёл в гипер, а за тебя уже маршрут построен. Прошелся быстро, всё понакидал в корзину и довольный пошёл домой с 10 пакетами. А если к этому добавить ещё и автоматическую оплату, как у амазона, то вообще улёт.
Когда мне задают вопрос "почему вы не использовали ___?", у меня возникает только одна ассоциация — лошадь в ванне с огурцами.
Потому что я просто не вспомнил о ? Не знал о ? Не знаю почему не использовал ___?
Это не сколько осуждающий вопрос, сколько бесполезный, на который не понятно как отвечать.
В вашей говорится о конкретном случае использования. Для этого я бы тоже не стал использовать HOC или Render Props. Но в данном кейсе мне больше симпатизирует паттерн Container Component. Всё-таки если захотим использовать тот же компонент, но с другой логикой получения данных, то в вашем случае придётся создавать ещё один компонент, в который прокинем новый хук. В случае контейнера мы просто создаём новый контейнер, а сам компонент не трогаем. А вообще хуки — это конструкция фреймворка. Их можно совмещать со всеми паттернами, будь то HOC, Render Props, Container Component или любой другой из известных и не очень, которые мы используем для разделения зон ответственности и связанности кода.
Но касательно вашего примера — вы написали обычные слоты. Для слотов с ограниченной областью видимости как раз надо передать функцию, т.к. параметры в неё должен передать дочерний компонент. А это уже Render Props.
Это может понадобиться при создании универсальных компонентов, например, автокомплита, когда элемент списка в разных местах может иметь разный шаблон. Т.е. мы говорим, что родитель может передать кусок шаблона в дочерний компонент, но в нём можно использовать только определённый набор параметров (к примеру {id, name, title}).
Покажите мне простой пример паттерна декоратор или адаптер на хуках. Покажите мне аналог scoped-slots на хуках. Окажется ли это проще, чем с HOC или Render Props?
Ну и главный вопрос. Какой из этих молотков хуки:
Захотел разделения бизнес логики и представления — используешь паттерн Container Component. Захотел изменить что-то в одном месте не меняя поведение в других — HOC. Захотел всё смешать в кучу — написал через хуки.
Только везде учат, что паттерны должны быть к месту, а не ради использования паттернов, но в React какой-то хайп идёт по каждому новому паттерну (или функционалу, который именуют очередным убийцей). То HOC самый лучший паттерн, который заменяет почти всё, потом появился убийца HOC'а — Render Props, а теперь уже и хуки, которые опять же сравнивают на полном серьёзе с HOC и Render Props как их замену.
Такое ощущение, что все просто поклоняются тому, о чём пишет Дэн Абрамов. Он написал, что HOC лучший — все это подхватили. Он написал, что HOC ужасен и Render Props теперь лучший — всё форсят Render Props.
Видимо молодость фронтенда даёт о себе знать. Когда-нибудь большая часть паттернов устаканится и их правильное применение осядет в головах, как это происходит в бэкенде. А сейчас идёт поиск серебряной пули.
github.com/vuejs/rfcs/blob/dynamic-lifecycle/active-rfcs/0000-dynamic-lifecycle-injection.md
Почему нельзя совмещать хуки и хоки? Просто нужно без фанатизма. Это не противостояние за власть, а разные инструменты для разных задач. Я как бы понимаю, что и микроскопом можно гвозди забивать, но лучше забивать гвозди молотком, а с микроскопом делать другое.
Возьмём к примеру паттерн декоратор (на примере любого классического серверного языка, пусть даже PHP). Его концепция позволяет сделать то же самое — обернуть какой-нибудь объект в 10 обёрток, тем самым вызвать wrapped-hell. Но почему-то им до сих пор пользуются и пользуются успешно. Всё потому, что используют его там, где он принесёт много пользы, а не везде.
Нет идеального паттерна, есть хорошие паттерны для решения конкретных проблем.
HOC — это частный случай HOF (Higher Order Function). Вся концепция HOC — это получить один (на самом деле можно и несколько, но это особо не важно) компонент параметром и на основе полученных данных выплюнуть другой компонент. В целом вообще без разницы, что за код там будет внутри. Хотите как-то делить props? Пожалуйста, никто не запрещает. Хотите добавить какие-то сложные условия работы? Пожалуйста, никто не запрещает. Хотите с помощью HOC реализовать паттерн Container Component? Опять же, никто не запрещает.
1) А если я не использую pug или другой шаблонизатор?
2) Появляется неявная зависимость в коде.
Решение выглядит как большой костыль в попытках расширить непредусмотренную функциональность extend.
github.com/yyx990803/vue-hooks
Вообще хуки прикольные, но они не заменят HOC на 100%. У них много общих задач, которые они решают, но есть и различия.
HOC — это лишь паттерн. У каждого паттерна есть своя зона применения. Если он не к месту, то он только ухудшит положение. Миксины и extends всё так же полезны, просто в некоторых моментах они проигрывают HOC, а в некоторых выигрывают.