Архитектурный шаблон MVVM для приложения ReactJS

Сам React не особо критикует архитектуру программного обеспечения. Это библиотека, которая упрощает парадигму многократно используемых компонентов наряду с рекомендациями по управлению такими вещами, как состояние и совместное использование данных (реквизиты). В какой-то момент Facebook описал это как the V in MVC, но с тех пор отошел от этого маркетинга и назвал его более абстрактно A JavaScript library for building user interfaces.

Конечно, типичный инструментарий, связанный с приложениями React, действительно поддается некоторой архитектуре при совместном использовании.

Вот пара возможных способов подумать об этом:

Приложения Simple React могут быть просто «VVM» или «VC».

MVC, вероятно, наиболее известен в мире разработки. Ключевое концептуальное различие между контроллером (C) и моделью представления (VM) можно свести к следующему: контролер может иметь множество разнообразных обязанностей, таких как отслеживание событий и их маршрутизация в правильном направлении. Это клей, который облегчает функциональность всего приложения. С другой стороны, модель просмотра просто отвечает за приклеивание текущего состояния данных к модели.

Таким образом, первоначальное использование Facebook «V в MVC», вероятно, с таким же успехом могло быть «V в MVVM» - термин «контроллер» имеет больше смысла в мире бэкэнд-разработки.

Простое приложение React без Redux, которое загружает данные непосредственно в компоненты (например, fetch в componentDidMount или использует GraphQL) с ограниченным сбором данных любого типа, можно назвать простой моделью «VVM».

Представление-модель (ВМ): код, связанный с компонентами, который управляет простым состоянием, передает данные непосредственно в представление, потенциально передает данные непосредственно обратно из представления.

Посмотреть (V): Как выглядят визуальные элементы (JSX, CSS)

Добавьте немного сложности, и вы могли бы назвать это "MVVM" / "MVC"

Если вы добавите Redux, redux-saga или даже начнете делать сумасшедшие вещи с простым состоянием компонента React, вы вводите операции модели. Модель (M) может представлять как минимум две вещи:

1. Актуальная бизнес-логика для вашего приложения
2. Хранение и управление сложным поведением вашего клиента

На практике бизнес-логика иногда нежелательна: например, если у вас есть контроль над сервером, возможно, стоит сохранить всю бизнес-логику в одном месте (на сервере) и просто передать пользовательскому интерфейсу то, что ему нужно для взаимодействия с пользователем. Но если у вас ограниченные конечные точки REST и вам нужно немного спорить (например, в ваших сагах или внутри компонентов), это будет бизнес-логика.

Управление поведением клиентов вероятно, особенно в сложных приложениях, где вы можете делать такие вещи, как отображение различных вещей для пользователя в зависимости от его сеанса (например, это незарегистрированный пользователь, а не пользователь или администратор). Вы, вероятно, делаете это в любых взаимодействиях с хранилищем redux, которые предназначены для использования только клиентом.

Отказ от ответственности: обсуждение MVC, MVVM и т. д. Может привести к множеству различных мнений о точно, что они означают [1]. Выше я попытался провести параллели между общими шаблонами, которые я видел, и тем, как они вписываются в MVC / MVVM, но есть так много разных подходов к этому или более детальных способов обдумать это. Я бы не стал слишком зацикливаться на ярлыке, если ваша система проста для понимания: модульная, СУХОЙ, абстрактная и т. д. На уровнях, которые имеют смысл для вашего варианта использования и масштаба разработки.

[1] Обсуждается в дополнительной длине в ответы и комментарии на этот вопрос

Простое веб-приложение не требует MVC, MVVM, не требует даже React IMO. Возможная эволюция простого приложения ReactJS, которому может потребоваться MVVM / MVC /, если оно попытается стать PWA (прогрессивным веб-приложением). Другими словами - если он пытается выполнить какую-то конкретную логику (приложение / домен) - офлайн, а какая-то другая - онлайн. Это естественная точка зрения при разработке мобильных приложений. Затем информация может быть получена из локального хранилища или IndexedDB (для Интернета) или Back-End / Rest /. Тогда разделение модели, хранилища / репозитория / источника INfo / ViewModel / или контроллера / и представления будет естественным и действительно необходимым для правильной работы всего ...