Согласен, такой вариант тоже рабочий) Строгих правил нет, можно отталкиваться от преимуществ своего продукта, как например, хороший интерфейс, как вы уже упомянули.
Мне кажется, вы недооцениваете силу продвижения) Если у тебя нет поддержки от известных компаний, то крайне тяжело популяризировать свое решение, даже если оно выполнено технически грамотно. Люди чаще всего просто выбирают самое популярное решение, поэтому любой шаг, который может привлечь внимание потенциальных пользователей достаточно важен.
Огромное комьюнити из дилетантов - такое себе преимущество.
По вашему выходит, что все сотни тысяч человек, кто использует React - дилетанты) Не могу согласиться с вашей достаточно надменной позицией, коммьюнити позволяет решить многие возникающие проблемы достаточно быстро.
Как там в этом сезоне модно писать на Реакте? Классы? Функции? Чистые функции? Хоки? Хуки? Флакс? Редакс? Мобыкс? Солид? ЦСС Модули? СтайледКомпонентс? Эмоушен? Афродайт? Формик? РеактФормс? ...
Не вижу в этом ничего плохого, многообразие решений позволяет найти то нужное, что подходит конкретно под проект. Конкуренция между библиотеками бустит индустрию в целом, в моем понимании. FSD же со своей некоторой строгостью помогает избавиться от захламления кодовой базы и привести проекты к единому стилю (как минимум).
Умение писать JSX шаблоны как-то поможет в изучении уникальной архитектуры и связки библиотек очередного проекта? Вы же не пробовали $mol, откуда такая уверенность, что онбординг в проект на нём потребует больше времени?
Очевидно, что человек, знакомый с React и его экосистемой разберется в реактовском проекте быстрее, чем с проектом, написанным на $mol. При этом ему нужно отказаться от всей знакомой ему экосистемы, сознательно ограничиться в инструментарии и погружаться в чужую экосистему, со своими багами и велосипедами. Мне кажется, оно того не стоит.
Я понимаю ваше желание продвинуть свою библиотеку и возможно это действительно хорошее решение, однако смена React на $mol это более, как вы выразились, дерзкий эксперимент, чем смена методологии) React обладает огромным коммьюнити и сформированной базой готовых решений на все случаи жизни, а онбординг новых людей в реактовский проект будет проходить гораздо быстрее, чем в известный только в узких кругах $mol. Все это вкупе ускоряет разработку и позволяет выпустить продукт в максимально быстрые сроки. Поэтому вопрос о смене фреймворка пока не стоит)
Насчет ограничения слоев нужно разбираться в каждом конкретном случае отдельно. Страницы в некоторых случаях могут вкладываться друг в друга, а если "Чат" является внешней библиотекой, то ничему не препятствует его вложению в виджет "Лента комментариев". По проблеме изоляции модулей подробно описано в документации здесь.
Начну с конца) Да, представленный вами пример нарушает базовое правило методологии и сигнализирует о проблемах в архитектуре. Кстати, еще один несомненный плюс методологии FSD - у нее есть обширная документация со множеством примеров и ссылок на различные статьи)
В конкретно вашем случае нужно сначала проанализировать зоны ответственности модулей "Пост" и "Комментарий", дабы понять, нужно ли объединять или делить модули, а после переместить логику на слой выше или ниже. Самый простой из возможных вариантов решения данной проблемы - создания виджета, который свяжет между собой нижние слои-сущности "Пост" и "Комментарий". Такая комбинация, на мой взгляд, обладает достаточной самостоятельностью и позволяет избежать дублирования логики. Но тут все зависит от конкретного случая)
Когда даешь советы по неймингу, но сам не справляешься с ним) Учту на будущее, благодарю!
Согласен, такой вариант тоже рабочий) Строгих правил нет, можно отталкиваться от преимуществ своего продукта, как например, хороший интерфейс, как вы уже упомянули.
Мне кажется, вы недооцениваете силу продвижения) Если у тебя нет поддержки от известных компаний, то крайне тяжело популяризировать свое решение, даже если оно выполнено технически грамотно. Люди чаще всего просто выбирают самое популярное решение, поэтому любой шаг, который может привлечь внимание потенциальных пользователей достаточно важен.
По вашему выходит, что все сотни тысяч человек, кто использует React - дилетанты) Не могу согласиться с вашей достаточно надменной позицией, коммьюнити позволяет решить многие возникающие проблемы достаточно быстро.
Не вижу в этом ничего плохого, многообразие решений позволяет найти то нужное, что подходит конкретно под проект. Конкуренция между библиотеками бустит индустрию в целом, в моем понимании. FSD же со своей некоторой строгостью помогает избавиться от захламления кодовой базы и привести проекты к единому стилю (как минимум).
Очевидно, что человек, знакомый с React и его экосистемой разберется в реактовском проекте быстрее, чем с проектом, написанным на $mol. При этом ему нужно отказаться от всей знакомой ему экосистемы, сознательно ограничиться в инструментарии и погружаться в чужую экосистему, со своими багами и велосипедами. Мне кажется, оно того не стоит.
Я понимаю ваше желание продвинуть свою библиотеку и возможно это действительно хорошее решение, однако смена React на $mol это более, как вы выразились, дерзкий эксперимент, чем смена методологии) React обладает огромным коммьюнити и сформированной базой готовых решений на все случаи жизни, а онбординг новых людей в реактовский проект будет проходить гораздо быстрее, чем в известный только в узких кругах $mol. Все это вкупе ускоряет разработку и позволяет выпустить продукт в максимально быстрые сроки. Поэтому вопрос о смене фреймворка пока не стоит)
Насчет ограничения слоев нужно разбираться в каждом конкретном случае отдельно. Страницы в некоторых случаях могут вкладываться друг в друга, а если "Чат" является внешней библиотекой, то ничему не препятствует его вложению в виджет "Лента комментариев". По проблеме изоляции модулей подробно описано в документации здесь.
Начну с конца) Да, представленный вами пример нарушает базовое правило методологии и сигнализирует о проблемах в архитектуре. Кстати, еще один несомненный плюс методологии FSD - у нее есть обширная документация со множеством примеров и ссылок на различные статьи)
В конкретно вашем случае нужно сначала проанализировать зоны ответственности модулей "Пост" и "Комментарий", дабы понять, нужно ли объединять или делить модули, а после переместить логику на слой выше или ниже. Самый простой из возможных вариантов решения данной проблемы - создания виджета, который свяжет между собой нижние слои-сущности "Пост" и "Комментарий". Такая комбинация, на мой взгляд, обладает достаточной самостоятельностью и позволяет избежать дублирования логики. Но тут все зависит от конкретного случая)