Интерактив по Flux и MVC

Когда мы разобрались с действиями пришло время добавить приложению интерактивность. Для этого сделаем полноценные кнопки добавления лотов в избранное. И на этом примере разберём архитектуру Flux для построения интерактивного интерфейса фронтенда. Найдём сходство с классическим паттерном MVC для построения пользовательских интерфейсов и рассмотрим его упрощённую реализацию Web-MVC для бэкенда.

  • 00:01:35 Флаг добавления в избранное
  • 00:02:30 Стилизация избранных лотов
  • 00:03:13 Вывод кнопки
  • 00:04:08 Вынесение кнопки в компонент
  • 00:04:51 Уменьшение связанности компонентов
  • 00:06:40 Подключение иконок
  • 00:08:55 Написание экшена и редьюсера
  • 00:10:32 Процедуры для действий
  • 00:11:05 Выполнение запросов к API
  • 00:13:31 Привязка действий к кнопкам
  • 00:15:47 Возврат чистоты функций
  • 00:17:22 Отвязка компонента от сущности
  • 00:21:32 Перенос действий в локальную область видимости
  • 00:22:32 Структура приложения
  • 00:23:48 Архитектура Flux
  • 00:25:56 Работа с несколькими представлениями
  • 00:27:40 Вывод лотов таблицей
  • 00:29:28 Паттерн MVC для интерфейсов
  • 00:37:19 Сложности передачи props

А в следующем эпизоде решим проблему повсеместной передачи props-ов.

Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Комментарии (22)
Arunas

Спасибо.

Ответить
fedot

Спасибо

Ответить
Кропотов Александр

Дмитрий, во первых, конечно же спасибо. А вопрос такой. Вы предполагаете использовать все же Редакс для хранения состояния? Как то складывается ощущение что сейчас в тренде Хуки, и будущее за ними. И еще вопрос. Будете какую либо UI библиотеку использовать в проекте аукциона? Ну типа material-ui.

Ответить
Дмитрий Елисеев

Хранилище удобно для хранения глобальных данных вроде пользователя. А остальное можно сохранять в локальном состоянии компонента через хук useState.

Ответить
Павел

Как всегда уровень подачи на высоте!)

Ответить
kashamamina

я согласен с вами по MVC, но как насчет того что даже Facebook на сайте своего Flux начиная со второго абзаца пишет об MVC совсем иначе, как об web-MVC или ADR? как это можно объяснить? и кстати, вы бы могли поделится источниками об "том самом MVC", не могу найти ничего толком о его изначальных идеях?

Ответить
Дмитрий Елисеев

В Wikipedia в разделе History есть сноска на оригинальную статью A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System с описанием:

The standard interaction cycle in the Model-View-Controller metaphor, then, is that the user takes some input action and the active controller notifies the model to change itself accordingly. The model carries out the prescribed operations, possibly changing its state, and broadcasts to its dependents (views and controllers) that it has changed, possibly telling them the nature of the change. Views can then inquire of the model about its new state, and update their display if necessary. Controllers may change their method of interaction depending on the new state of the model.

Оригинал позволяет представлениям по событию изменения модели самим запрашивать нужные данные из модели. И при желании позволяет контроллерам тоже подписаться на модель, чтобы потом при изменении состояния модели контроллер мог менять свою логику. То есть поток однонаправленный, но может дополняться обратными зависимостями. Контроллеру и представлению даётся больше свободы и самостоятельности для реализации всего процесса работы.

А Flux в этом смысле как раз проще и прямолинейнее, так как не предусматривает возможности создания таких обратных зависимостей. Там экшены и представления примитивные и однонаправленные. Вместо них процессом больше управляет обвязка и сам React.

Ответить
kashamamina

ООООО, спасибо, спасибо, это я и искал. А вот еще насчет однонаправленности, это же имеется ввиду что поток данных между view action и model идет в одном направлении, по сути по кругу и эта связь как-бы не обрывается, или же нет? Потому что мне говорили что однонаправленный это когда поток данных идет не по кругу, то есть как я понял что, например, есть как-бы вход, выход и все, то есть как в web-mvc, где запрос попадает на контроллер, он в свою очередь делает запрос в модель по надобности, принимает данные которые она вернет, далее передает их в view, тот формирует представления (некий ответ), отдает его контроллеру, а тот пользователю и все, поток оборвался по сути. Как будет правильнее?

Ответить
Дмитрий Елисеев

Однонаправленный - это когда информация перемещается только в одну сторону.

У нас представление передаёт данные только в контроллер, а контроллер только в модель:

   M
 ↑   ↓
C  ←  V

Если бы контроллер менял модель и правил представление, или представление сразу отправляло изменения в модель, то появились бы двунаправленные участки:

   M
 ↑   ↑↓
C  ⇔  V

То есть главное – это только направление.

Ответить
kashamamina

И при желании позволяет контроллерам тоже подписаться на модель, чтобы потом при изменении состояния модели контроллер мог менять свою логику.

А что под этим имеется ввиду, что контроллеры в зависимости от нового состояния модели могут менять свою логику. Это как? Ну то есть, что это по сути значит и как, в каких кейсах, может использоваться?

Ответить
Дмитрий Елисеев

Можно придумать какую-то ситуацию. Например, если в модели что-то выключилось, то контроллер может отписаться от системного таймера, чтобы экономить ресурсы.

Ответить
kashamamina

большое спасибо за ответы!

Ответить
S.Polessky
const favorite = (id) => {
   api.post(`/lots/${id}/favorite`).then(() => {
       dispatch(favoriteLot(id))
   })
}

Почему, кстати, мы функцию favorite записываем в const, а не используем function? Чтобы ограничить область видимости и не резервировать название?

Ответить
Дмитрий Елисеев

Разницы с точки зрения записи нет, если не учитывать отсутствие this внутри трелочных функций. Записываем так для однообразия с другими присваиваниями.

Ответить
S.Polessky

Модель данных - это название отдельной сущности (пример: Lot) или их группы (Lot, User, News)?

Ответить
Дмитрий Елисеев

Смотря как это сделано в проекте. Можно работать с каждой сущностью отдельно, а можно всё склеить в одну структуру.

Ответить
S.Polessky

Значит, в MVC все "равноправные партнеры" - View говорит что делать Controller > Controller говорит что делать Model > Model высылает директиву о своих изменениях, и View обязан измениться. Равноправное партнерство.

А в ADR "Action" - крутой перец. Он говорит что делать Model, и потом по результатам говорит как оформлять данные ADR. Диктатура Action.

Так, да?

Ответить
Дмитрий Елисеев

Примерно так. В ADR процессом управляет Action.

Ответить
S.Polessky

Гибриный MVC - это:

Отсылаем запрос на Back-end, который через Controller вносит изменения в Model, а та создаёт оповещение для Front-end через WebSocket.

Вопрос по схеме Гибридного MVC:

(36:33 - https://i.imgur.com/ANYww2N.png)

За что ответственный северный View в схеме "Гибридного MVC"? Или его просто надо удалить?

Ответить
Дмитрий Елисеев

В этом случае View понадобится только чтобы вернуть первоначальное представление по GET-запросу. А для POST-запроса он уже не нужен.

Ответить
S.Polessky

Интересно, а в каких кейсах нужен "Гибридный MVC", вместо "Web-MVC"? Web-MVC подход же самый популярный, я так понимаю?

Ответить
Дмитрий Елисеев

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

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Yandex
MailRu
GitHub
Google