Согласен, зависимость одностороння от компонента на композабл. Так что сцепленности нет. Разве что апи композабла чуть усложняется из-за эмитов, но это мелочи и, возможно, субъективное усложнение.
Так что если даже документация не запрещает эмитить из композаблов, то вполне рабочий подход. Спасибо буду держать на вооружении.
Я, кстати, не знал, что официальная документация не рекомендует эмитить из композаблов. Спасибо, автору, что поднял эту тему. Но, честно говоря, если бы мне пришлось решать подобную описанной в статье задачу, я бы врятли использовал такой паттерн. Апи композабла усложняется. Теперь, чтобы понять, что он делает, нужно в него провалиться, т.е. это теперь не просто набор входных параметров и выходных значений или методов, которые афектят только внутреннее состояние композабла. В сложных случаях, я наверно предпочел бы иметь больше бойлерплейта для уменьшения сцепленности компонента и композабла.
По-моему, большая часть пользы tailwind идет из того, что утилитарные классики можно навешивать на сам элемент (структура html прямо перед глазами, легко понять к какому блоку что применить). Заменяем утилитарные классы на семантические, выносим использование tailwind через apply в блок css деклараций и теряем преимущество тэйлвинда, что классики вешаем прямо на html. Насчет размера бандла, кстати, не уверен. Бандл ведь не сжимается, как сжался бы при навешивании утилитных классиков прямо на html? В блоке css деклараций появляется лишняя абстракция, не надежней ли использовать стандартный css, если уж мы пишем свои классы.
Хотя, забыл еще одно преимущество тэилвинда - готовая тема. Т.е. можно делать более менее гармоничные сайты без привлечения дизайнера.
А вариант с привязкой отдельной банковской карты специально для подписок, которая регулярно пополняется живым владельцем ровно на сумму стоимости подписок, не рассматривается? Вроде подписки в долг не работают. Соответственно, как только денег на карте не станет - подписки сами отключатся. А основные средства хранятся на отдельном счету без всяких авто платежей и тому подобного.
В чем виноват mobile first? Он не подразумевает "сделаем десктоп, если денег/времени хватит". Он подразумевает: "сделаем и то и другое". А если его реализуют наполовину, то причина либо в том, что бизнесу эта половина реально не нужна либо просто не умеют. И я сомневаюсь, что гугл таблицы были сделаны mobile first. Выглядит как раз наоборот.
Согласен, зависимость одностороння от компонента на композабл. Так что сцепленности нет. Разве что апи композабла чуть усложняется из-за эмитов, но это мелочи и, возможно, субъективное усложнение.
Так что если даже документация не запрещает эмитить из композаблов, то вполне рабочий подход. Спасибо буду держать на вооружении.
Я, кстати, не знал, что официальная документация не рекомендует эмитить из композаблов. Спасибо, автору, что поднял эту тему. Но, честно говоря, если бы мне пришлось решать подобную описанной в статье задачу, я бы врятли использовал такой паттерн. Апи композабла усложняется. Теперь, чтобы понять, что он делает, нужно в него провалиться, т.е. это теперь не просто набор входных параметров и выходных значений или методов, которые афектят только внутреннее состояние композабла. В сложных случаях, я наверно предпочел бы иметь больше бойлерплейта для уменьшения сцепленности компонента и композабла.
По-моему, большая часть пользы tailwind идет из того, что утилитарные классики можно навешивать на сам элемент (структура html прямо перед глазами, легко понять к какому блоку что применить). Заменяем утилитарные классы на семантические, выносим использование tailwind через apply в блок css деклараций и теряем преимущество тэйлвинда, что классики вешаем прямо на html. Насчет размера бандла, кстати, не уверен. Бандл ведь не сжимается, как сжался бы при навешивании утилитных классиков прямо на html? В блоке css деклараций появляется лишняя абстракция, не надежней ли использовать стандартный css, если уж мы пишем свои классы.
Хотя, забыл еще одно преимущество тэилвинда - готовая тема. Т.е. можно делать более менее гармоничные сайты без привлечения дизайнера.
А почему дизайнеры фиксят проблему инженеров экранов телевизоров? :)
А вариант с привязкой отдельной банковской карты специально для подписок, которая регулярно пополняется живым владельцем ровно на сумму стоимости подписок, не рассматривается? Вроде подписки в долг не работают. Соответственно, как только денег на карте не станет - подписки сами отключатся. А основные средства хранятся на отдельном счету без всяких авто платежей и тому подобного.
В чем виноват mobile first? Он не подразумевает "сделаем десктоп, если денег/времени хватит". Он подразумевает: "сделаем и то и другое". А если его реализуют наполовину, то причина либо в том, что бизнесу эта половина реально не нужна либо просто не умеют. И я сомневаюсь, что гугл таблицы были сделаны mobile first. Выглядит как раз наоборот.
Сколько же крутизны тут! спасибо за подборку! Пойду пробовать)