Весь диалог строиться вокруг компонентов фреймворка react - так и пришли. Хотелось бы понять что вы подразумевает под layout? Если это разметка header, body, footer, sidebar и т.д. То это не всегда может быть стандартизировано для всех страниц вашего приложения, но если очень хочется, то можно привести к одному виду и вынести в ui kit. Отступ можно стандартизировать через тему.
Чтобы не плодить компонент на каждый "чих", вы должны продумать api (набор props) вашего компонента так, чтобы через него можно было настраивать внешний вид. Например для цвета можно использовать отдельный prop color.
Последнюю часть не очень понял, не знаю как прокомментировать.
Если возникла такая ситуация, то это повод задуматься - Почему ваш UI kit компонент требуется докручивать до того дизайна что вам требуется? Вы не должны тратить время на выравнивание стилизации, так как она уже должна быть выровнена согласно дизайну. Иначе вы теряете преимущества использования UI kit.
Frontend разработчик должен корректировать дизайнеров если считает, что дизайн содержит противоречия. Дизайнеры не всегда имеют знания об ограничениях со стороны фронта.
Если я правильно вас понял, есть UI пакет с css-modules, и вы его подтягиваете для стилизации чего либо. Пример
import { button } from "@ui-kit/css-modules";
<button className={button}>Отправить</button>
В таком случае, мои аргументация построенная вокруг className не работает. Так как ваше решение отдаёт лишь стили, а не заранее стилизованные компоненты.
Мне очень понравился ваш термин "локальный стиль" - он более политкорректный. Но, мне кажется, такая формулировка размывает серьёзность проблемы.
Если вы создаёте систему UI компонентов, то любое переопределение стилей на локальную вариацию - это сигнал о том, что то идёт не так. Если нужна "сложная визуализация", то она должна лежать в ui kit компонентах c ещё большей вероятностью. А не оставаться где то локально в месте использования.
Я согласен с последним тезисом, но не полностью. Вы потратили время на разработку UI Kit, который решает конкретную проблему - переиспользование. И продолжаете модифицировать набор компонентов от случая к случаю. И это значит, что ваш UI Kit не выполняет той функции, которую вы на него возложили. Так почему я должен не называть такие точечные стилизации "костылями"?
У меня такой же опыт, поэтому решил поднять эту тему. Но я, к сожалению, не смог аргументировать использование className в ui kit компонентов компании. Если у вас есть пример обоснованного использования className в такой ситуации, буду очень рад услышать его.
Дошло про что вы, прошу прощения не могу написать конкретный пример, так как это уже другая целая статья, где надо "теорию" приблизить к практике.
Вы правы - логика и представление так плотно свяжутся, что их почти невозможно менять независимо друг от друга.
Но хук так же не защищает от этого. Хук, реализующий сложную бизнес-логику, так же может стать непереиспользуемым, так как будет плотная связь с конкретным отображением.
Прощу прощения, всё чтобы я не привёл в качестве примера не будет сильным аргументом. Так как "сделать можно всё через хуки". Но вот вам утрированный пример представим что надо шарить между командами логику. Команды пишут на разных фреймворках. Сможете ли вы шарить ваши хуки в этом случае?
По моим примерам из статьи видно, что сделать можно всё через хуки. Я хотел добиться результата, где в мою логику не протекает что-то связанное с render циклом компонента. Это сделает связь между представлением (отображением) и логикой менее сильной, что не может сделать хук.
За догму можно взять и то, что писать всё в рендер функции — это хорошо, чтобы было проще. Могут быть разные ситуации, где один подход будет выглядеть привлекательнее другого и наоборот. Но из моего опыта есть закономерность, что написанный код в одном файле после его декомпозиции становится более читабельным. Разделение на логические блоки кода создаёт более четкие границы, которые человеку проще воспринимать. Конечно, могут быть исключения.
Да, результат скорее отрицательный, но для меня было интересно покапать в этом направлении.
Смысл тут в интересе, как можно сделать по другому. Предполагалось, что логика из reducer не будет глобальной, а будет находится по близости с отображением. И хранилище создаётся под каждую конкретную ситуацию. Конечно, это выглядит не поворотливо. И лучше просто использовать хук, но это не значит, что не стоит исследовать другие варианты реализации.
Может, я не корректно выразился и ввёл вас в заблуждение. То, что вы предлагаете — безусловно работает и является хорошим решением, которое я описал в рамках компонента `Bloc`. Но моя идея в том, чтобы убрать из логики что-то связанное с жизненным циклом компонента. Поэтому я не стал останавливаться на этом варианте, но и не обошёл его стороной.
? Это презентация небольшого исследования - А что если не использовать хуки?. Конечно я не делаю так на боевых проектах. Это лишь желание дать пищу для ума, что можно по другому.
Плюсы могут стать и минусами в зависимости от разработчика. Подход непривычный и сырой, что делает его более затратным. Использование хранилища конечно выглядит избыточным.
Лично для меня декомпозиция лучше сказывается на поддержке, так как чёткие границы позволяют изолировать ошибки или зону вносимых изменений. Но для кого это не так и на это надо обращать внимание, поэтому вынес это в минус.
Да, я понимаю, что проще использовать хук. Но задумка была пощупать другой подход. По поводу селекторов, надо посмотреть как это пишется в slice. Но написание селектора - это вторично по отношению к теме.
Вы абсолютно правы, что подсоединять каждый компонент к глобальному хранилищу - это мягко говоря бред. Но как пример, возможной реализации, он подошёл.
Тесты используются, как пример смешения хука и рендера компонента и для помощи в декомпозиции. Как их писать и что покрывать тестами - другая история.
Весь диалог строиться вокруг компонентов фреймворка react - так и пришли. Хотелось бы понять что вы подразумевает под layout? Если это разметка header, body, footer, sidebar и т.д. То это не всегда может быть стандартизировано для всех страниц вашего приложения, но если очень хочется, то можно привести к одному виду и вынести в ui kit. Отступ можно стандартизировать через тему.
Чтобы не плодить компонент на каждый "чих", вы должны продумать api (набор props) вашего компонента так, чтобы через него можно было настраивать внешний вид. Например для цвета можно использовать отдельный prop color.
Последнюю часть не очень понял, не знаю как прокомментировать.
Согласитесь, что любые модификации должны быть предусмотрены в этом компоненте через его набор props (через его api).
Уже - это в UI kit. Вы же его разрабатываете не для того что бы править под каждый случай.
Если возникла такая ситуация, то это повод задуматься - Почему ваш UI kit компонент требуется докручивать до того дизайна что вам требуется? Вы не должны тратить время на выравнивание стилизации, так как она уже должна быть выровнена согласно дизайну. Иначе вы теряете преимущества использования UI kit.
Звучит идеально, но к этому надо стремиться.
Frontend разработчик должен корректировать дизайнеров если считает, что дизайн содержит противоречия. Дизайнеры не всегда имеют знания об ограничениях со стороны фронта.
Я говорил о случаях когда ваша или готовая UI библиотека отдаёт - компоненты, а не только стили.
Если вы прямо в месте использования собираете нужный вам класс, то для вас className жизненно необходим. Пример
<button className="button button__size_s">Отправить</button>
Но если вы инкапсулируете стилизацию внутри компонентов, то у вас "класс-костыль". Пример
<Button className="класс-костыль" size="s" >Отправить</button>Если я правильно вас понял, есть UI пакет с css-modules, и вы его подтягиваете для стилизации чего либо. Пример
import { button } from "@ui-kit/css-modules";
<button className={button}>Отправить</button>
В таком случае, мои аргументация построенная вокруг className не работает. Так как ваше решение отдаёт лишь стили, а не заранее стилизованные компоненты.
Мне очень понравился ваш термин "локальный стиль" - он более политкорректный. Но, мне кажется, такая формулировка размывает серьёзность проблемы.
Если вы создаёте систему UI компонентов, то любое переопределение стилей на локальную вариацию - это сигнал о том, что то идёт не так. Если нужна "сложная визуализация", то она должна лежать в ui kit компонентах c ещё большей вероятностью. А не оставаться где то локально в месте использования.
Я согласен с последним тезисом, но не полностью. Вы потратили время на разработку UI Kit, который решает конкретную проблему - переиспользование. И продолжаете модифицировать набор компонентов от случая к случаю. И это значит, что ваш UI Kit не выполняет той функции, которую вы на него возложили. Так почему я должен не называть такие точечные стилизации "костылями"?
У меня такой же опыт, поэтому решил поднять эту тему. Но я, к сожалению, не смог аргументировать использование className в ui kit компонентов компании. Если у вас есть пример обоснованного использования className в такой ситуации, буду очень рад услышать его.
Можем, но это уже немного другая история со своими ограничениями.
Дошло про что вы, прошу прощения не могу написать конкретный пример, так как это уже другая целая статья, где надо "теорию" приблизить к практике.
Вы правы - логика и представление так плотно свяжутся, что их почти невозможно менять независимо друг от друга.
Но хук так же не защищает от этого. Хук, реализующий сложную бизнес-логику, так же может стать непереиспользуемым, так как будет плотная связь с конкретным отображением.
Прощу прощения, всё чтобы я не привёл в качестве примера не будет сильным аргументом. Так как "сделать можно всё через хуки". Но вот вам утрированный пример представим что надо шарить между командами логику. Команды пишут на разных фреймворках. Сможете ли вы шарить ваши хуки в этом случае?
Полезный комментарий, благодарю.
По моим примерам из статьи видно, что сделать можно всё через хуки. Я хотел добиться результата, где в мою логику не протекает что-то связанное с render циклом компонента. Это сделает связь между представлением (отображением) и логикой менее сильной, что не может сделать хук.
За догму можно взять и то, что писать всё в рендер функции — это хорошо, чтобы было проще. Могут быть разные ситуации, где один подход будет выглядеть привлекательнее другого и наоборот. Но из моего опыта есть закономерность, что написанный код в одном файле после его декомпозиции становится более читабельным. Разделение на логические блоки кода создаёт более четкие границы, которые человеку проще воспринимать. Конечно, могут быть исключения.
Да, результат скорее отрицательный, но для меня было интересно покапать в этом направлении.
Будет меньше факторов влияющих на работу логики. Написание хуков накладывает некоторые ограничения. Навскидку
Вы не можете менять порядок хуков между перерисовками
Где то требуется мемоизация, так как это может сказаться на перерисовке
При тестировании надо вызвать перерисовку хука через утилиту act
Хуки нельзя вызывать из классовых компонентов или в других местах кроме render функции
Поэтому я искал способ избавится от примеси чего то компонентного в логике, что сделает её более чистой, простой и более переиспользуемой.
Смысл тут в интересе, как можно сделать по другому. Предполагалось, что логика из reducer не будет глобальной, а будет находится по близости с отображением. И хранилище создаётся под каждую конкретную ситуацию. Конечно, это выглядит не поворотливо. И лучше просто использовать хук, но это не значит, что не стоит исследовать другие варианты реализации.
Может, я не корректно выразился и ввёл вас в заблуждение. То, что вы предлагаете — безусловно работает и является хорошим решением, которое я описал в рамках компонента `Bloc`. Но моя идея в том, чтобы убрать из логики что-то связанное с жизненным циклом компонента. Поэтому я не стал останавливаться на этом варианте, но и не обошёл его стороной.
Что правда, то правда ?
? Это презентация небольшого исследования - А что если не использовать хуки?. Конечно я не делаю так на боевых проектах. Это лишь желание дать пищу для ума, что можно по другому.
Плюсы могут стать и минусами в зависимости от разработчика. Подход непривычный и сырой, что делает его более затратным. Использование хранилища конечно выглядит избыточным.
Лично для меня декомпозиция лучше сказывается на поддержке, так как чёткие границы позволяют изолировать ошибки или зону вносимых изменений. Но для кого это не так и на это надо обращать внимание, поэтому вынес это в минус.
Да, я понимаю, что проще использовать хук. Но задумка была пощупать другой подход.
По поводу селекторов, надо посмотреть как это пишется в slice. Но написание селектора - это вторично по отношению к теме.
Вы абсолютно правы, что подсоединять каждый компонент к глобальному хранилищу - это мягко говоря бред. Но как пример, возможной реализации, он подошёл.
Тесты используются, как пример смешения хука и рендера компонента и для помощи в декомпозиции. Как их писать и что покрывать тестами - другая история.