Comments 10
Отличная статья! Добавлю еще сюда иммутабельность. Некоторые товарищи любят создавать объекты, напихавать их пропсами, потом где-то както менять их, заигрываются с рефами, создают несколько источников правды в стейте. В общем там даже тайпскрипт становится бессилным.
Код в картинках...
Хорошая статья, жду продолжения. На тему SOLiD вроде уже много статей, но очень мало инфы о том как придерживаться этих принципов на фронте. Лично мне помогло гораздо лучше понять суть, когда я разбирал свои и чужие примеры, и прям во время ревью пробегался по каждому из них, и сразу легче становится определять проблемные участки кода. Единственное, по поводу SRP, моё мнение, что не всегда стоит стремиться к нему в компонентах, особенно бизнесовых, поэтому я его больше воспринимаю как рекомендацию: не единую, а минимально возможных ответственностей.
Кстати по по поводу разделения интерфейсов, он же тоже отлично подходит для нас, только его надо чуть иначе воспринимать, если в ооп речь про интерфейсы описывающие объекты и классы, то в нашем случае этими интерфейсами мы можем воспринимать компоненты, как раз затрагивает тему перегруженности компонентов пропсами и методами. Ну можно его наверное переназвать принцип разделения компонентов :)
Не очень люблю материалы в ключе "ууу, гады, так делать плохо" без малейшей попытки сказать, как делать хорошо. SOLID? Окей. Покажите на примере, как крайне сложную бизнес-логику разместить идеально-удобно, чтобы не было ошибки.
Серебрянной пули не существует и SOLID ей не является. Полезен ли он? Безусловно. Возможно ли его везде применять? Нет конечно.
Возможно ли его везде применять? Нет конечно.
Вот поэтому и говно-код отовсюду лезет. Потому что "это я не буду применять, это я не буду читать", а потом через месяц разраб уже сам не понимает, чего написал.
Еще раз. Материал плох из-за того, что он абстрактен. Принципы SOLID разобраны и обсосаны всеми. Они применяются, в большинстве своем. Их можно и нужно применять. Как и YAGNI, KISS и так далее. Но материал ни о чем, потому что об абстракциях и на глупых примерах.
Мы открываем код любого проекта и видим компоненты. Заходим в любой из них и обнаруживаем:
кусочек кода объявления состояния
кусочек кода действий по обновлению этого состояния
кусочек кода по верстке
кусочек кода по api запросам (хорошо если они вынесены наружу)
кусочек кода по объявлению типов
...
Вот покажите в материале, как у вас "плохие" компоненты отрефакторились в хорошие компоненты по принципам SOLID. Я читал https://habr.com/ru/companies/beeline_tech/articles/862558/ вторую часть и могу сказать, что вы сделали ровно то, с чем боролись. Вы не избавились от мусора. Вы переложили его из одного места в другое. Это как вечный спор бэкэндеров: fat models vs fat controllers. Хотя ни то ни то не является хорошим решением.
Хотите хороший пример материала по SOLID в фронтенд приложениях?
Ловите: https://medium.com/dailyjs/applying-solid-principles-in-react-14905d9c5377
Я высказался.
Простите, но наброшу - все эти проблемы зачастую - следствие самого подхода Реакта - что "я - мол библиотека, используйте меня как хотите, я даже слова не скажу, я даже не буду добавлять по умолчанию тайпскрипт, чтобы уменьшить боли от разработки.
Отсюда и рождаются другие потребности - в накачивании "обычной библиотеки" стероидами в виде других библиотек или даже (о чудо чудное) фреймворков, таких как Next.
Реакт сам себя топит, а потом героически достаёт себя из воды за уши.
Многослойная архитектура FrontEnd-приложений на основании SOLID, часть 1