Дураки/умные - это же надо так умудряться интерпретировать. Я текст на абзацы не просто так разбиваю - там цельная мысль в нескольких предложениях, нет смысла выхватывать предложения из контекста.
Третий пример - есть специфичная кнопка src/components/ButtonGetUser
Вот хороший пример. Основной момент как раз - где проходит та граница, когда группировка родительской папкой теряет смысл. Когда рядом лежит Button и ButtonGetUser - для меня это прям сваливание в кучу компонентом с разными ответственностями и контекстами. Вам - ок? Ну хозяин - барин. Просто многим такое не ок.
Про декорирование не понял, я вроде о нем ничего не говорил)
Это в переносном смысле - не про декораторы. В папке components плоская структура подпапок? Никакой группировки нет? Button и ButtonGetUser лежат рядом? Если плоская, то где та грань, когда надо начинать группировать? Если группируется, то по какому принципу? Если как-то семантически и подпапок немного, то смысл в этой декоративной "components"?..
В целом понятно, что серебряной пули нет. Структура сильно зависит от проекта и задач. Кому-то достаточно и доменов в pages. А кто-то видит необходимость и поглубже в DDD погрузиться. Фронтовые приложения растут в масштабах и лучшие практики проектирования тоже постепенно заходят во фронт.
Ничего не писал про идеальность :) Так что кто и что выдумывает - вопрос открытый.
Отдельный реп - это локально просто папка. Не запускайте всё, запускайте только то, что нужно - в чём проблема? Водораздел проходит не там, а в отдельных релиз-циклах и изолированности команд. Если сильно надо, то почему нет. Но это немного про другое.
Что-то обсуждение начинает сводиться к "А вы бросили пить коньяк по утрам? Да или нет?", но попробую последний раз :)
Ключевое в борьбе со свалками - это структура и нейминг. Если нарезали так, что можно выделить в отдельные микрофронты и есть несвалочный шаренный код, то выделение в отдельный реп с точки зрения борьбы со свалками особого профита не несет.
Микрофронты = 1 микрофронт - отдельный репозиторий
Это очень узкий взгляд на микрофронты. Только если нужен отдельный релиз-цикл, да и в этом случае совсем необязательно. В остальных случаях, прекрасно и даже проще живет в монорепе с workspace-ами.
Что за палочка-выручалочка "микрофронты"? Как она избавляет от свалок в директориях "components", "services", "hooks", "helpers", "utils"?
Для меня микрофронты - это в первую очередь про модульность, структуру и нейминг. Ровно то, о чём сейчас речь и идет. В монорепе с микрофронтами же поди на верхнем смысловом уровне "components", "services", "hooks", "helpers", "utils" не будет? Будет смысловая разбивка на микрофронты + какие-то нарезки шаренного кода? Кто же мешает так и делать сразу. Кто-то так и 10 лет назад делал, когда никаких "микрофронтов" ещё и не было.
Это, похоже, вечный спор, который был ещё 10 лет назад. Нейминг и группировка на основе типов сущностей (components, services, hooks) и семантики. Первое просто и универсально, но с определенного момента начинает превращаться в свалку. Второе сложно, думать надо по-больше и единого универсального подхода нет, в одной статье описать сложно. И с первым и со вторым можно жить.
Есть ощущение, что с какого-то момента роста проекта первое начинает внутри прятать второе.
Как по мне, "components", "services", "hooks", "helpers", "utils" - это потенциальные свалки, особенно на верхнем уровне структуры каталогов. Нейминг слишком общий, слишком мало в нем семантики. И лучше бы подумать над более контекстными смысловыми названиями, как минимум, для каталогов верхнего уровня.
Они могут использовать глобальные вызовы api и читать данные из глобальных сторов globalStores
Button тоже может? Выглядит так, что в components у вас будут намешаны компоненты с разной семантикой. Ну или не будут, но тогда, скорее всего, в вроде как "простой" классической внутри спрячется семантическая посложнее. Толку тогда от это вроде как "простого" декорирования?..
Пытался недавно решать задачу слежения за каналами, фильтрации нужных сообщений и пересылки их в отдельный канал. Информации в Телеграме сейчас много, и не хочется загружать мозг отфильтровыванием абсолютно ненужной информации. Так вот либо я не доразобрался, либо решения в данном случае достаточно костыльные. Нашлось некоторое количество ботов, которые вроде как умеют такое делать, но они фактически открывают сессию под твоим аккаунтом (ты им сообщаешь телефон, тебе приходит код, ты передаешь его боту), что уже не очень хорошо. Но к тому же нормально работающего так и не нашел, глючат, иногда стоят каких-то неразумных денег за такую простую задачу. И подумал, что может проще платить за свой минимальный сервер и написать самому нужный функционал. В результате получился мини-клиент на базе Telethon (похоже это и есть юзербот, не знал до данного момента про такую классификацию). Код достаточно тривиален, правда получилась проблемка, что когда под своим аккаунтом сообщение пересылаешь, в канале-получателе то не будет уведомления о непрочитанном сообщении, а нормального функционала «сделать сообщение непрочитанным» найти не получилось, пришлось делать промежуточного простого бота, единственная функция которого — принять сообщение и переслать в конечный канал. Но решение выгляди костыльно. Это я недоразобрался или всё так и есть?
А с нашими лентами arlight никому не приходилось сталкиваться? Вроде стоит сходных денег (170-270 р/м). Насколько параметры у них правдоподобны и стабильны?
У вас какие-то очень слабые тексты на сайте, если бы Вы не дали название, то по описанию на сайте сложно понять, что это именно то средство. Да и вообще, когда читаешь рядом описание на сайте и этот абзац из статьи:
Скорость действия следующая: солнечные ожоги по плечам ярко-красного и буроватого оттенка (второй степени) убирает за 6 часов почти полностью (болевых ощущений нет, визуально не различимы, кожа не отходит). Насекомые вроде комаров — намазать место укуса и забыть, что он был. Осы покусали — три нанесения маской, 4 часа до стабилизации, 10-12 часов до ухода основных симптомов. Царапины без доступа к крови — без числа, быстро. Используется для младенческих опрелостей и всяких натёртостей, есть практика. Мы очень гордимся, что смогли добиться такого. Надеемся, его возьмут при следующей ревизии аптечки на МКС из-за действенности.
то возникает легкое недоумение и недоверие, либо в статье сильно приукрасили, либо на сайте ну уж совсем свои заслуги преуменьшили.
По функционалу чтения: мне кажется, опционально было бы полезно еще транскрипцию выводить, чтобы не получилось, что начал про себя произносить неправильно и это произношение так и закрепилось.
Вы этот дополнительный архитектурный тип сущностей "граница" и "близость/соприкосновение с границей" вводите, потому что не получается Application layer разбить на 2 слоя и руководствоваться только правилами: через слой не перепрыгивать (непересечение слоя) и нижний ничего не знает про верхний?
Что значит "скрыто"? Просто в другом слое, причем всего лишь на один уровень ниже. Почему Model может туда обращаться, а находящиеся там же (где и Model) View и Controller — нет?
Вы сами ввели в разговор правило непересечения слоев. Вот следуя ему, View и Controller могут обратиться к Domain Model. Если же Вы запретите пересекать границу (какое-то другое правило), то к Domain Model не сможет обратиться Application Model.
Итого: разложив все в три слоя и пользуясь правилом непересечения слоев — картина получается непротиворечивая. Ваше последнее описание мне пока кажется противоречивым. Возможно, Вы используете какой-то другой способ изоляции, но в явном виде пока его не описали, причем еще раз обращу Ваше внимание, что изоляцию через правило непересечения слоев Вы ввели в обсуждение сами.
А на границу вы его, судя по всему, поместили, чтобы для варианта в 5-1 проиллюстрировать, что вот в отдельном слое лежит Domain Model, а Application Model в другом и вроде как вместе с Controller и View, но при этом же надо как-то обозначить, что View и Controller не должны лезть к Domain Model.
Вот если руководствоваться правилом непересечения слоев, то надо было просто в три слоя их разложить, а не в два. Но чтобы остаться в рамках картинки, где слоя всего два нарисовано приходится придумывать вот это про границу.
Или что вы под этим размещением на границе подразумевали?
Дураки/умные - это же надо так умудряться интерпретировать. Я текст на абзацы не просто так разбиваю - там цельная мысль в нескольких предложениях, нет смысла выхватывать предложения из контекста.
Вот хороший пример. Основной момент как раз - где проходит та граница, когда группировка родительской папкой теряет смысл. Когда рядом лежит Button и ButtonGetUser - для меня это прям сваливание в кучу компонентом с разными ответственностями и контекстами. Вам - ок? Ну хозяин - барин. Просто многим такое не ок.
Это в переносном смысле - не про декораторы. В папке components плоская структура подпапок? Никакой группировки нет? Button и ButtonGetUser лежат рядом? Если плоская, то где та грань, когда надо начинать группировать? Если группируется, то по какому принципу? Если как-то семантически и подпапок немного, то смысл в этой декоративной "components"?..
В целом понятно, что серебряной пули нет. Структура сильно зависит от проекта и задач. Кому-то достаточно и доменов в pages. А кто-то видит необходимость и поглубже в DDD погрузиться. Фронтовые приложения растут в масштабах и лучшие практики проектирования тоже постепенно заходят во фронт.
Ничего не писал про идеальность :) Так что кто и что выдумывает - вопрос открытый.
Отдельный реп - это локально просто папка. Не запускайте всё, запускайте только то, что нужно - в чём проблема?
Водораздел проходит не там, а в отдельных релиз-циклах и изолированности команд. Если сильно надо, то почему нет. Но это немного про другое.
Что-то обсуждение начинает сводиться к "А вы бросили пить коньяк по утрам? Да или нет?", но попробую последний раз :)
Ключевое в борьбе со свалками - это структура и нейминг. Если нарезали так, что можно выделить в отдельные микрофронты и есть несвалочный шаренный код, то выделение в отдельный реп с точки зрения борьбы со свалками особого профита не несет.
Это очень узкий взгляд на микрофронты. Только если нужен отдельный релиз-цикл, да и в этом случае совсем необязательно. В остальных случаях, прекрасно и даже проще живет в монорепе с workspace-ами.
Что за палочка-выручалочка "микрофронты"? Как она избавляет от свалок в директориях "components", "services", "hooks", "helpers", "utils"?
Для меня микрофронты - это в первую очередь про модульность, структуру и нейминг. Ровно то, о чём сейчас речь и идет. В монорепе с микрофронтами же поди на верхнем смысловом уровне "components", "services", "hooks", "helpers", "utils" не будет? Будет смысловая разбивка на микрофронты + какие-то нарезки шаренного кода? Кто же мешает так и делать сразу. Кто-то так и 10 лет назад делал, когда никаких "микрофронтов" ещё и не было.
Это, похоже, вечный спор, который был ещё 10 лет назад. Нейминг и группировка на основе типов сущностей (components, services, hooks) и семантики. Первое просто и универсально, но с определенного момента начинает превращаться в свалку. Второе сложно, думать надо по-больше и единого универсального подхода нет, в одной статье описать сложно. И с первым и со вторым можно жить.
Есть ощущение, что с какого-то момента роста проекта первое начинает внутри прятать второе.
Как по мне, "components", "services", "hooks", "helpers", "utils" - это потенциальные свалки, особенно на верхнем уровне структуры каталогов. Нейминг слишком общий, слишком мало в нем семантики. И лучше бы подумать над более контекстными смысловыми названиями, как минимум, для каталогов верхнего уровня.
Button тоже может? Выглядит так, что в components у вас будут намешаны компоненты с разной семантикой. Ну или не будут, но тогда, скорее всего, в вроде как "простой" классической внутри спрячется семантическая посложнее. Толку тогда от это вроде как "простого" декорирования?..
А какая у вас мотивация предпочитать интерфейсы вместо типов?
Но про костыльность — это я не только про непрочитанные сообщения. Вообще всё решение выглядит костыльно.
Лента RT 2-5000 24V White6000 0.5x (3528, 150 LED, CRI > 85, 250 lm/m, 2.5 W/m)
Лента RT 6-5000 12V White (2835, 150 LED, CRI > 90, 630 lm/m, 6 W/m)
Лента RT 2-5000 12V White6000 (3528, 300 LED, CRI > 85, 410 lm/m, 4.8 W/m)
то возникает легкое недоумение и недоверие, либо в статье сильно приукрасили, либо на сайте ну уж совсем свои заслуги преуменьшили.
Что значит "скрыто"? Просто в другом слое, причем всего лишь на один уровень ниже. Почему Model может туда обращаться, а находящиеся там же (где и Model) View и Controller — нет?
Вы сами ввели в разговор правило непересечения слоев. Вот следуя ему, View и Controller могут обратиться к Domain Model. Если же Вы запретите пересекать границу (какое-то другое правило), то к Domain Model не сможет обратиться Application Model.
Итого: разложив все в три слоя и пользуясь правилом непересечения слоев — картина получается непротиворечивая. Ваше последнее описание мне пока кажется противоречивым. Возможно, Вы используете какой-то другой способ изоляции, но в явном виде пока его не описали, причем еще раз обращу Ваше внимание, что изоляцию через правило непересечения слоев Вы ввели в обсуждение сами.
Вот если руководствоваться правилом непересечения слоев, то надо было просто в три слоя их разложить, а не в два. Но чтобы остаться в рамках картинки, где слоя всего два нарисовано приходится придумывать вот это про границу.
Или что вы под этим размещением на границе подразумевали?