не можем
Извиняюсь, исправил
Демо должно работать?
чистенько, структура хорошая, код понятный. я бы взял
Миллион ошибок а нейминге)) То буквы лишние, то описки
а можно, пожалуйста, пример?
https://github.com/sergeevich-k/TheLifeGame/blob/187c3e75fcd52895d10197ea2cc609ea54ed6412/src/compoonents/Board/Board.js#L15 А чё, прям рефы через пропсы и работает? Я бы использовал пакет use-dynamic-refs. И prop-types заменить бы на typescript, а так нормас )
1) подскажите пожалуйста, я изучил use-dynamic-refs но не совсем понял зачем она нужна именно здесь. это нужно для улучшения читаемости кода ? просто она полезна, на сколько я понял, когда много рефов ОТ элементов нужно хранить, но в моем случае Реф используется чисто для хранения одной общей переменной между рендерами - "состояние мыши" чтоб знать не совсем понял почему тут будет лучше библиотека позволяющая упростить хранение рефов, когда их не нужно много. или я что то не правильно понял ?
Ок, я сначала неправильно понял назначение. передача ссылки на реф через props drilling, конечно, необычное решение (на эту переменную ссылается логика функции дочернего компонента - если ее не планируется кешировать с помщ useCallback, вроде, должно работать без багов, но на первый взгляд смотрится не айс)) Про нейминг комментировали выше - в целом верный подход именования is*, should*.. но читаемость проекта ещё и в том, чтоб логика "детей" не знала про логику "родителей" (я про нейминг пропсов) - так проект останется жизнеспособным дольше
> логика "детей" не знала про логику "родителей" можно, пожалуйста, один пример что бы я понял в каком направлении менять ? > если ее не планируется кешировать с помщ useCallback, я изучил useCallback,а разве не получается так что этому рефу безразлично будет ли useCallback или нет ? дочерний же общается с родительским не через пропсы а напрямую по ссылке на обьект-реф но если это считается не лучшей практикой то ок, уберу реф из дочернего
Обсуждают сегодня