Комментарии 12
Спасибо за статью. А как быть в случае если одна сущность содержит в себе другую? Например, Посты содержат комментарии. Стоит ли комментарии выносить в отдельную сущность? Если да, то уместно ли типы комментариев импортировать в сущность страниц? Считается ли это кросскомпонентом в таком случае и плохим тоном в данной методологии?
Начну с конца) Да, представленный вами пример нарушает базовое правило методологии и сигнализирует о проблемах в архитектуре. Кстати, еще один несомненный плюс методологии FSD - у нее есть обширная документация со множеством примеров и ссылок на различные статьи)
В конкретно вашем случае нужно сначала проанализировать зоны ответственности модулей "Пост" и "Комментарий", дабы понять, нужно ли объединять или делить модули, а после переместить логику на слой выше или ниже. Самый простой из возможных вариантов решения данной проблемы - создания виджета, который свяжет между собой нижние слои-сущности "Пост" и "Комментарий". Такая комбинация, на мой взгляд, обладает достаточной самостоятельностью и позволяет избежать дублирования логики. Но тут все зависит от конкретного случая)
Для нашей команды эти проблемы также актуальны. Чтобы их решить раз и навсегда, мы обратились к активно развивающейся методологии Feature-Sliced Design (FSD).
Вот я смотрю вы не боитесь самых дерзких экспериментов с активно развивающимися штуками. Может тогда ещё и $mol попробуете, чтобы не иметь следующих проблем:
нет единой методологии по проектированию приложений, как, например, в Angular. Кроме того, многообразие библиотек усложняет погружение в проект, а свобода в реализации и проектировании может обернуться захламлением кодовой базы, что пугает разработчиков, особенно новичков
Ну и заодно расскажите, почему нам стоит ограничивать себя и не допускать встраивания страницы "авторизация" в страницу "форма комментария", или приложения "чат" в виджет "лента комментариев"? Потому что кривой фреймворк на самом деле не умеет в компонентную декомпозицию?
Я понимаю ваше желание продвинуть свою библиотеку и возможно это действительно хорошее решение, однако смена React на $mol это более, как вы выразились, дерзкий эксперимент, чем смена методологии) React обладает огромным коммьюнити и сформированной базой готовых решений на все случаи жизни, а онбординг новых людей в реактовский проект будет проходить гораздо быстрее, чем в известный только в узких кругах $mol. Все это вкупе ускоряет разработку и позволяет выпустить продукт в максимально быстрые сроки. Поэтому вопрос о смене фреймворка пока не стоит)
Насчет ограничения слоев нужно разбираться в каждом конкретном случае отдельно. Страницы в некоторых случаях могут вкладываться друг в друга, а если "Чат" является внешней библиотекой, то ничему не препятствует его вложению в виджет "Лента комментариев". По проблеме изоляции модулей подробно описано в документации здесь.
React обладает огромным коммьюнити
Огромное комьюнити из дилетантов - такое себе преимущество.
и сформированной базой готовых решений на все случаи жизни,
Как там в этом сезоне модно писать на Реакте? Классы? Функции? Чистые функции? Хоки? Хуки? Флакс? Редакс? Мобыкс? Солид? ЦСС Модули? СтайледКомпонентс? Эмоушен? Афродайт? Формик? РеактФормс? ...
а онбординг новых людей в реактовский проект будет проходить гораздо быстрее, чем в известный только в узких кругах $mol
Умение писать JSX шаблоны как-то поможет в изучении уникальной архитектуры и связки библиотек очередного проекта? Вы же не пробовали $mol, откуда такая уверенность, что онбординг в проект на нём потребует больше времени?
Все это вкупе ускоряет разработку и позволяет выпустить продукт в максимально быстрые сроки.
Да-да, как раз недавно рассказывал про это..
если "Чат" является внешней библиотекой, то ничему не препятствует его вложению в виджет "Лента комментариев"
Чат - это стороннее приложение "мессенджер", которое интегрируется в качестве виджета в другие приложения.
Огромное комьюнити из дилетантов - такое себе преимущество.
По вашему выходит, что все сотни тысяч человек, кто использует React - дилетанты) Не могу согласиться с вашей достаточно надменной позицией, коммьюнити позволяет решить многие возникающие проблемы достаточно быстро.
Как там в этом сезоне модно писать на Реакте? Классы? Функции? Чистые функции? Хоки? Хуки? Флакс? Редакс? Мобыкс? Солид? ЦСС Модули? СтайледКомпонентс? Эмоушен? Афродайт? Формик? РеактФормс? ...
Не вижу в этом ничего плохого, многообразие решений позволяет найти то нужное, что подходит конкретно под проект. Конкуренция между библиотеками бустит индустрию в целом, в моем понимании. FSD же со своей некоторой строгостью помогает избавиться от захламления кодовой базы и привести проекты к единому стилю (как минимум).
Умение писать JSX шаблоны как-то поможет в изучении уникальной архитектуры и связки библиотек очередного проекта? Вы же не пробовали $mol, откуда такая уверенность, что онбординг в проект на нём потребует больше времени?
Очевидно, что человек, знакомый с React и его экосистемой разберется в реактовском проекте быстрее, чем с проектом, написанным на $mol. При этом ему нужно отказаться от всей знакомой ему экосистемы, сознательно ограничиться в инструментарии и погружаться в чужую экосистему, со своими багами и велосипедами. Мне кажется, оно того не стоит.
По вашему выходит, что все сотни тысяч человек, кто использует React - дилетанты)
99% - да. В том числе те, что выдают себя за "экспертов по построению архитектуры на Реакт". 1% - заложники, вынужденные работать с тем, что дали, без возможности взять что-то более продуманное.
коммьюнити позволяет решить многие возникающие проблемы достаточно быстро
Это какие такие проблемы? Которые созданы кривой архитектурой Реакта? Этому комьюнити не хватает даже экспертизы, чтобы понять в чём источник тех проблем, с которыми они героически, но безуспешно борются всей толпой.
многообразие решений позволяет найти то нужное, что подходит конкретно под проект
Проблема не в многообразии, а в постоянном переписывании вроде бы "готовых решений" каждый год. Шестая мажорная версия реакт роутера не даст соврать. А всё потому, что понимание, что с текущим положением дел что-то не так, - есть, а понимания, что именно не так, - нет. Вот и тычутся, как слепые котята, меняя шило на мыло.
FSD же со своей некоторой строгостью
"немножко беременна" - из той же области медицины. Любое нестрогое правило будет нарушаться, чем разрушать любые возможные преимущества этого правила. А нарушаться они будут неизбежно, так как десяток корзин, куда складывается всё - не масштабируется. А масштабироваться могут только фрактальные архитектуры.
Очевидно, что человек, знакомый с React и его экосистемой разберется в реактовском проекте быстрее, чем с проектом, написанным на $mol
Не очевидно. Возьмите два проекта на Реакт. Общего у них будет только шаблоны на JSX, и даже они скорее всего писаться будут по разному. Придётся втыкать в новую связку библиотек, которые проблем создают больше, чем решают, осваивать новые виды костылей, которые то и дело ломаются, привыкать писать бойлерплейт по новому, и привыкать его переписывать. А если на проект затянули ещё и какой-нибудь новомодный эффектор, то это вообще на пол года затянется.
ему нужно отказаться от всей знакомой ему экосистемы
Раздутая экосистема, тянущая тонны тормозных говнолиб из нпм и раздувающая бандлы так, что даже микро-фронтенд-модуль-федерейшен не спасает. Бежать от такой экосистемы надо как от огня.
сознательно ограничиться в инструментарии
Попробуйте отыскать в реактовой экосистеме хоть одну либу объективно лучше, чем в $mol.
Неправильно вы свое детище продвигаете
То что реакт шляпа я согласен, но вот мол ваш, нет слов, уверен на 99,(9)% что ни кто им не будет пользоваться. Люди ленивые, по природе, ни кто не хочет учить новый синтаксис, по этому реакт на вершине. Так как по сути реакт, это ванилла js приправленная ванилла HTML. Если ты знаешь ванила js то ты считай знаешь и реакт. То же относится и к TypeScript и к SCSS. Это просто расширение существующих технологий. Это база. Все less, angular, vue и svelte, это не расширение, а переопределение. Не знаю как объяснить эту мысль лучше.
Кстати, как же тут не упомянуть обзор упоротого молера:
Feature-Sliced Design: эволюция фронтенда для быстрых экспериментов