Архитектура FE-части приложения на основе Atomic Design
Решили поделиться с вами одним из решений для создания масштабируемой архитектуры монолитного приложения, которое применяли сами. Метод дает возможность минимизировать накладные расходы на тестирование с разрастанием проекта. А также снижает шансы появления багов в процессе доработки проекта в связи с изменениями требований заказчика.
Молодёжь ведётся на всё модное. И глупое.
Зачем компонент называть молекулой? Или атомом? Просто по чьему-то субъективному мнению, мол этот большой, а этот маленький? А если у другого разработчика другое мнение?
Короче, обозвали зачем-то компоненты по новому и заявляют - это новый подход к проектированию!
Дедушка, позвольте молодежи сказать пару слов)
<= "Короче, обозвали зачем-то компоненты по новому и заявляют - это новый подход к проектированию!"
=> А то вы прям накидываете так, что лопатой не раскидаешь, в тексте нет ни слова, о новизне)
<= "Зачем компонент называть молекулой? Или атомом? Просто по чьему-то субъективному мнению, мол этот большой, а этот маленький? А если у другого разработчика другое мнение?"
=> Данный подход основан на системе, которая иногда используется дизайнерами и которая наиболее близка к дизайн системе)
Ситуация когда другой разработчик подумает по другому, очень легко решается после изучения темы и подходов atomic design, в гугл не посылаю, отдаю сразу первоисточник, ссылочка ниже.
Ну и да, речь не про размер компонента, а про его роль, что вы, конечно же, бы знали после изучения темы.
https://bradfrost.com/blog/post/atomic-web-design/