Предзагрузка данных через роутинг
ฝัง
- เผยแพร่เมื่อ 2 ต.ค. 2024
- Осенью 2022 года React Router научился делать асинхронные запросы на сервер при переходах между SPA страницами. Разбираемся как это можно сделать.
Код из видео github.com/mic...
Мои курсы по вебу с купонами:
✅ mishanep.com/
📢 Поддержка канала:
/ mishanep
www.tinkoff.ru...
paypal.me/mish...
Как по мне, Роутер слишком много на себя пытается взять. Кастомный хук по получению данных гораздо легче по написанию, понимаю, скорости загрузки...
Ахренеть! Я не успеваю за всем этим фронтэндом) Спасибо!
Присоединяюсь. Ток к одному привык уже новое
Век живи, век учись
Быть разрабом зашибись
Ваш канал сокровище для Junior dev
И не только для джуна :)
@@raufhashimov241 сильно сомневаюсь, что НЕ джун станет смотреть ролик по новой фиче, вместо того-чтобы открыть оф доку )
@@threehundredbucks3212 станет)
Я два выпуска назад попросил Михаила рассказать про это обновление и он меня услышал)
Спасибо большое за такое полезное видео!)
Очень интересное видео! Спасибо за курс по v6 реакт роутеру!)
Не знаю насколько это нужно. Геморроя только добавили. Будет ли этот функционал кто-то реально использовать и переписывать все - неизвестно
Спасибо, очень своевременное для меня видео)
Спасибо за Ваши видео
Спасибо за разбор новых возможностей. Пользоваться я этим не буду. Новый синтаксис никакой пользы не несет
Такой подход очень ускоряет загрузку!🥰
И что это дало? Лишь бы было.
Основой принцип реакта - декомпозиция.
И когда встретишь это на проекте после чувака который любит декомпозировать декомпозированное, не потеряешься 😁
на мой взгляд в случае с использованием с defer получается какое то трудно читаемое нагромождение кода всего лишь для того, что бы показать компонент Loader.
почему бы для этой задачи не сделать хук и использовать его вроде: const { data, loading, error } = useFetch("...") ?
import {useCallback, useState} from 'react';
const useRequest = (promise: (...args: TParams) => Promise) => {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
const run = useCallback((...args: TParams) => {
setData(null);
setLoading(true);
setError(null);
promise(...args)
.then((response) => {
setData(response);
setError(null);
})
.catch((error: Error) => {
setData(null);
setError(error.message);
})
.finally(() => {
setLoading(false);
});
}, [promise]);
return {data, loading, error, run};
};
export default useRequest;
ох да запутаться можно.Пока одно выучишь, другое учить надо. И не понятно что на интервью спросят.Поэтому учим все подряд
на самом деле теперь v6.4 очень похожа на remix, в плане всех этих лоадеров, Form и т.д.
в теории это может полностью изменить подход к разработке некоторых приложений
хочется еще больше видео про react-router-dom v6.4!
судя по странице ReactRouter там справа вверху прям отсылка идет к Remix, так что вполне вероятно
Это и есть remix
Если внимательно посмотреть на имена авторов того и другого, то всё станет понятно ;)
Автор, скажите что такое "эндерфугнансы " на 19:18 (по таймлайну) ?
😄😄😄
Звучит смешно. Переслушал несколько раз и сам не пойму)) Ума не приложу откуда вылезло))
@@mishanep да и пофиг, все равно ты молодец😃
Можно ещё роликов по новой версии роутера?)) Там линки обновили с ними немного не ясно(
Да роутер многое на себя забирает из функционала, не думаю что многие будут этим пользоваться, скорее тем что привычнее
Я может что упустил, но в чем преимущество перед просто загрузкой контента через useEffect при переходе на страничку?
тот же вопрос.
я храню состояние в recoil
без перезагрузки страницы - ранее подгруженные данные открываются мнгновенно
фишка - дрочево ради дрочева
@@exsterx Согласен, ненужный гемор. Может это как-то влияет на производительность, что навряд ли... В общем, ненужная фишка
useEffect триггерит сайд-эффекты после рендера.
@@d0paminer раскройте подробнее, что вы имеете ввиду
@@exsterx Ну как минимум один дополнительный draw call
Здорово, очень полезная инфа и подача отличная! Спасибо!
Спасибо огромное за то, что Вы находитесь на острие технологий front-end!
Супер
для тех, кто не понимает, зачем нужен loader:
- без использования loader - сначала загружается компонент, потом после его рендера начинается загрузка данных в useEffect.
- с использованием loader - компонент и данные загружаются параллельно.
Но в таком случае отстутсвует lazy loading и клиент не видит ничего,немного не понятен плюс этого подхода,кроме того что не подтягиваются хуки реакта
Просто прописываешь if (!data) return null и не паришься насчёт лишнего рендера (выполнения функции компонента)
Про try catch не забываем
Подскажите пожалуйста. Если работать не через Route, а через массив объектов, то как делать редирект, например, по клику на кнопку. Ведь useNavigate, работает только с route
Подскажите, а как в переменную router передавать дополнительные параметры. Допустим я хочу передать в пропс одного из компонентов вложенных в router, состояние, которое создается хуком, но, так как хуки можно создавать только внутри компонентов (в данном случае внутри App), а router является внешней константой, то при передачи ее в RouteProvider, я никак этого сделать не смогу. Т.е. мне нужно создавать router уже внутри компонента App, чтобы передавать в пропсы состояния сделанные с помощью хуков, т.е. других вариантов нет?
Расскажите, пожалуйста, как писать вложенные роутеры по версии React Router 6.4 с помощью createBrowserRouter
лично я в children роутах ещё одни чилдрены делаю и outlet-ом выбираю что где отрисовывать, возможно это не правильно, но оно работает, я буквально сегодня проверял.
В крайнем случае почитай доку
@@НікітаКорчемний-г4ч спасибо
{request,params} выдает ошибку, Unhandled Thrown Error!
_ref is undefined
делал все по видео!Что это может быть?
Ну это еще тот бубен. Ничего нового данные изменения не принесли, только опять проблемы с новой стандартизацией и структурой проекта. Как по мне ничего лучшего чем ReactQuery или же Redux + RTKQuery не придумали. Я думаю что в будущем данная фишка не получит своей популярности, и будет просто как заглушка в библиотеке
Не много не понимаю какие плюсы дает этот метод предзаргрузки, да я сам когда то думал, а почему нельза передавать какие то данные по роутер после клика, всеравно под скелетом у нас используеться useContext , но разработчики что-то перемудрили
Чем тогда отличается загрузка постов через useEffect и defer. Ведь и там и там можно показывать лоадер, отличается только реализация
Создатели библиотеки с роутингом просто предложили нам разделить логику получения и потребления данных.
@@mishanep Понял, спасибо за ответ)
Здравствуйте Михаил. Как создать бесконечный роутер?
а можно ли подход с роутер лоадером соеденить с редакс тулкитом??
Хороший урок, очень ждал продолжения курса
Спасибо! Буду следить за каналом, чтобы следить за новинками)
Уроки супер, но расскажи как организовать проект вместе с отдельным npm пакетом в котором находятся компоненты и импортируются в проект
Шикарное видео!
Как совместить это с reduxjs/toolkit, если мы обычно в toolkit вызывали асинхронную функцию через createAsyncThunk и через dispatch вызывали нужный нам reducer и записывали данные в state, а уже через redux-react используя useSelector передавали данные? Как я понял, сейчас мы данные получаем через useLoaderData помимо reduxjs/toolkit
Лучше не надо совмещать, обычно редакс нужен для управления состоянием каких-то больших данных, а предварительная загрузка react-router-dom для получения и отрисовки небольших.
Ну а вообще для больших проектов данная фича выглядит как оверхед, ибо редакс или что-нибудь другое для state manage (например, react-query) прекрасно справиться без помощи библиотеки, которая в первую очередь нужна для роутинг, а не для предзагрузки
Пример понятный но не продакшн) Покажите плз пример с RTK Query)
Так это же два разных подхода. Может быть со временем другие библиотеки предложат нам интеграции под возможности роутинга, пока она сырая.
@@mishanep Ну пока это первый заход "быть похожим на ангуляр" ну наконец то))) Ток в ангуляре можно было в резолвере сервисы подсосать. Это же тема не только для резолвинга данных, но еще и гвардинг доступов.
Я вижу проблему в том, что нет четких паттернов "как делаем", просто сделали и в путь) Ну, будем вырабатывать
В продакшене ведь чаще всего next
@@redhook777 1) причем тут ssr 2) "чаще всего" это где? крупняк редко его использует, чаще свое. и большинство SPA это внутрянка где ssr не нужен
А есть ли кэширование в данной версии роутера?
Подскажите, дружит ли React Router Dom с Electron?
У меня пока не было опыта работы с Electron.
Спасибо, очень своевременное для меня видео)
Как это будет работать с redux? Приходящие данные надо будет через стор обрабатывать?
Здесь могут быть разные сценарии поведения. В базовом варианте можно обойтись без складывания в стор. Здесь скорее вопрос, как избежать повторных запросов. На данной стадии вариантов кэширования из коробки не видно. Как подружить с лоадер с редаксом - вопрос, я пока не пробовал =)
Думаю если вам не нужны эти будут данные в другом компоненте. То их не стоит пробрасывать в стор redux. Бывает ситуации когда вам надо только получить и отрисовать данные и больше не где не использовать. Пока всё лишь предположение. Но всё равно очень полезный инструмент. Надо пробовать использовать в проекте.
Add text 12:44
Интересно, а если без defer, то как отрисовать лоадер на зависшей (пока данные грузятся) странице, с которой идет переход. Чтобы люди понимали, что нажатие на кнопку/ссылку сработало и что-то делается.
useNavigation там есть хук и у него состояние есть. Ну тоесть используем так const navigation = useNavigation(). И там уже цепляемся navigation.state === 'loadiing и рисуем что надо
Михаил, контент потрясающий
Очень круто. Спасибо за контент.
Отличная декомпозиция 🤠
Спасибо за видео) Подскажите, пожалуйста, какая у вас тема стоит?)
Codesandbox
Подскажите этот курс еще актуален?
Видео свежее, так что актуально. Но зависит от того, какую версию библиотеки вы в своем приложении используете. Там есть различия между версией 5, 6 и 6.4. В рамках плейлиста разбирается 6-я версия и последние дополнения, начиная с 6.4.
На 23:15 вы не писали return defer ({...}), он обезателен или можно обойтись await-ом в return-e
Интересно, вы уже досмотрели до конца, или всё ещё ждёте ответа? :)
@@The14Some1 хаххаха смешно))досмотрел до конца )забыл удалить коментарий
А возможно ли использовать useLoaderData в typescript? А то я пробую, а оно ругается на типы. В документации react-router-dom ничего не нашел об этом (ну или плохо искал :) )
В файлах декларации возвращаемый тип для этого хука идет как unknown. Поэтому, по логике, надо подготовить свой тип и указать его.
const data = useLoaderData() as MyType
@@mishanep Спасибо очень помог ваш ответ !)))
Он Гений
Супер. Спасибо большое
Подскажите как тема в VS называется ?
CodeSandbox
спасибо!
как раз когда реакт получает новый нативный хук use
А если заново надо получить данные?
перегружать компонент🤔
@@nikitasafonkin3077 useRevalidate()
Если вы использовали angular, то расскажите почему react лучше? Ну кроме как простоты и количества вакансий. Помоему ангулар куда логичнее. верстка от логики отдельно, модульный подход. Есть сервисы. Компоненты верстать может верстальщик, без знаний js/ts. Все есть из коробки, и никаких там а мы на проэкте используем мобх, или еще чего.
Хотя и простота тоже такое.... если взять ts, rxjs, redux(и всякий другой зоопарк), webpack, то тоже получается не так уж и просто.
Просто учу angular. Мне нравится. Все из коробки. нормальный ооп. но вакансий на него значительно меньше. Вот думаю не зря ли его осваиваю? Хотя посмотрел в сторону реакт. Какая-я то ерунда и все вперемешку.
Я не работал с Ангуляром. Касаемо Реакта, то здесь от проекта надо плясать. Не каждый проект нуждается в роутинге на стороне клиента, не всегда нужен Redux и его аналоги, многие проекты спокойно обходятся и без ts, что удешевляет разработку и снижает порог входа.
В ангуляре зачастую ориентироваться сложнее, сам rxjs тоже весьма неприятная и сложная штука. На реакте в целом многие моменты делаются гораздо проще, на реакте больше выбор библиотек, на реакте лучше можно контролировать ререндеры. Да и он банально легче и меньше. Это его основные плюсы.
У ангуляра, то что многое с коробки и то, что в модульном подходе код выглядит красиво, правда до первого взаимодействия с rxjs)))
Реакт даёт просто функцию, которая возвращает html и если возвращает то же, что и в прошлый раз - оптимизирует
Под капотом ангуляра непонятно что, много декларативности и нужно запоминать какие-то решения тк так придумали разработчики
Любой чел, знающий js, на реакт за день пересядет, а вот на ангуляр врятли
Ничем реакт не лучше. Инструмент всегда хорош, когда он в правильных руках. Реакт это библиотека, и его нужно уметь готовить. Ангуляр это фреймворк, свободы чуть меньше чем с реактом в плане композиции приложения и от этого код должен быть выше качеством, чем то что пишут на реакте.
Реакт просто популярней ангуляра, поэтому его выбирают чаще, от того и вакансий больше. Мало где можно встретить хороший код на реакте как раз из-за того что библиотека не ограничивает разраба ни в чем, кроме не сложных правил написания хуков. Если это большая компания, вероятно, у них есть деньги нанять программистов, если это стартап или средняя компания то, вероятно, они уже наняли "реакт разработчиков", а не программистов. Так что, если хотите поскорее на работу, берите реакт и вперед, если уже освоили реакт попробуйте ангуляр.
@@denissaripov7130 Блин, а тут, типа, придуманные разработчиками решения не нужно запоминать? Вот, мы прям сейчас обсуждаем последнюю версию роутера, который уже в третий раз значительно меняет парадигму своей внутрянки.
У меня уже голова идёт кругом от редакса, редакс-квери, редакс-санк, ртк-квери и роутера разных версий.
компонент уже стал каким то грязным и похоже на страницу php с ajax подгрузкой где нужно )
Михаил, а вы не поделитесь статейкой где откопали такой способ получения данных, или копались в документации? очень интересно, круто что технология не стоит на месте
Изначально я узнал об этом в их release notes, которыми библиотека поделилась ещё на стадии беты. А дальше через документацию.
Берите на заметку классный хук, на подобии useFetch, который поддерживает параметры и гораздо легче всей этой дичи с React router.
import {useCallback, useState} from 'react';
const useRequest = (promise: (...args: TParams) => Promise) => {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
const run = useCallback((...args: TParams) => {
setData(null);
setLoading(true);
setError(null);
promise(...args)
.then((response) => {
setData(response);
setError(null);
})
.catch((error: Error) => {
setData(null);
setError(error.message);
})
.finally(() => {
setLoading(false);
});
}, [promise]);
return {data, loading, error, run};
};
export default useRequest;
спасибо за актуальную инфу, скажи а почему ты не используешь стандартную запись export default ComponentName ?
Иногда использую и экспорт по умолчанию. Не согласен, что это стандартная запись. Многие библиотеки в качестве стандарта как раз используют именованный экспорт. Но для проекта это вопрос привычки и соглашений внутри команды.
ну и есть смысл убирать юзстейт и прочие для замены их на роутинг, он что жрет меньше памяти? или это просто альтернативный подход?
Здесь скорее история не про память, а про разные уровни абстракции. У нас, к сожалению или может быть к счастью, слишком много вариантов делания одного и того же. Касаемо производительности я не замерял, не отвечу. Но в теории должно быть быстрее.
Какой редактор?
vs code