з.ы. сталкиваюсь иногда с проблемой выхода из сна, если много всего было запущено, система просто теряет связь с программами и иногда только жесткий ребут спасает, т.к. приложения не удается корректно выгрузить. Но это скорее проблема софтовая, а не камня.
Докину в пользу М-камней - пишу фронт, при этом проекты приходят иной раз ОЧЕНЬ сильно нагруженные, в частности необходимость запускать докер с несколькими инстансами бэка, базы, редиса и прочей ерунды, прямое сравнение интела и м-ки в пользу м-ки (работаю на прошках). Основной бонус для меня - значительно меньший разогрев машины во время работы. На интеле приходилось пользоваться выносными клавой с мышью, бо пальцы просто вопили от перегрева. М1 в настоящий момент, проблем с выгрузом на лету и падением браузеров не встречал. Вкладок обычно штук 30-40 да еще и по нескольким виртуальным экранам раскиданы, не считая иде, докера и прочего хлама.
Помимо того что нужно использовать алиасы как таковые, важно знать, что алиасы для вебпака (или какой сборщик у вас) и алиасы для иде это разные вещи, и описывать их придется скорее всего в двух разных конфигах.
p.s. для ускорения разработки можно подключить какие-нить reach.tech или headless ui компоненты, которые дадут хорошую функциональность и не будут блочить борьбой со стилями, т.к. они без оформления из коробки.
Evgenii, есть платежки, которые позволяют работать в ифрейме. В частности best2pay. У ифрейма настраивается режим песочницы и только в путь.
Про ту же вкладку - иногда бизнес изначально не желает уводить клиента с сайта.
Михаил Смирнов
Обычно результат платежки ведет на целевую успеха или не успеха оплаты страницу сайта, откуда она была открыта, соответственно вполне можно пользоваться в том числе и localstorage для обмена данными с родительским окном. В частности платежки обычно передают информацию об успехе определенного заказа, его можно складировать и в локалстор и, если сайт на пхп, к примеру, просто на кнопку закрытия отправлять в бэк (и в случае успеха - закрывать вкладку). А в родительском окне подписаться на обновление localstorage или сокеты и запросы в бэк на статус заказа. По результату скрывать кнопку оплатить.
Финт с локалстором будет работать в том числе и если открывать в ифрейме. Основная проблема заключается в том, что раз уж платежка в ифрейме и целевые страницы вашего же сайта открывается там же - связи с родительским окном (в режиме песочницы) через js по умолчанию нет. Один из вариантов - использовать localstorage.
Мог ошибиться в пропсе. Но с чего бы это мне сочинять? столкнулся с проблемой, характерной исключительно для сафари актуальной версии.
Не часто, но это - баг. Адаптивность таким образом дизайнер нарисовал и сафари подставил ногу. Пришлось лечить старыми методами.
А зачем в useEffect в депсах висит map? На сколько я понял, этот хук должен реагировать только на location? Вы же один раз этот пропс тащите с бэка? А так - каждое изменение map будет у вас дергать этот useEffect.
Честно говоря, пагинация на фронте - это зло.
Логику ты реализовать можешь, даже вывести верстку по тем правилам, которые сам же и описал в вопросе.
Но вот вопрос - есть форум, там скажем больше 100000 сообщений. Как ты собираешься с этим работать?
Общепринятый подход - ты кидаешь запрос на бэк, просишь страницу номер Х и кол-во элементов на странице Y, получаешь данные для страницы, бэк тебе возвращает список элементов, номер страницы, общее кол-во страниц и элементов. Все расчеты по кол-ву должно лежать на бэке, у него минимальные задержки при работе с базой данных.
Но в качестве потренироваться - пиши все условия (считай на сколько страниц у тебя есть элементов в массиве, рассчитывай что ты выводишь в пагинации и проч). Просто это работа в стол.
Кука хранится в хранилище браузера, параметры хранения выставляешь на сервере, когда отправляешь ее клиенту. В дальнейшем она будет монтироваться браузером в каждый запрос к серверу, ты на сервере данные оттуда вытаскиваешь.
В httpOnly доступ из js не получишь, туда кладешь свой драгоценный токен авторизации, остальные поля не нужны (типа name, surname), их можно просто в респонс эндпойнта в JSON формате отдавать, фронт будет это читать и использовать.
JS при httpOnly куке про этот токен и про то, что бэку он нужен, вообще не знает. И это правильно. А бэк читает значения из заголовка и проверяет наличие данных из куки.
Честно говоря - сильно не хватает информации о том, что в итоге уходит на бэк и возвращается.
нужен скрин из вкладки network запроса и респонса.
Если у тебя запрос норм и респонс норм, тогда обкладывайся консолями, смотри что у тебя в переменных на каждом шаге.
Сейчас разговор ни о чем.
тогда скорее всего никак.
Проблема в лесенке - не срабатывающий антиалиасинг в некоторых браузерах и/или устройствах. Это может быть для экономии или оптимизации. Надо гуглить и пробовать разные рекомендации по этой теме. Есть еще сглаживание для шрифтов например...
