мы в проекте используем это правило только как warn, для индикации возможных проблем.
Как показала практика, полностью отключив правило мы закрываем возможность понять почему мы его отключаем, поэтому лучше оставлю информирующий коммент)
мне кажется такое решение не сильно отличается от решения через ref, разве нет?
Реф это же ссылка на дом элемент, с предложенным вариантом выйдет похожий результат, нужно будет собрать сначала все элементы, а после получения ошибок, определить самый верхний и сделать к нему скролл.
Мой вопрос скорее не про ресурсоемкость решения, а про выборку этих самих элементов.
А как обрабатывать например такой кейс с таким подходом.
Есть страница на которой 2 компонента.
1. Лента со списком имен юзеров.
2. Селект со списком имен юзеров.
При первом заходе мы загружаем всех юзеров с бека в ленту (getUsers), показываем прелоадер в ленте пока грузим, потом отображаем.
При выборе селекта мы делаем отдельно повторный запрос (getUsers), чтобы получить обновленный список имен юзеров (их могло стать больше на беке, нужны актуальные данные в селекте). Но нам не нужно обновлять ленту юзеров и показывать прелоадрер в ленте, а только в селекте.
Получается что нужно дублировать сагу и кусок стора? т.к лента следит за состоянием getUsers loading (true/false) и селект следит тоже.
Возникает вопрос, если табы передаются как children в компонент tabs, то как в компоненте tabs определять какой children делать активным?
Сейчас я использую подход в котором пребираю children в tabs и дописываю дополнительный props active одному из детей (Tab), корректно ли так делать? или нет?
При редактировании child в tabs, приходится переписывать onClick в child, на такой
1. Время жизни токена хранится в самом токене. Токен поставляется бэкендом. Сооответственно если мы просрочим токен, и отправим запрос с ним на бек, то нас разлогинет.
2. Чтобы не было проблем с производительностью в отслеживании событий, есть подходы по их оптимизации, например throttling или debounce.
в axios есть возможность не проходить по редиректам? или например пройти и понять что был редирект?
в fetch есть флаг redirect: "manual" который позволяет не проходить, или есть тип request opaqueredirect после редиректа, т.к обработать итуации до и после можно
useDispatch
useSelector