В предыдущем эпизоде мы придумали удобное хранилище состояния. А в этом сделаем работу с ним более удобнее, доработав экшены. Отделим декларацию действия от его реализации, сделав код компонентным и тестируемым. И после этого рассмотрим и подключим библиотеку Redux:
- 00:01:11 Проблемы невыделенного кода
- 00:02:28 Отписка слушателя
- 00:04:03 Постановка задачи
- 00:06:00 Вынесение конвертеров состояния
- 00:07:56 Обобщение сигнатур
- 00:09:45 Создание функции reducer
- 00:11:37 Написание reucer-а
- 00:13:35 Группировка action и params
- 00:15:24 Константы для имён действий
- 00:16:47 Добавление метода dispatch
- 00:19:20 Инъекция зависимости
- 00:20:54 Перенос инициализации состояния
- 00:22:19 Использование action creators
- 00:24:18 Комбинирование редьюсеров
- 00:27:22 Разбиение состояния
- 00:28:58 Универсальный combineReducers
- 00:30:11 Обзор результата
- 00:31:35 Подключение Redux
А в следующем эпизоде добавим интерактив и разберём настоящий MVC.
Скрытый контент (код, слайды, ...) для подписчиков.
Открыть →Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Выдохнул ) Да, это не 6 часов )
Скорее бы опять к бэкэнду вернулись - столько интересного в очереди стоит.
Да. Бэк это сила. 💪
уже не дождался сам изучил Bus
Спасибо :)
Ух ты - deworker перешел на React)))
Да, за пару недель постепенно перевели c Nuxt на Next.
а Nuxt, Next, зачем они нужны, чисто для SSR? и это сложно реализовать самому поверх Vue/React?
Да, это готовые сборки для SSR. Можно и самому сделать, но это сложнее.
а этот SSR, его главным преимуществом же является то что пользователю отдаётся сразу отрендеренная страница? то есть это по сути немного быстрее и полезно для SEO, чтобы роботы нормально индексировали эти страницы но актуально ли это сейчас, ведь, вроде, я слышал что сейчас поисковики уже нормально воспринимают spa и все хорошо индексируют тогда есть ли смысл в ssr, или же он полезен не только этим и есть ещё какие-то весомые преимущества?
Да, именно для этого.
Ходят слухи, что индексируют, но не все поисковики и не всегда правильно. И точно не индексируют различные анализаторы сайта.
То же преимущество производительности при открытия сложных страниц со смартфонов. Готовый HTML отобразить быстрее, чем разряжать аккумулятор и ждать результатов выполнения десятков Ajax-запросов по 3G или плохому LTE.
а то тот же next это готовая сборка для SSR на базе React, но он уже является полноценным фреймворком а не библиотекой с множеством не всегда нужного функционала, то есть намного громоздкие той же библиотеки
Да, SSR-версии - это уже полноценные фреймворки-сборки с уже настроенным маршрутизатором, куда сразу в папку pages можно добавлять компоненты, которые автоматически будут подхватываться как страницы-маршруты.
Спасибо Дмитрий, отличный урок, но раз пошла такая пьянка, может выскажите мнение о MOBx ? Случаи когда предыдущее состояние прямо вот нужно и необходимо, можно по пальцам пересчитать, а лишняя писанина совсем не радует, особенно если делаешь для заказчика, а не для себя, а MOBx сильно сокращает код и делает его более понятным.
Да, MOBx выигрывает в размере кода, взамен добавляя чуть больше магии. Но суть от этого не меняется.
Ясно, спасибо.
Супер! Спасибо за четкое изложение)
Дмитрий, а сделайте урок хотя бы теоретический по типу философии, о server side rendering, что это и зачем. Спасибо.
В примере с кодом в HTML-странице показать не получится, так как нужно будет всё запускать в NodeJS-сервере.
А вообще SSR нужен для того, чтобы при первом запросе с сервера возвращалась не пустая страница:
как у нас наполняемая уже потом в браузере по
ReactDOM.render(<App />, root)
, а как у классических сайтов сразу бы возвращалась страница со всем HTML-контентом:уже сгенерированным на сервере через
ReactDOMServer.renderToString(<App />)
.И уже на неё в браузере через
ReactDOM.hydrate(<App />, root)
подключался бы JavaScript.В итоге имеем и индексацию поисковыми системами как у классического сайта, и JS-интерактив.
Спасибо за ответ.
Подробнее ответил здесь
Зачем константы. Можно сразу же передавать ф-ции по названию или из объекта по ключу и избежать огромного switch - case
Да, можно. Но мы изначально ориентировались на пример Redux.
Не до конца понятна зона отвественности, обязанности Редюсера: он только вносит изменения в State, или ещё может вызывать определенные функции?
Давайте на примере:
На наше кукурзное поле прилетает ворона. Мы отправляем Action:
{type: "RAVEN_HERE", id: 25}
на Reducer.Какие права у Reducer? Варианты:
а) Reducer может запись в State данные о новой вороне, и(!) активировать функцию:
shootInRaven()
.б) Reducer может ТОЛЬКО записать в State данные о новой вороне. Чтобы вызвать
shootInRaven()
мы должны подписаться на Event изменения State, и уже в Listener вызывать данную функцию.Могут быть комбинированные экшены, которые могут запускать другие экшены. Это у нас будет в 10-ом эпизоде. Но надо следить чтобы всё не зациклилось.
Великолепный курс, как и все здесь. Начинающему - сложновато будет, но тому, кто уже что-то может, - в самый раз. Спасибо и продолжайте в том же духе!
Откуда взялось это слово - "целиковый". Разве слово "цельный" не передают сути?
Откуда берутся данные, которые идут в качестве аргументов в стрелочную функцию:
Например: тот же action. Он внутри каждого Reducer'а по отдельности же.
При вызове:
происходит:
То есть метод
dispatch
вstate
передаёт текущийthis.state
, а вaction
попадает именно этот результат функцииfavoriteLot(id)
, который мы ему передаём.То есть мы могли бы записать вызов так:
для большей наглядности.
Или войти через: