Огромная благодарность за урок, всё понятно и доступно. Считаю Вас одним из лучших авторов по программированию и web разработке в целом. Да прибудет с вами сила))
Михаил, спасибо за видео. Для меня это уже ваше третье по счету про RTK. Кратко, но достаточно, чтобы зацепиться. А дальше уже намного легче с официальными гайдами разбираться. Отличная подача материала!
кэширование, работающее из коробки, и запрос на получение всех данных при каждом удалении или добавлении выглядят очень стремно) Но, скорее всего, это все настраивается. Спасибо большое за видео!
"и запрос на получение всех данных при каждом удалении или добавлении", а как подругому? изменив данные на сервере их сразу же и нужно подгрузить, чтобы у пользователя произошли изменения
если что то сейчас достаточно в get-запрос написать: providesTags: ['Products'] а в post-запрос: invalidatesTags: ['Products'] - спасибо за уроки - максимально понятно
15:15 При использовании доп. параметров в endpoint'е лучше написать: "query: {limit = ""} => ({url: 'goods', params: {_limit: limit, и все остальные нужные параметры, если есть, тоже сюда, как ключ: значение}})". Это не только правильно с точки зрения RTK, но и делает код более читаемым 😉
Больше всего нравится такой стиль изложения. Ulbi tv тоже годные видосы снимает, но очень быстро все показывает и частенько приходится нажимать на паузу, чтобы понять что вообще происходит, а в твоих видео, пока ты печатаешь уже можно смысл уловить.
Привет. Присоединяюсь к поблагодарившим, в целом все четко, по полочкам, в удобно перевариваемой последовательности. Но хотелось бы уточнить, на 29:00 речь про то, что если кто-то в соседней комнате что-то удалит, то мы получим свежие данные. На сколько я понимаю, автоматом мы уже их не получим. RTK Query в нашем экземпляре приложения ничего не знает об операциях в чужом приложении.
Просто невероятно! Очень прошу вас на основе этого видно сделать бесконечную загрузку данных при скроле. На самом деле проблема не маленькая а решения на нее не так просто и найти адекватного именно с RTK query. Был бы очень благодарен.
26:13 это всё, что нужно знать про RTK Query "Мы сделали для вас новый крутой инструмент, который позволяет писать меньше кода, но выучите миллион новых синтаксисов под каждый конкретный случай". Это всё конечно здорово звучит, но ровно до тех пор, пока у вас простой CRUD, а не большое сложное приложение, где вы можете в респонсе синхронизировать много данных. На мой сугубо личный взгляд, связка redux-toolkit + классическая redux-saga + axios - это лучшая сборка для вашего проекта.
на многих ютуб гайдах часто вместо с rtk query еще и axios фигачат. есть ли реальный смысл аксиос юзать или rtk query самодостаточен? спс за видос, один из лучших сенсеев на ютубе
Не уверен, что после удаления или добавления объекта прямо настолько круто делать еще запрос на получение всех продуктов. Если объектов много, то они постоянно будут запрашиваться. Или это не так работает?
Спасибо автору за весь контент очень понятно и информативно. Такой вопрос RTK Quary это замена или альтернатива Thunk? просто по функционалу в RTK Quary больше возможностей и упрощений под капотом и его (как я понял) лучше использовать в компонентах, а Thunk более настраеваемая вещь которая работает в сугубо в слайсах. Как я понял если все упростить то в случаи: RTK Quary сначала грузиться компонент => идет запрос на сервер => выполняется логика компонента => меняется стейт в сторе redux . Thunk Сначала делаеться запрос на сервер => меняеться стейт в сторе => грузиться компонент => Выполняеться логика компонента Буду рад если скоректируете моё понимание об этих 2х расширениях, так как пока не могу понять что нужно и в какие моменты использовать и как их между собой связывать и нужно ли? Зарание спасибо.
Спасибо за видео!!! Как быть если нужно получить объект с сервера..., пользователь его редактирует и только потом делаем запрос на обновление, как в таком случае использовать RTK Query?
@@kawaikaino5277 ты прав, но это очень удобно. Можно смотреть внутренности в документации, но и она меняется постоянно) так что один глаз в доку, а другой на код)
Очень доступно! А можно эти получаемые данные диспачить в стейт, определенный в каком-либо слайсе, и по необходимости использовать? Или хуки RTK Query сами являются таким хранилищем, которое можно подключать и использовать в нужных местах приложения?
29:55 показать всплывашку после удаления как? у меня, почему-то после удаления обновляется страница 2 раза.. после первого раза она содержит и удалённый элемент и только после второго раза элемент исчезает с экрана.. но всплывашка получается выскакивает ДО того как удалённый элемент исчезнет.. логи: deletedCar {status: 200, data: {…}} всплывашка myCars**** [{…}] ----------- что это? откуда? car уже удалена! myCars**** []
Спасибо за обратную связь. По websocket пока не планирую. Просто потому, что серьёзно с ним не работал. Возможно на одном из проектов по работе он пригодится, тогда будет пища для видео. Сейчас квалификации не хватит.
Не понял, а что, в RTK Query, GET запросы можно делать только автоматически при рендере компонента? А что если мне нужно сделать GET запрос при клике на кнопку? RTK Query так может?
Может, через useLazyQuery. Такой хук имеет trigger, через него можно сделать fetch данных при клике на кнопку (по сути работает также, как и mutation).
Правильно ли я понял: мы когда получаем товары добавляем к ним тег Products, который содержит актуальную базу продуктов, а потом когда добавляем и удаляем говорим что этот тег стал инвалидным (invalidate - сделать неактуальным) и его надо актуализировать и потому идёт автоматический запрос?
спасибо!!!! Не понятно, как теперь обращаться к стору... А что если эти данные нужны в другом компоненте ? потом в третьем? или в редаксе.... раньше это можно было делать const { allPackets, } = store.getState(); а сейчас это делается через такой костыль..... const allPacketsData = allPackets.queries?.['getAllPackets("allPackets")']?.data; не подскажешь, как это можно реализовать по другому ?
Не надо обращаться к стору за содержимым, полученным через rtk query. Он предполагает истину на стороне сервера, и кэширует запросы. Поэтому правильный подход - это использовать один и тот же хук получения данных в разных компонентах. Если запрос недавно был совершен, он не будет повторен - мы сразу получим данные. Если прошло минимально установленное на кэширование время - данные возьмутся с сервера.
@@mishanep спасибо!!! ну тогда получается, в каждом компоненте делать вызов одного и тогоже хука, как то не очень ;) повторяешь один и тот же код каждый раз. А если данным, которые хранятся а другом слайсе в редаксе должны использовать запрос ртк? Как тогда туда их затянуть ?
@@АлександрЕрмолов-п2ь а когда мы вызываем useSelector на конкретный селектор в каждом компоненте - в чем разница? =) В redux devTools можно посмотреть как дерево стейта выглядит. А так, если нам для запроса нужны данные из другого слайса мы их получаем на уровне компонента и передаем в качестве параметра в хук.
Михаил подскажите пожалуйста, когда после каждой мутации я перезаписываю кэш (используя invalidatesTags) и сразу идёт запрос на повторное получение данных (query), как сильно это будет нагружать сервер?
Спасибо автору за ценную информацию. Подскажи пожалуйста, как мне создать и использовать хук для получения каких то товаров по slug. Slug берется из параметров url, то есть динамический. Я получаю этот параметр из url и как его пропихнуть в хук query? Желательно через useEffect, в котором будет привязка к slug, и внутри useEffect вызов для получения списка? Благодарю заранее, если конечно увидишь коммент)
Не кажется что все же есть проблема, в том что происходят дополнительные запросы и перерендер всего, допустим вы обновили какой-то список, как обычно делается: обновляете данные на UI , UI Отправляет запрос на обновление не важно как он просто передает данные в API, при положительном ответе просто по id или индесу обновляешь данные, на UI обновляется только тот маленький компонент к которому привязан елемент из списка. В RTK Query после обновления происходит перерендер всего, что связано с этим списком и к тому же еще происходит запрос дополнительный на сервер, при том что сервер уже до этого сказал, что ты обновил, и у тебя по факту есть уже данные новые, но мы все равно делаем запрос. А если посложней пример, у вас есть сущьность "profile" у этой сущности есть какие-то данные и привязана сущьность "services" - это сущность допустим большой массив который мы мапим где-то на UI, из "profile" мы берем какие-то данные и показываем допустим где-то в хедере имя пользовотеля и тд а хедер находится естествено в корне апп, получается мы хотим обновить одну запись в "services" , тогда ререндер будет всего париложения к тому же будет заново мапить "services", это разве не дорого? При удалении вместо того, что бы просто при положительном ответе с сервера, удалить запись по id или индексу в приложении, приложение будет делать запросы ненужные и ререндерить полностьюб,Не знаю Не знаю, не всё так хорошо как кажется на первый взгляд, как мне кажется.
А если апи поддерживает пагинацию и я в хук useGet...Query передаю номер следующей страницы и хочу, что бы данные с предыдущим запросом не исчезали, а к ним добавлялись данные из нового запроса (следующей страницы), то мне надо заводить отдельный слайс через createSlice для этого и хранить всё в сторе? Без создания слайса никак, да?
В конце была фраза про один источник истины, и все хранится на сервере. Я беккндщик и сейчас штурмую ртк. Хорошая практика в стейте хранить данные по пользователю?(Юзернейм, мыло итд) Вот у меня сейчас два эндпоинта, получение токена, и после кверифулфилда сразу диспатчится квери на получение пользователя через инитиате. Два эндпоинта через экстра подключены к своим слайсам. Можно ли назвать это оверхедом сохраняя пользователя в отдельном слайсе? Или пусть он в кеше хранится, а по необходимости/тайм-ауту инвалидировать его?
У меня было видео про клиентские компоненты nextjs 13+ и там я немного затрагивал тему использования стейт-менеджеров. По сути, в текущем варианте вы можете использовать редакс, как и прежде. Но только в клиентских компонентах.
Самое потрясающее и понятное объяснение RTK Query!
Такое видео должно быть в официальной документации!
Самые адекватные уроки на ютубе. Без воды, все четко понятно человеческим языком
Этот коментарий создан в качестве уважения автору и для продвижения его канала.
Этот ответ создан, чтобы поблагодарить автора комментария =)
Самое понятное и краткое объяснение. Обожаю автора, все нравится, от тембра голоса до логики объяснения, супер!
Очень круто и актуально, то что нужно было!!! еще бы с TS и тогда полный кайф был бы)
Эм, какой смысл сейчас вообще без ts делать ? Сейчас все начинают на ts делать , видео какое то неполное получаеться
в действительности, там всё легко типизируется. Пришлось бы dto описать, что заняло бы еще какое то время урока
Спасибо большое за урок! У тебя отлично получается объяснять не самые лёгкие вещи, не самым продвинутым юзерам)
Огромная благодарность за урок, всё понятно и доступно.
Считаю Вас одним из лучших авторов по программированию и web разработке в целом.
Да прибудет с вами сила))
Честное слово, это самое вменяемое объяснение данной темы! Огромнейшее спасибо!
Михаил, спасибо за видео. Для меня это уже ваше третье по счету про RTK. Кратко, но достаточно, чтобы зацепиться. А дальше уже намного легче с официальными гайдами разбираться. Отличная подача материала!
кэширование, работающее из коробки, и запрос на получение всех данных при каждом удалении или добавлении выглядят очень стремно)
Но, скорее всего, это все настраивается. Спасибо большое за видео!
"и запрос на получение всех данных при каждом удалении или добавлении", а как подругому?
изменив данные на сервере их сразу же и нужно подгрузить, чтобы у пользователя произошли изменения
@@REDH3ADd согласен, когда суть библиотеки это перенос состояния на бэк такой коммент выглядит как минимум забавно)
Автору браво. Это самое понятное обьяснение ртк квери что я только видел в рунете.
если что то сейчас достаточно в get-запрос написать: providesTags: ['Products'] а в post-запрос: invalidatesTags: ['Products'] - спасибо за уроки - максимально понятно
Огромное спасибо🥰
Теперь у меня заработало автообнобление
Спасибо большое!
раньше признавал только ulbi) Теперь + к нему еще и Миша) лайк оставил, комен оставил, видео лот корки до корки посмотрел) спасибо большое!
Михаил, спасибо вам за обучающие ролики! Всегда доступно и понятно!
i'm not understand your language but understand the whole video it's too simple and amazing.thanks for sharing
Вау! Хорош! И структура информации и подача мне нравится! Однозначно подписка!
Респект за усилия с которыми Вы доносите материал!
И правда, RTK Query - крутейший инструмент! Спасибо за разжеванное объяснение!
Как раз думал по этой проблеме, я фуллстэк разраб. Думал как связывать бд и редакс. Контент простой для понятия, автору большой респект ❤❤❤
Просто по божески объяснил! Моё величайшее почтение
Достаточно детально и ёмко изложено, очень легко вникать. Большое спасибо!
я присоединясь к множеству одобрильных отзывов, браво!
15:15 При использовании доп. параметров в endpoint'е лучше написать: "query: {limit = ""} => ({url: 'goods', params: {_limit: limit, и все остальные нужные параметры, если есть, тоже сюда, как ключ: значение}})". Это не только правильно с точки зрения RTK, но и делает код более читаемым 😉
Мишаня, ты прекрасно подаешь информацию, продолжай дальше просвещать нас!
спасибо, большое! объяснение на высшем уровне! желаю вам крепкого здоровье!
Спасибо большое вам за этот урок. Было очень понятно. Ставлю лайк ❤
Респект за уроки, одни из самых лучших на ютубе
Больше всего нравится такой стиль изложения. Ulbi tv тоже годные видосы снимает, но очень быстро все показывает и частенько приходится нажимать на паузу, чтобы понять что вообще происходит, а в твоих видео, пока ты печатаешь уже можно смысл уловить.
Максимально доступно, понятно и интересно. Спасибо, Михаил!!!
очень крутой инструмент и очень понятно рассказан. очень хотелось бы подробно изучить все возможности RTK Query.
Спасибо, Михаил за понятное объяснение!!!
Классная вещь!!!
Насколько же вы шикарно преподносите информацию❤
объясняете просто супер! все четко и понятно, спасибо!
Хорошее видео, спасибо автору!
Спасибо. Очень подробно и главное все понятно.
Спасибо за урок, доступный, понятный материал за короткое время, хорошая работа 💪💪💪👍👍👍
Да уж ашалеть, и по редакс тулкит, и по редакс квери и по материал юай всё по делу, без воды в лайв режиме, моё почтение и уважение сэр👊
Супер понятное и подробное объяснение!!! Спасибо!
Крутой вы, лайкнул, спасибо вам, желаю успехов!
Большое спасибо за отличное объяснение такой непростой вещи
Очень крутая штука!!! Только закончил пет проджект с этой фичей ! Спасибо актуальный контент!
Михаил, спасибо за труд
спасибо, отличный разбор темы!
Очень круто объяснил, спасибо!
Блин, как же это круто! Спасибо огромное! ОХх... )
Круто! сложное - простыми словами!
спасибо большое)больше про редакс тулкит, очень полезные знания
Хорошее объяснение! Понял! Спасибо!
очень классный и понятный урок, большое спасибо!
Очень хорошо объясняешь, очень нужные вещи, спасибо
Очень доходчиво объяснено!!!Спасибо!!!
Спасибо 👍🏻, после zustand начал понимать работу Redux, а дальше Redux toolkit там и до крольече норы можно дайте.
Привет. Присоединяюсь к поблагодарившим, в целом все четко, по полочкам, в удобно перевариваемой последовательности. Но хотелось бы уточнить, на 29:00 речь про то, что если кто-то в соседней комнате что-то удалит, то мы получим свежие данные. На сколько я понимаю, автоматом мы уже их не получим. RTK Query в нашем экземпляре приложения ничего не знает об операциях в чужом приложении.
Просто невероятно! Очень прошу вас на основе этого видно сделать бесконечную загрузку данных при скроле. На самом деле проблема не маленькая а решения на нее не так просто и найти адекватного именно с RTK query. Был бы очень благодарен.
супер объяснение, благодарю!!!
Спасибо вам, как раз с РТК работаю, буду внедрять!
Все это очень круто, единственное, пожалуйста, переключись на dark mode ))
Отличные гайды! Спасибо!
Спасибо за Вашу работу.
Этот комментарий создан в качестве уважения автору и для продвижения его канала.
Спасибо большое. Круто!
26:13 это всё, что нужно знать про RTK Query
"Мы сделали для вас новый крутой инструмент, который позволяет писать меньше кода, но выучите миллион новых синтаксисов под каждый конкретный случай".
Это всё конечно здорово звучит, но ровно до тех пор, пока у вас простой CRUD, а не большое сложное приложение, где вы можете в респонсе синхронизировать много данных.
На мой сугубо личный взгляд, связка redux-toolkit + классическая redux-saga + axios - это лучшая сборка для вашего проекта.
на многих ютуб гайдах часто вместо с rtk query еще и axios фигачат. есть ли реальный смысл аксиос юзать или rtk query самодостаточен? спс за видос, один из лучших сенсеев на ютубе
Не уверен, что после удаления или добавления объекта прямо настолько круто делать еще запрос на получение всех продуктов. Если объектов много, то они постоянно будут запрашиваться. Или это не так работает?
Самое лучшее объяснение из всех!
Спасибо автору за весь контент очень понятно и информативно.
Такой вопрос RTK Quary это замена или альтернатива Thunk?
просто по функционалу в RTK Quary больше возможностей и упрощений под капотом и его (как я понял) лучше использовать в компонентах, а Thunk более настраеваемая вещь которая работает в сугубо в слайсах.
Как я понял если все упростить то в случаи:
RTK Quary
сначала грузиться компонент => идет запрос на сервер => выполняется логика компонента => меняется стейт в сторе redux .
Thunk
Сначала делаеться запрос на сервер => меняеться стейт в сторе => грузиться компонент => Выполняеться логика компонента
Буду рад если скоректируете моё понимание об этих 2х расширениях, так как пока не могу понять что нужно и в какие моменты использовать и как их между собой связывать и нужно ли?
Зарание спасибо.
Спасибо за видео!!!
Как быть если нужно получить объект с сервера..., пользователь его редактирует и только потом делаем запрос на обновление, как в таком случае использовать RTK Query?
Спасибо за видео!
Крутой видос, спасибо!
Гранд мерси. Что значит большое спасибо )
Спасибо. Хорошее видео.
Капец как удобно! Правда придётся многое переписывать))
Все прячется под капот, иногда мне кажется что это является проблемой
@@kawaikaino5277 ты прав, но это очень удобно. Можно смотреть внутренности в документации, но и она меняется постоянно) так что один глаз в доку, а другой на код)
Михаил, а какой метод получения данных через api предпочтительнее? CreateAsyncThunk или RTK Query?
Класс! Суперкруто!
Очень доступно!
А можно эти получаемые данные диспачить в стейт, определенный в каком-либо слайсе, и по необходимости использовать? Или хуки RTK Query сами являются таким хранилищем, которое можно подключать и использовать в нужных местах приложения?
тоже интересно
привет, узнал? что то у меня не получается диспатчить
29:55 показать всплывашку после удаления как? у меня, почему-то после удаления обновляется страница 2 раза.. после первого раза она содержит и удалённый элемент и только после второго раза элемент исчезает с экрана.. но всплывашка получается выскакивает ДО того как удалённый элемент исчезнет..
логи:
deletedCar {status: 200, data: {…}}
всплывашка
myCars**** [{…}] ----------- что это? откуда? car уже удалена!
myCars**** []
Вопрос.. как данные доставать селектором? или достаточно просто извлекать хук в нужном компоненте и уже дальше работать?
18:38 - Говоря об айди, недавно узнал, что в RTK еще есть nanoid() который тоже можно импортировать для создания ID
Очень круто!! Спасибо за такую качественную работу!!!Можно попросить сделать видосик связки rtk querry и websocket?
Спасибо за обратную связь. По websocket пока не планирую. Просто потому, что серьёзно с ним не работал. Возможно на одном из проектов по работе он пригодится, тогда будет пища для видео. Сейчас квалификации не хватит.
почему у меня не показывает то что на порте 3001/goods находится, все установил но почему то не выходит
спасибо!
🎉🎉🎉🎉 спасибо, подскажите как создать по SOLID, class который делает базовый крад, и от него можно отнаследоваться
Кааааайф! Спасибо!
Не понял, а что, в RTK Query, GET запросы можно делать только автоматически при рендере компонента? А что если мне нужно сделать GET запрос при клике на кнопку? RTK Query так может?
Может, через useLazyQuery. Такой хук имеет trigger, через него можно сделать fetch данных при клике на кнопку (по сути работает также, как и mutation).
@@Acmuddi Спасибо. Попробую.
Правильно ли я понял: мы когда получаем товары добавляем к ним тег Products, который содержит актуальную базу продуктов, а потом когда добавляем и удаляем говорим что этот тег стал инвалидным (invalidate - сделать неактуальным) и его надо актуализировать и потому идёт автоматический запрос?
спасибо!!!!
Не понятно, как теперь обращаться к стору... А что если эти данные нужны в другом компоненте ? потом в третьем? или в редаксе....
раньше это можно было делать
const {
allPackets,
} = store.getState();
а сейчас это делается через такой костыль.....
const allPacketsData = allPackets.queries?.['getAllPackets("allPackets")']?.data;
не подскажешь, как это можно реализовать по другому ?
Не надо обращаться к стору за содержимым, полученным через rtk query. Он предполагает истину на стороне сервера, и кэширует запросы. Поэтому правильный подход - это использовать один и тот же хук получения данных в разных компонентах. Если запрос недавно был совершен, он не будет повторен - мы сразу получим данные. Если прошло минимально установленное на кэширование время - данные возьмутся с сервера.
@@mishanep спасибо!!! ну тогда получается, в каждом компоненте делать вызов одного и тогоже хука, как то не очень ;) повторяешь один и тот же код каждый раз. А если данным, которые хранятся а другом слайсе в редаксе должны использовать запрос ртк? Как тогда туда их затянуть ?
@@АлександрЕрмолов-п2ь а когда мы вызываем useSelector на конкретный селектор в каждом компоненте - в чем разница? =)
В redux devTools можно посмотреть как дерево стейта выглядит.
А так, если нам для запроса нужны данные из другого слайса мы их получаем на уровне компонента и передаем в качестве параметра в хук.
Михаил подскажите пожалуйста, когда после каждой мутации я перезаписываю кэш (используя invalidatesTags) и сразу идёт запрос на повторное получение данных (query), как сильно это будет нагружать сервер?
круто
остальные видео были с типизацией, это забыли ?
Man you are the best!
Круто!!!
Спасибо 👍🏿
Михаил, спасибо!! Пушка, огонь, пожар!
nice one,keep doing that!
Спасибо автору за ценную информацию.
Подскажи пожалуйста, как мне создать и использовать хук для получения каких то товаров по slug. Slug берется из параметров url, то есть динамический. Я получаю этот параметр из url и как его пропихнуть в хук query? Желательно через useEffect, в котором будет привязка к slug, и внутри useEffect вызов для получения списка?
Благодарю заранее, если конечно увидишь коммент)
Не кажется что все же есть проблема, в том что происходят дополнительные запросы и перерендер всего, допустим вы обновили какой-то список, как обычно делается: обновляете данные на UI , UI Отправляет запрос на обновление не важно как он просто передает данные в API, при положительном ответе просто по id или индесу обновляешь данные, на UI обновляется только тот маленький компонент к которому привязан елемент из списка. В RTK Query после обновления происходит перерендер всего, что связано с этим списком и к тому же еще происходит запрос дополнительный на сервер, при том что сервер уже до этого сказал, что ты обновил, и у тебя по факту есть уже данные новые, но мы все равно делаем запрос. А если посложней пример, у вас есть сущьность "profile" у этой сущности есть какие-то данные и привязана сущьность "services" - это сущность допустим большой массив который мы мапим где-то на UI, из "profile" мы берем какие-то данные и показываем допустим где-то в хедере имя пользовотеля и тд а хедер находится естествено в корне апп, получается мы хотим обновить одну запись в "services" , тогда ререндер будет всего париложения к тому же будет заново мапить "services", это разве не дорого? При удалении вместо того, что бы просто при положительном ответе с сервера, удалить запись по id или индексу в приложении, приложение будет делать запросы ненужные и ререндерить полностьюб,Не знаю Не знаю, не всё так хорошо как кажется на первый взгляд, как мне кажется.
Это реакт, он всегда ререндерит при изменении состояния
@@myrichstory ну вроде как он не всё приложение перендэривает , а только тот компонент в котором изменились состояния
Преждевременная оптимизация зло, имхо. Ну и по-настоящему дорого перерисовывать ui, а перерендер сам по себе не такая тяжелая операция.
А если апи поддерживает пагинацию и я в хук useGet...Query передаю номер следующей страницы и хочу, что бы данные с предыдущим запросом не исчезали, а к ним добавлялись данные из нового запроса (следующей страницы), то мне надо заводить отдельный слайс через createSlice для этого и хранить всё в сторе? Без создания слайса никак, да?
В конце была фраза про один источник истины, и все хранится на сервере. Я беккндщик и сейчас штурмую ртк. Хорошая практика в стейте хранить данные по пользователю?(Юзернейм, мыло итд)
Вот у меня сейчас два эндпоинта, получение токена, и после кверифулфилда сразу диспатчится квери на получение пользователя через инитиате. Два эндпоинта через экстра подключены к своим слайсам. Можно ли назвать это оверхедом сохраняя пользователя в отдельном слайсе? Или пусть он в кеше хранится, а по необходимости/тайм-ауту инвалидировать его?
Спасибо за видео. Будет ли что то по state в nextjs13+, и вообще имеет ли смысл это использовать в nextjs, или там есть другие методики?
У меня было видео про клиентские компоненты nextjs 13+ и там я немного затрагивал тему использования стейт-менеджеров. По сути, в текущем варианте вы можете использовать редакс, как и прежде. Но только в клиентских компонентах.
Все понятно. В ученики возьмете?