Владимир, просто смысл самой задачи заключается в том чтобы удостовериться что бэк возвращает именно те данные , которые фронт ждет. То есть фактически проверять с фронта не было ли изменений на бэке
Правильно я понимаю что ответ должен быть "точным" ? Ну то есть могу ли я прописать тест, который говорил бы что должен вернуться объект с такими-то ключами, но не описывать полноценно что там внутри а описывать только тип возвращаемых данных?
Например что должен получить объект такой
{
user : string,
email: string
}
Владимир, спасибо! А можете объяснить в чем тогда смысл тестирования на моковых фетчах? Что именно тогда мы будем тестировать? И как тогда нам тестировать что бэк правильно отработал и вернул нужные данные для нас?
LEXA_JA, да , отличный вариант! Правда все оказалось ещё проще. Библиотека react-toastify. позволяет передать в toast айдишник. Если какой-то контейнер уже активирован, то следующий тост с таким-же айдишником не отработает и не будет показываться. А айдишником можно поставить текст ошибки чтобы не ставить костыльный статус ошибки. Осталось только оттестировать этот вариант и потом закрыть этот вопрос если все отработает корректно. Но ещё раз спасибо за советы! Очень пригодятся в будущем
Хм. Я хотел избежать хранения ошибки где либо так как думал о следующей ситуации - мы храним код ошибки и если эта ошибка хранится, то значит уже показывали и повторно выводить не будем. Но при этом вдруг пользователь сразу после данной ситуации попробует перейти куда-либо где он снова попадёт на такую ошибку - тогда она не будет визуализирована. А нам нужно это контролировать внутри компонента одного. Но я не знал о событии onClose в react-toastify. Попробую через него посмотреть что можно реализовать. Плюс я увидел что у них в доке есть контроль активных уже контейнеров , которые мы показывает. В то русло тоже хочу посмотреть что могу реализовать. Спасибо большое за совет!
Спасибо огромное за столь большой и подробный ответ! Позвольте ещё один небольшой вопрос. А как быть если мне нужно сохранить те часы , которые приходят с бэка? То есть не менять под часовой пояс пользователя , а оставить оригинальные 20:00 например
Допустим у меня есть один большой компонент и внутри него несколько других. Мне необходимо отслеживать ширину во всех компонентах. Лучше в каждый передавать свой хук или передать только в основной родительский и оттуда уже раскидывать его через пропсы в дочерние?
То есть при display: none и медиа запросах рендер этого элемента все равно бы происходил, верно?
И насчет хука. Имеете ввиду сделать единый хук, который просто переиспользовать в нужных компонентах? Наподобие того что рассказывают в документации к реакту про создание своего хука? Просто я не делал ранее свой собственный хук
Мне тоже больше нравится css вариант и использую я именно его. Просто возник вопрос теоретический. Будет ли происходить рендер элемента, на котором стоит условие по ширине экрана? Отрендериться ли он и потом скроется из дерева или вообще не будет создан?
Ну и как быстро работает передача пропса по сравнению с css стилями. Хочется на будущее понять что из этих двух вариантов быстрее на большом проекте
Надим Закиров, мне его сначала собрать нужно. У меня нет файла, я его создаю. Я отталкиваюсь от того что вижу в библиотеке , которая работает - собирает данные тега table и выдают уже excel файл с нужными данными. Внутри этой библиотеки есть подобное решение при создании element.href . Туда же, через base64 , как я понимаю кодируются данные будущего эксель файла.
twobomb, проблема в том что если я буду так кодировать, то уйдут некорректные данные для построения экселя. Грубо говоря если window.btoa(unescape(encodeURIComponent("текст"))) мне выдает 0YLQtdC60YHRgg== , то мне нужен способ , который бы делал и выдавал один в один тоже самое, но без использования unescape