Ответ
Наиболее популярные архитектурные методологии во фронтенде:
-
MVC (Model-View-Controller)
Разделение на модель (данные), представление (UI) и контроллер (логика). Пример: Backbone.js. -
MVVM (Model-View-ViewModel)
Добавляет ViewModel для двустороннего биндинга. Пример: Vue, Angular. -
Flux/Redux
Односторонний поток данных: Action → Dispatcher → Store → View. Пример: React + Redux. -
Atomic Design
Разбиение UI на атомы (кнопки), молекулы (формы), организмы (блоки). -
Feature-Sliced Design
Группировка кода по фичам, а не по типам файлов (components, hooks и т.д.).
Пример Redux:
// Action
const increment = () => ({ type: 'INCREMENT' });
// Reducer
const counter = (state = 0, action) => {
switch (action.type) {
case 'INCREMENT': return state + 1;
default: return state;
}
};
// Store
const store = createStore(counter);Ответ 18+ 🔞
А, слушай, вот эти ваши архитектурные методологии во фронтенде — это вообще отдельный цирк с конями, блядь. Сидят умники, придумывают аббревиатуры, а потом мы, лохи, их внедряем и нихуя не понимаем, что происходит. Но ладно, разберём по полочкам, как есть.
Вот, например, MVC (Model-View-Controller). Это как старый дед в подъезде, который всем мозги выносит, но работает, ёпта. Модель — это данные, вид — это то, что ты видишь, а контроллер — это такой посредник, который всё это соединяет и орёт на обоих. Типа Backbone.js, который уже, конечно, накрылся медным тазом, но в своё время был царём и богом.
Потом пошли умнее — придумали MVVM (Model-View-ViewModel). Тут уже добавили эту вашу ViewModel, которая делает магию двустороннего биндинга. Нажал кнопку — данные обновились, изменил данные — интерфейс подстроился. Vue или Angular этим промышляют. Удобно, конечно, но иногда такая ебля начинается с отслеживанием изменений, что волосы дыбом встают, в рот меня чих-пых!
А потом пришли ребята из Facebook и сказали: «Всё, мудаки, хватит эту хуйню городить! Давайте сделаем односторонний поток, чтобы всё было предсказуемо!». И родился Flux, а потом и Redux. Action → Dispatcher → Store → View. И никаких тебе сюрпризов, всё как по нотам. Только вот boilerplate-кода пишешь — овердохуища, на одно простое действие — три файла и пятнадцать строк кода. Но зато стабильно, блядь.
// Action — типа, я хочу что-то сделать
const increment = () => ({ type: 'INCREMENT' });
// Reducer — а вот тут решается, можно ли это сделать
const counter = (state = 0, action) => {
switch (action.type) {
case 'INCREMENT': return state + 1;
default: return state;
}
};
// Store — и вот тут всё это хранится
const store = createStore(counter);Смотри, вроде просто, а? А теперь представь, что у тебя не счётчик, а целое состояние приложения с пользователями, заказами и корзиной. Вот тут-то и начинается настоящий пиздец, ёперный театр!
Ещё есть Atomic Design. Это когда ты разбиваешь интерфейс на атомы (кнопочка), молекулы (форма поиска) и организмы (целый хедер). В теории — красота, переиспользование компонентов на максимум. На практике — начинаешь спорить с дизайнером, что вот эта иконка — это атом или уже молекула, и в итоге все друг друга ненавидят.
И наконец, Feature-Sliced Design. Это свежая идея, чтобы не таскать компоненты, хуки и стили по разным папкам, а складывать всё, что относится к одной фиче, в одну кучу. Типа «корзина» — и там всё про корзину. Звучит логично, но попробуй убедить в этом команду из десяти человек, у каждого из которых своё видение, где что должно лежать. Подозрение ебать чувствую, что это закончится очередной войной за нейминг папок.
В общем, выбирай, что тебе ближе: старый добрый бардак, новый строгий порядок или что-то посередине. Главное — не увлекайся архитектурой ради архитектуры, а то можно так зарефакторить, что сам потом ни хуя не поймёшь, как это работает.