Эти три соединяются в обычном variants. Если можно в прозрачность, то ставится основной цвет text-success-700, а фон задается bg-current/5 сразу для всех вариантов. Вот с variant=solid такой фокус не срабатывает и там уже compoundVariants и длинное "text-success-50 bg-success-700". Все равно куча кнопок, но скорее из-за логики. Например, кнопки download/upload выделены в отдельные с наследованием ts-пропсов. А если какая-то редкая замысловатая кнопка, то проще стилизовать на месте, а не мудрить в универсальность. У всех компонент какой-то жизненный цикл. А "одна кнопка для всего" - зло.
Норм там с иконкой внутри и без. Четвертый tailwind умеет в хитрые штуки типа селекторов потомков. И умеет в data-атрибуты. Уверен, вы видели это в shadcn - я оттудова копипастю и адаптирую под себя. Так кусочек, когда нужно для xs только иконку, а текст в span прятать и оставлять только img/svg-иконку: adaptive: { true: "[&>span]:hidden sm:[&>span]:inline", false: ""} Еще в cva есть compoundVariants, когда просто variants не хватает. Здесь размер кнопки + текст/нет: compoundVariants: [ // отступы, если есть span-текст { adaptive: false, size: "md", class: "has-[>span]:px-3" }, { adaptive: false, size: "lg", class: "has-[>span]:px-4" }, { adaptive: true, size: "md", class: "sm:has-[>span]:px-3" }, { adaptive: true, size: "lg", class: "sm:has-[>span]:px-4" },
Да, все в css переводится. Но работает, и это уже хорошо
Не понял сабжа. Если делаешь универсальное решение, то по дефолту оно и является проблемой. Просто управляем сложностью, и рядом с XButton может быть XButton2 - норм. Про cva вы умолчали, что наряду с VariantProps-параметрами остается доступный className, куда можно добавить своё накопившееся.
Я тоже "нимношка" пишу свой коммуникатор. И пишу давно, потому что с нуля - хочу реанимировать древние форумы, скрещиваю их с мессенджерами и ролевыми доступами. Я одиночка, потому хз где кончается творчество и начитается бизнес-цель. Знаю, что в московской оффлайн-тусовке кто-то уже пилит НОВЫЙ мессенджер командой (не макс), но название я запамятовал. И уверен, что тут как с облаками - через полгода будет дофига мессенджеров. Потому что ит - это инфраструктура, и общаться через нее можно и нужно. Вопросы по задумке - Цель в чем? Если просто "осчастливить народ", то тухляк. Потому что сервера не бесплатные, поддерживать-развивать, а народ за сообщения платить не будет. Если окупаться, то кто платит?! И за что и сколько? Если есть бизнес-цель, то как набрать критическую массу. Я вот интроверт, и мне физически тяжело поддерживать кучу контактов. Еще в древние доковидные времена говорилось, что самоокупаемость соцсетей начинается с 50к пользователей.
На восьмой vite уже перешел. И заодно разделять бандл научился - проект небольшой и maplibre+terradraw увеличил бандл с 1МБ до 2МБ. Полет нормальный. А как это совсем без useEffect?! У меня много чего через useSWR, но что-то приходится через useEffect делать. И вот в в прошлом-этом месяце много эффектов было. И страдал от захватов и всякого. Разрулил, и с облегчением мечтаю, чтобы нескоро снова лезть в эффекты.
Мир разделяется. Технологии приравнены к оружию. И повесточка дня не "дружба дружбой, а табачок врозь", но "разделять и властвуй". В целом пиплу приходится думать, что радует. Ну и потерпеть придется, не без этого.
Зачем request в logError(r *http.Request, error), где он не используется. Наверно в поначалу поднимали логгер из контекста. И в http-ответе он не нужен, нужен только w.
Не надо, чтобы `message interface{}` (причем давно - any). Стоит сделать string, и приводить к строке на на месте или реализовывать интерфейс через String().
Не очень понял логику. serverErrorResponse пишет в лог и в http, а два других метода только в http. Типа это не ошибка бизнеса и не надо логгировать?! - для меня необычно, ну да ладно.
В принципе примерно также писал, но потом понял, что http-хелпер не пересекается с бизнес-логикой и стал писать вида `if d.CatchErr(op, err) { return }`, где d - обертка поверх (w, r).
Вау, оказалось, что я комментил вашу предыдущую статью.
Поражен вашей внимательностью ;) Писал залпом, и это был кусок кода из головы. Не проверял, потому что в этом месте по сценарию должен быть uuid. И мне трудно представить, что я его где-то чистым текстом вписал. Для такого зарезервированные значения в models.
Тут бы разбить общение на деловое и нет. Я тут ниже написал, что делаю "деловое общение" (или "что") - там важны статусы, деловая этика и рациональные мысли. И есть неделовое "как" - важны как раз эмоции, которые точно не рациональны. Потому это просто разное общение в разных системах. И проблемы, только если мешать одно с другим.
Я тоже что-то такое делаю. Но не особо похожее на описанное. Делаю сообщества (соседи в недвижке как цель, но не обязательно). В сообществах есть чаты и есть "документы" типа древних форумов, но со специализацией. Ролевая система. И внутри можно скинуться деньгами (учет с остатками). И фильтр на входе. Акцент на реестре участников с долей в управлении. И тогда есть многообразие плюшек. И "замедление" в документах, чтобы не в пару экранов как в чате. И перспективный модуль "партнерств" - сообщества могут иметь вертикальные связи (структура) и горизонтальные (партнерство). И добавляются испорт/экспорт ролей представителей. И тут же может двигаться информация - вверх/вниз и вправо/влево. Но пока модуль структур слабо развит. А вот очень надо потестировать основной модуль на людях. Если у вас есть сообщество с общим имуществом (управление чем-то) и денежными отношениями, то вэлкам сюда: https://pro.deloset.ru
Привет, Петр! я про него тебе точно рассказывал - монолитик на go + react pwa (deloset.ru, а лендинг туда переедет с pro.deloset.ru). По теме статьи - мотив был очень сильный к написанию. К идее уже было видение "как надо" + опыт в недвижке и управлении - нельзя было не написать. И это захватывающе, но "очень тяжело продавать" для интроверта. Делаю отдельные вылазки, общаюсь, потом отдыхаю ;)
Сделал свой продукт, теперь учусь продавать, что чревато просадкой по техническим скиллам. Но не первый день замужем! и своё же продавать, так что держусь. Но если можете не делать своего, то не делайте!
Не очень вчитывался, но у меня вроде посложнее: - на внешний сигнал стопа закрываем прием новых запросов (у меня http-сервер), доделываем имеющиеся запросы, сервер по завершении обработки завершается и кидает ок в канал - по сигналу закрываются соединения с ресурсами, чтобы не потерять данные, - и потом выход из main (или жесткий шатдаун по истечении второго времени). И потому есть контекст на управление сервером, есть контекст запросов внутри сервера, и есть контекст на приложуху с ресурсами - данные в одну сторону. И каналы для ответов. Потому долго ковырялся.
Всё не настолько плохо, чтобы тащить новую зависимость. Мне не зашел "uber/fx". И за несколько дней разобрался в теме - задача красиво остановить сильно сложнее, чем запустить. Пучок каналов, несколько контекстов, waitgroups для внешних сервисов - и готово. Решение на пару сотен строк, разбросанных по модулям. Я за отсутствие магии в разработке, если что.
Добрых лучиков! Это кусок текста из "примерно в начале", где я набрасываю, что это не мой выбор. И там речь больше про чтение логов в chrome-for-devs. И в принципе работает - там текст же. Но ГОРАЗДО УДОБНЕЕ писать больше букв. В первую очередь, есть правило наименования переменных - чем дальше от места использования тем длиннее. И здесь по сути название очень далекой функции. Потому не надо сокращать. Про идентификаторы в путях типа "users/:id" подробно в разделе "о входящих данных". Если кроме одного идентификатора ничего не нужно - то ок. На этом REST API держится. Но если пересылать больше данных, которые уже в query/body И ДОПОЛНИТЕЛЬНО парсить путь - да зачем?! А если не пихать в путь, то сильно просто парсить входящие данные по ОДНОЙ модели с валидатором.
Вертушка - наоборот раскидывала входящие звонки на дежурных в разных офисах. А поднимать старые звонки через CRM было больнее, да. Я какое-то время назад вернулся в разрабы со своей идеей из недвижки. Долго пилил, теперь учусь продавать проект. Рекламу бросил давать еще до пандемии, но иногда делаю сделки - вот недавно меня нашла заказчица через 8 лет. С видео и аи в продажах недвиги не вижу перспектив - эффект мал, а трудоемкость высокая. А продвижение услуг - это НОВЫЕ контакты, то есть надо собрать клиентов (а не пользователей как в циан) в одном месте и свести с риелторами, которых надо фильтровать (не как в циан). Причем собрать на фоне перегретого информационного шума. Если так, то фантастика! Здесь просто общаемся, мне было приятно вспомнить что-то старое.
Стоит сначала определить, кто такой риелтор (у каждого риелтора своё определение профессии). Я склонен называть риелтора "доверенным специалистом". И сказал бы не о контент-голоде (обычно всякие страшилки) - а об отсутствии реальных контактов. Раньше с телефонной вертушки нормально клиентов набирали, и это то качество, которое не дает никакой контент (особенно сгенерированный) - клиент выбирает "своего" риелтора во многом по речи - громкость, чистота речи, понятность, и даже скорость и тембр. И приходит на личную встречу уже теплый. "Ведущие соцсети" - это имиджевая реклама, такое себе мало кто может позволить. И не всем надо - какие-то клиенты предпочитают тишину и кулуарность. З.Ы. РиЭлтор - это конкретно член Российской Гильдии Риэлторов. Грамотно писать "риелтор", но РГР зарегистрировало товарный знак "риэлтор". А называть себя таким словом может только тот, кто платит членские взносы. Риелтор - это устоявшееся название, которым любой себя может назвать.
Видео вообще в недвижке не нужно, от нейронки тем более. В первичке и так полно обмана, где соседнюю промзону или пустырь изображают на схеме взрослым лесом. Во вторичке база для ручной фильтрации (ну вы и так поняли после 100 собесов) - минимум времени на объявление по типовому шаблону. И смотреть видео будет никто. Есть общий тренд на то, что выбирают по фотографиям (витрина), а при визите уже подтверждают свое решение. Видео сработает для нестандартных объектов, которые невозможно сравнить с соседями - и уже другая оценка объекта. В целом рад, что вы опрашивали именно риелторов - обычно их почему-то игнорируют, когда что-то в недвижке хотят поменять.
Думаю, что зависит от назначения приложения. У меня сервер обслуживает сайт. И умеет всё с данными - это бизнес. А из сервисов там cron, рассылка и sse...
Эти три соединяются в обычном variants. Если можно в прозрачность, то ставится основной цвет text-success-700, а фон задается bg-current/5 сразу для всех вариантов. Вот с variant=solid такой фокус не срабатывает и там уже compoundVariants и длинное "text-success-50 bg-success-700".
Все равно куча кнопок, но скорее из-за логики. Например, кнопки download/upload выделены в отдельные с наследованием ts-пропсов.
А если какая-то редкая замысловатая кнопка, то проще стилизовать на месте, а не мудрить в универсальность. У всех компонент какой-то жизненный цикл. А "одна кнопка для всего" - зло.
Норм там с иконкой внутри и без. Четвертый tailwind умеет в хитрые штуки типа селекторов потомков. И умеет в data-атрибуты. Уверен, вы видели это в shadcn - я оттудова копипастю и адаптирую под себя.
Так кусочек, когда нужно для xs только иконку, а текст в span прятать и оставлять только img/svg-иконку:
adaptive: { true: "[&>span]:hidden sm:[&>span]:inline", false: ""}Еще в cva есть compoundVariants, когда просто variants не хватает. Здесь размер кнопки + текст/нет:
compoundVariants: [// отступы, если есть span-текст{ adaptive: false, size: "md", class: "has-[>span]:px-3" },{ adaptive: false, size: "lg", class: "has-[>span]:px-4" },{ adaptive: true, size: "md", class: "sm:has-[>span]:px-3" },{ adaptive: true, size: "lg", class: "sm:has-[>span]:px-4" },Да, все в css переводится. Но работает, и это уже хорошо
Не понял сабжа. Если делаешь универсальное решение, то по дефолту оно и является проблемой. Просто управляем сложностью, и рядом с XButton может быть XButton2 - норм.
Про cva вы умолчали, что наряду с VariantProps-параметрами остается доступный className, куда можно добавить своё накопившееся.
Я тоже "нимношка" пишу свой коммуникатор. И пишу давно, потому что с нуля - хочу реанимировать древние форумы, скрещиваю их с мессенджерами и ролевыми доступами. Я одиночка, потому хз где кончается творчество и начитается бизнес-цель. Знаю, что в московской оффлайн-тусовке кто-то уже пилит НОВЫЙ мессенджер командой (не макс), но название я запамятовал. И уверен, что тут как с облаками - через полгода будет дофига мессенджеров. Потому что ит - это инфраструктура, и общаться через нее можно и нужно.
Вопросы по задумке - Цель в чем? Если просто "осчастливить народ", то тухляк. Потому что сервера не бесплатные, поддерживать-развивать, а народ за сообщения платить не будет. Если окупаться, то кто платит?! И за что и сколько?
Если есть бизнес-цель, то как набрать критическую массу. Я вот интроверт, и мне физически тяжело поддерживать кучу контактов. Еще в древние доковидные времена говорилось, что самоокупаемость соцсетей начинается с 50к пользователей.
На восьмой vite уже перешел. И заодно разделять бандл научился - проект небольшой и maplibre+terradraw увеличил бандл с 1МБ до 2МБ. Полет нормальный.
А как это совсем без useEffect?! У меня много чего через useSWR, но что-то приходится через useEffect делать. И вот в в прошлом-этом месяце много эффектов было. И страдал от захватов и всякого. Разрулил, и с облегчением мечтаю, чтобы нескоро снова лезть в эффекты.
Мир разделяется. Технологии приравнены к оружию. И повесточка дня не "дружба дружбой, а табачок врозь", но "разделять и властвуй". В целом пиплу приходится думать, что радует. Ну и потерпеть придется, не без этого.
Зачем request в
logError(r *http.Request, error), где он не используется. Наверно в поначалу поднимали логгер из контекста. И в http-ответе он не нужен, нужен только w.Не надо, чтобы `message interface{}` (причем давно - any). Стоит сделать string, и приводить к строке на на месте или реализовывать интерфейс через String().
Не очень понял логику.
serverErrorResponseпишет в лог и в http, а два других метода только в http. Типа это не ошибка бизнеса и не надо логгировать?! - для меня необычно, ну да ладно.В принципе примерно также писал, но потом понял, что http-хелпер не пересекается с бизнес-логикой и стал писать вида `if d.CatchErr(op, err) { return }`, где d - обертка поверх (w, r).
Вау, оказалось, что я комментил вашу предыдущую статью.
Пользуйтесь на здоровье!
Поражен вашей внимательностью ;) Писал залпом, и это был кусок кода из головы. Не проверял, потому что в этом месте по сценарию должен быть uuid. И мне трудно представить, что я его где-то чистым текстом вписал. Для такого зарезервированные значения в models.
Тут бы разбить общение на деловое и нет. Я тут ниже написал, что делаю "деловое общение" (или "что") - там важны статусы, деловая этика и рациональные мысли.
И есть неделовое "как" - важны как раз эмоции, которые точно не рациональны. Потому это просто разное общение в разных системах. И проблемы, только если мешать одно с другим.
Я тоже что-то такое делаю. Но не особо похожее на описанное. Делаю сообщества (соседи в недвижке как цель, но не обязательно). В сообществах есть чаты и есть "документы" типа древних форумов, но со специализацией. Ролевая система. И внутри можно скинуться деньгами (учет с остатками). И фильтр на входе.
Акцент на реестре участников с долей в управлении. И тогда есть многообразие плюшек. И "замедление" в документах, чтобы не в пару экранов как в чате.
И перспективный модуль "партнерств" - сообщества могут иметь вертикальные связи (структура) и горизонтальные (партнерство). И добавляются испорт/экспорт ролей представителей. И тут же может двигаться информация - вверх/вниз и вправо/влево.
Но пока модуль структур слабо развит. А вот очень надо потестировать основной модуль на людях. Если у вас есть сообщество с общим имуществом (управление чем-то) и денежными отношениями, то вэлкам сюда: https://pro.deloset.ru
Привет, Петр! я про него тебе точно рассказывал - монолитик на go + react pwa (deloset.ru, а лендинг туда переедет с pro.deloset.ru). По теме статьи - мотив был очень сильный к написанию. К идее уже было видение "как надо" + опыт в недвижке и управлении - нельзя было не написать. И это захватывающе, но "очень тяжело продавать" для интроверта. Делаю отдельные вылазки, общаюсь, потом отдыхаю ;)
Сделал свой продукт, теперь учусь продавать, что чревато просадкой по техническим скиллам. Но не первый день замужем! и своё же продавать, так что держусь. Но если можете не делать своего, то не делайте!
Не очень вчитывался, но у меня вроде посложнее:
- на внешний сигнал стопа закрываем прием новых запросов (у меня http-сервер), доделываем имеющиеся запросы, сервер по завершении обработки завершается и кидает ок в канал
- по сигналу закрываются соединения с ресурсами, чтобы не потерять данные,
- и потом выход из main (или жесткий шатдаун по истечении второго времени).
И потому есть контекст на управление сервером, есть контекст запросов внутри сервера, и есть контекст на приложуху с ресурсами - данные в одну сторону. И каналы для ответов. Потому долго ковырялся.
Всё не настолько плохо, чтобы тащить новую зависимость. Мне не зашел "uber/fx". И за несколько дней разобрался в теме - задача красиво остановить сильно сложнее, чем запустить. Пучок каналов, несколько контекстов, waitgroups для внешних сервисов - и готово. Решение на пару сотен строк, разбросанных по модулям.
Я за отсутствие магии в разработке, если что.
Добрых лучиков! Это кусок текста из "примерно в начале", где я набрасываю, что это не мой выбор. И там речь больше про чтение логов в chrome-for-devs. И в принципе работает - там текст же. Но ГОРАЗДО УДОБНЕЕ писать больше букв. В первую очередь, есть правило наименования переменных - чем дальше от места использования тем длиннее. И здесь по сути название очень далекой функции. Потому не надо сокращать.
Про идентификаторы в путях типа "users/:id" подробно в разделе "о входящих данных". Если кроме одного идентификатора ничего не нужно - то ок. На этом REST API держится. Но если пересылать больше данных, которые уже в query/body И ДОПОЛНИТЕЛЬНО парсить путь - да зачем?! А если не пихать в путь, то сильно просто парсить входящие данные по ОДНОЙ модели с валидатором.
Вертушка - наоборот раскидывала входящие звонки на дежурных в разных офисах. А поднимать старые звонки через CRM было больнее, да.
Я какое-то время назад вернулся в разрабы со своей идеей из недвижки. Долго пилил, теперь учусь продавать проект. Рекламу бросил давать еще до пандемии, но иногда делаю сделки - вот недавно меня нашла заказчица через 8 лет.
С видео и аи в продажах недвиги не вижу перспектив - эффект мал, а трудоемкость высокая. А продвижение услуг - это НОВЫЕ контакты, то есть надо собрать клиентов (а не пользователей как в циан) в одном месте и свести с риелторами, которых надо фильтровать (не как в циан). Причем собрать на фоне перегретого информационного шума. Если так, то фантастика!
Здесь просто общаемся, мне было приятно вспомнить что-то старое.
Стоит сначала определить, кто такой риелтор (у каждого риелтора своё определение профессии). Я склонен называть риелтора "доверенным специалистом". И сказал бы не о контент-голоде (обычно всякие страшилки) - а об отсутствии реальных контактов. Раньше с телефонной вертушки нормально клиентов набирали, и это то качество, которое не дает никакой контент (особенно сгенерированный) - клиент выбирает "своего" риелтора во многом по речи - громкость, чистота речи, понятность, и даже скорость и тембр. И приходит на личную встречу уже теплый.
"Ведущие соцсети" - это имиджевая реклама, такое себе мало кто может позволить. И не всем надо - какие-то клиенты предпочитают тишину и кулуарность.
З.Ы. РиЭлтор - это конкретно член Российской Гильдии Риэлторов. Грамотно писать "риелтор", но РГР зарегистрировало товарный знак "риэлтор". А называть себя таким словом может только тот, кто платит членские взносы. Риелтор - это устоявшееся название, которым любой себя может назвать.
Видео вообще в недвижке не нужно, от нейронки тем более. В первичке и так полно обмана, где соседнюю промзону или пустырь изображают на схеме взрослым лесом.
Во вторичке база для ручной фильтрации (ну вы и так поняли после 100 собесов) - минимум времени на объявление по типовому шаблону. И смотреть видео будет никто. Есть общий тренд на то, что выбирают по фотографиям (витрина), а при визите уже подтверждают свое решение. Видео сработает для нестандартных объектов, которые невозможно сравнить с соседями - и уже другая оценка объекта.
В целом рад, что вы опрашивали именно риелторов - обычно их почему-то игнорируют, когда что-то в недвижке хотят поменять.
Думаю, что зависит от назначения приложения. У меня сервер обслуживает сайт. И умеет всё с данными - это бизнес. А из сервисов там cron, рассылка и sse...