Когда мы разобрались с действиями пришло время добавить приложению интерактивность. Для этого сделаем полноценные кнопки добавления лотов в избранное. И на этом примере разберём архитектуру 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-ов.
Скрытый контент (код, слайды, ...) для подписчиков.
Открыть →Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо.
Спасибо
Дмитрий, во первых, конечно же спасибо. А вопрос такой. Вы предполагаете использовать все же Редакс для хранения состояния? Как то складывается ощущение что сейчас в тренде Хуки, и будущее за ними. И еще вопрос. Будете какую либо UI библиотеку использовать в проекте аукциона? Ну типа material-ui.
Хранилище удобно для хранения глобальных данных вроде пользователя. А остальное можно сохранять в локальном состоянии компонента через хук
useState
.Как всегда уровень подачи на высоте!)
я согласен с вами по 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 с описанием:
Оригинал позволяет представлениям по событию изменения модели самим запрашивать нужные данные из модели. И при желании позволяет контроллерам тоже подписаться на модель, чтобы потом при изменении состояния модели контроллер мог менять свою логику. То есть поток однонаправленный, но может дополняться обратными зависимостями. Контроллеру и представлению даётся больше свободы и самостоятельности для реализации всего процесса работы.
А Flux в этом смысле как раз проще и прямолинейнее, так как не предусматривает возможности создания таких обратных зависимостей. Там экшены и представления примитивные и однонаправленные. Вместо них процессом больше управляет обвязка и сам React.
ООООО, спасибо, спасибо, это я и искал. А вот еще насчет однонаправленности, это же имеется ввиду что поток данных между view action и model идет в одном направлении, по сути по кругу и эта связь как-бы не обрывается, или же нет? Потому что мне говорили что однонаправленный это когда поток данных идет не по кругу, то есть как я понял что, например, есть как-бы вход, выход и все, то есть как в web-mvc, где запрос попадает на контроллер, он в свою очередь делает запрос в модель по надобности, принимает данные которые она вернет, далее передает их в view, тот формирует представления (некий ответ), отдает его контроллеру, а тот пользователю и все, поток оборвался по сути. Как будет правильнее?
Однонаправленный - это когда информация перемещается только в одну сторону.
У нас представление передаёт данные только в контроллер, а контроллер только в модель:
Если бы контроллер менял модель и правил представление, или представление сразу отправляло изменения в модель, то появились бы двунаправленные участки:
То есть главное – это только направление.
А что под этим имеется ввиду, что контроллеры в зависимости от нового состояния модели могут менять свою логику. Это как? Ну то есть, что это по сути значит и как, в каких кейсах, может использоваться?
Можно придумать какую-то ситуацию. Например, если в модели что-то выключилось, то контроллер может отписаться от системного таймера, чтобы экономить ресурсы.
большое спасибо за ответы!
Почему, кстати, мы функцию favorite записываем в const, а не используем function? Чтобы ограничить область видимости и не резервировать название?
Разницы с точки зрения записи нет, если не учитывать отсутствие this внутри трелочных функций. Записываем так для однообразия с другими присваиваниями.
Модель данных - это название отдельной сущности (пример: Lot) или их группы (Lot, User, News)?
Смотря как это сделано в проекте. Можно работать с каждой сущностью отдельно, а можно всё склеить в одну структуру.
Значит, в MVC все "равноправные партнеры" - View говорит что делать Controller > Controller говорит что делать Model > Model высылает директиву о своих изменениях, и View обязан измениться. Равноправное партнерство.
А в ADR "Action" - крутой перец. Он говорит что делать Model, и потом по результатам говорит как оформлять данные ADR. Диктатура Action.
Так, да?
Примерно так. В ADR процессом управляет Action.
Гибриный MVC - это:
Вопрос по схеме Гибридного MVC:
(36:33 - https://i.imgur.com/ANYww2N.png)
За что ответственный северный View в схеме "Гибридного MVC"? Или его просто надо удалить?
В этом случае View понадобится только чтобы вернуть первоначальное представление по GET-запросу. А для POST-запроса он уже не нужен.
Интересно, а в каких кейсах нужен "Гибридный MVC", вместо "Web-MVC"? Web-MVC подход же самый популярный, я так понимаю?
Во всех таких же сайтах, где новые данные в реальном времени приходят с сервера через WebSocket.
Или войти через: