GET /v1/users/:id - это плохо! в списке запросов инструментов браузера в строке будет показан одинокий нечитабельный айдишник, а полный путь с методом отображается только по дополнительному клику в отдельной вкладке .
Нет, я не хочу изменяя ref.current заставлять компоненту ререндерится.
Мне не нравится решение проблемы, которое предложил автор. Хук переписан так, что с наскоку непонятно, что в нем происходит, приходится вчитываться, а я это не люблю.
Я бы предложил решать проблему все таки через ссылку и первую реализацию(якобы косячную), потому что она приятно и легко воспринимается.
Тут "движок" реакта разберется когда сетнуть новую ссылку на элемент, а когда она осталась неизменной. Но все таки есть конечно слабые места, но пока до них не дошли, мне кажется, что первая "косячная" реализация хука более приятная, очевидная и менее запутанная
Я лютый приверженец MobX, но справедливости ради стоит отметить, что в нем тоже все , что читает observable поля должно быть завернуто в observer, у которого под капотом React.memo
Ну как же. В самом описании хука useEffect написано, что если значение в массиве зависимостей отлично от предыдущего рендера, то реакт дернет useEffect
Не будем тратить время на детальное объяснение того, что происходит в коде выше
Давайте все таки разберемся. Вы используете хук useRef, который создает объект с полем current на все время жизни компонента. И ссылка на объект останется неизменной. Это важно.
Далее в этот объект вы в зависимости от условия кидаете новые ссылки на DOM элементы.
Но в хук useResizeObserver вы все также передаете ту статичную ссылку на объект рефа. Это первый звоночек, который я заметил. И далее в хуке заметил, что useEffect тоже подписан на ту самую ссылку, которая статична.
Попробуйте не переписывая ничего заменить: useResizeObserver({ elemRef, onResize: handleResize }); на useResizeObserver({ elemRef: elemRef.current, onResize: handleResize });
Т.е. я (хоть уже и не молодой) достаточно часто могу переиграть кошку в игре "кто кого цапнет на скорость".
мне кажется тут надо внести детали. Когда вы играете в эту игру, вы пользуетесь вашими знаниями о поведении кошки и некой стратегией. То есть вы планируете рассчитываете ее действия и с высокой точностью предугадываете его. На что уже достаточно легко среагировать. Кошка же наверное каждый матч ведет без какой либо тактики и уж тем более стратегии(максимум тихо подкрасться), а чисто интуитивно атакует/защищается.
Думаю если кошке накинуть навыков стратегии и интеллекта, то наверное это для вас будет как бой с профессиональным боксером или вроде того. И там ваш процент выигрыша будет не такой уж и большой.
П.С. У меня есть кошка и когда я с ней намеренно воюю, то я выигрываю. Но от внезапного "кусь" увернуться мне очень редко удается, а удается только тогда, когда я вижу, что "что не то, ща чет будет".
Видел проекты на 30+ мб рукописного реактовского кода, где обернуто абсолютно все и видел такие же проекты, где ничего не обернуто. Это все конечно ЦРМки были, но все же разницы не чувствуется
эмм, да, а где минусы то?
Понравилось, спасибо
В конце вы описали кодом крутые примеры, но хотелось бы ссылки на песочницу или гифки. Я ленивый, простите )
давайте там где :has вместо +, если вы не против?
Спасибо
Мне для самообразования. Вот вы указали, что централизованный кеш не подошел из-за того, что это сетевой запрос.
Но в тоже время вы заюзали "централизованную" кафку. Разве общение с ней, не есть сетевые запросы или ... ?
Иронично
не, это скорее типа парирование. Вы выдвигаете это как минус, я просто говорю, что это можно починить.
А удобство - дело вкуса. Мне, как фронтендеру - да, более чем. Бэк сторону не знаю, поэтому и не сужу
так это ж настраивается
Я кажется понял вас.
Нет, я не хочу изменяя ref.current заставлять компоненту ререндерится.
Мне не нравится решение проблемы, которое предложил автор. Хук переписан так, что с наскоку непонятно, что в нем происходит, приходится вчитываться, а я это не люблю.
Я бы предложил решать проблему все таки через ссылку и первую реализацию(якобы косячную), потому что она приятно и легко воспринимается.
Всего лишь вместо
Сделать
Тут "движок" реакта разберется когда сетнуть новую ссылку на элемент, а когда она осталась неизменной. Но все таки есть конечно слабые места, но пока до них не дошли, мне кажется, что первая "косячная" реализация хука более приятная, очевидная и менее запутанная
ааа, вы про это.
конечно изменение рефа ничего не триггерит
Я лютый приверженец MobX, но справедливости ради стоит отметить, что в нем тоже все , что читает observable поля должно быть завернуто в observer, у которого под капотом React.memo
Что будет с useHover, если элемент который к нему подключен рендерится по условию и вдруг исчез, а потом появился?
В 4 хуке вы упомянули про производительность, но в хук воткнули useLayoutEffect. Зачем он там? То же самое и в 5
Ну как это нет бойлерплейта, чтобы его не было, должно было бы выглядеть так:
Это вопрос не вам, а к примеру кода от markelov69
Почему вам нравится
new A().effect1().effect2().......effectN()
но не нравится
new A(A.effect1(), A.effect2(), ..... A.effectN())
Мне со стороны кажется, что только в этом разница, нет?
Ну как же. В самом описании хука useEffect написано, что если значение в массиве зависимостей отлично от предыдущего рендера, то реакт дернет useEffect
Давайте все таки разберемся. Вы используете хук useRef, который создает объект с полем current на все время жизни компонента. И ссылка на объект останется неизменной. Это важно.
Далее в этот объект вы в зависимости от условия кидаете новые ссылки на DOM элементы.
Но в хук
useResizeObserver
вы все также передаете ту статичную ссылку на объект рефа. Это первый звоночек, который я заметил. И далее в хуке заметил, что useEffect тоже подписан на ту самую ссылку, которая статична.Попробуйте не переписывая ничего заменить:
useResizeObserver({ elemRef, onResize: handleResize });
на
useResizeObserver({ elemRef: elemRef.current, onResize: handleResize });
мне кажется тут надо внести детали. Когда вы играете в эту игру, вы пользуетесь вашими знаниями о поведении кошки и некой стратегией. То есть вы планируете рассчитываете ее действия и с высокой точностью предугадываете его. На что уже достаточно легко среагировать. Кошка же наверное каждый матч ведет без какой либо тактики и уж тем более стратегии(максимум тихо подкрасться), а чисто интуитивно атакует/защищается.
Думаю если кошке накинуть навыков стратегии и интеллекта, то наверное это для вас будет как бой с профессиональным боксером или вроде того. И там ваш процент выигрыша будет не такой уж и большой.
П.С. У меня есть кошка и когда я с ней намеренно воюю, то я выигрываю. Но от внезапного "кусь" увернуться мне очень редко удается, а удается только тогда, когда я вижу, что "что не то, ща чет будет".
Видел проекты на 30+ мб рукописного реактовского кода, где обернуто абсолютно все и видел такие же проекты, где ничего не обернуто. Это все конечно ЦРМки были, но все же разницы не чувствуется
brotli же уже, какой gzip