Я может параноик, и надеюсь это не прозвучит обидно, но у меня ощущение, будто этот ответ был скопирован с ChatGPT :). Слишком уж похож стиль написания вывода.
А покажите примерный код. Если в родительском компоненте не используются данные стора, которые меняют дочерние компоненты, то перерендера не должно быть. Еще если useSelector возвращает не примитив а ссылку на объект, то важно следить за стабильностью этой ссылки, или использовать функции сравнения объектов во втором аргументе useSelector (передав, например, туда shallowEqual функцию, чтобы только при изменении корневых полей объекта происходило обновление компонента, а не при изменении ссылки на объект).
Не, у вас правда handleClickNext на каждый рендер создается новая, а т.к. эта переменная в зависимостях у эффекта, он вызывается и вызывает функцию findReposInex , а она в свою очередь меняет стейт через setCurrentRepos, после чего происходит перерендер и опять заново создается handleClickNext и вызывается эффект. И так вечно.
А мне кажется, это просто заблюренная картинка. В исходниках фигмы наверняка можно понять, сделано это через множественные градиенты (что вряд ли), либо же реально картинка с применением блюра в фигме.
Если ни то, ни другое, то нужно согласовывать с дизайнером, по какому принципу строится это изображение.
А компонент же тоже vue приложением рисуется? Если да, то по какому-то правилу основываясь на данных? ИМХО лучше по этому правилу и определять, нарисовался ли компонент, нежели пытаться искать его на странице.
А fullpage сильно тормознутая штука. Если есть возможность по поддержке браузеров, лучше использовать scroll-snap. У него неплохая поддержка, правда он дико забагованный местами, нужно внимательнее тестить.
У меня на macos из-за софта лоджитеч во время движения мыши все тормозит. Возможно дело в нем, можно попробовать закрыть его или удалить (если есть конечно).
Вряд ли это проблема в железке, стоит проверить на другом устройстве (хоть на android телефоне, если есть переходник).
PS: у меня та же самая мышь
не совсем так
div - это красный круг, у него никаких бордеров, просто заливка
before - первый бордер, без заливок, просто бордер
after - второй бордер, тоже без заливок, просто бордер
div важно делать не бордером, чтобы потом в этот круг можно было что-то положить, ведь в before/after вы не сможете другие элементы положить
По вашей реализации дам подсказку - нужно сделать так, чтобы after и before были этими самыми бордерами, а основной тег был красным кругом. border на самом теге не нужен
Ощущение, что такой вопрос был, с точно таким же бордером, и Ankhena в ответе дала несколько хороших советов по реализации (например с box-shadow). Но что-то не могу найти
NooBick, моей карме будет большой минус, если я просто скажу, куда это вставить. Вам лучше попытаться самим разобраться. Вот прекрасная дока https://ru.reactjs.org/docs/handling-events.html там сразу дается пример с событием onSubmit, тут аналогично. Но немного странно, что в первом блоке кода у вас this.props.go (а значит это класс), а во втором useState (а значит это хуки). Лучше стараться писать компоненты только либо на классах, либо на хуках (лучше на хуках, хуки теперь в основном развиваются в реакте).
mkone112, общего единого стандарта нет, но там где я работал, джуна от мидла отличал лишь опыт и самостоятельность. Имею ввиду, что джун делает те задачи, которые ему дали, не предлагая лучшего решения, и не декомпозируя задачи, в отличии от мидла. Сложно проявлять самостоятельность в решении проблем, если нет достаточного опыта.
