onClick в обработке, в react, ничем не отличается от className . Как и не отличаются div и Counter. Проверится предыдущее значение, провериться следующее значение, если какой-то параметр изменился, то функция компонента выполнится и результат уйдет на рендер. То, как результат попадет в реальный DOM, уже не так важно.
Ивенты тут вообще ни при чем, потому что вместо clickHandler может быть какой-то onSomeAction , который должен вызываться, если в компоненте что-то поменялось, и это никаким образом не будет связано с ивентами. Но работать будет идентично, и проблемы будут идентичные.
События тут вообще ни при чем. Тут все упирается в непонимание того как работает компонент. При каждом его обновлении, вызывается его функция, и все, что объявлено в этой функции будет заново объявлено. Все ссылки станут новыми, все старые ссылки никуда не делись, и продолжают висеть в памяти. В примере из статьи, этой самой ссылкой является clickHandler . Следовательно, надо вручную отследить, отписать от неактуальной и подписать на актуальную. Сделать все то, что делает сам реакт под капотом.
Думаю это хорошо подходит под категорию рандомных скриптов. Чтоб все хорошо работало, нужен единый инструмент, который все разруливает. А если N модулей используют по такому инструменту, то в результате бандл будет больше примерно в N раз.
Как правило, разработчик никак не может повлиять на сторонние скрипты, которые встраиваются в сайт. Это метрики, аналитика, реклама, капчи и тд. Так-же не может повлиять на установленные в браузер расширения и блокировщики. Все это пишется непонятно кем, непонятно как. Но по итогу, каким бы ни был вылизан твой код, в консоли будет насрано.
Современный фронтенд очень легковесный, потому что на этапе сборки удаляется все не используемое, делится на небольшие кусочки, и в браузере загружается ровно то, что необходимо (в разумных пределах), в автоматическом режиме.
Дикие десятки мегабайт появляются тогда, когда надо поддерживать легаси десятилетней давности, давно не поддерживаемые библиотеки, потом к этому прикрутить современный фронтенд фреймворк и наладить взаимодействие с десятками рандомных сторонних скриптов, которым что-то нужно, а так-же добавить метрики, аналитику и рекламу. И все это должно работать в IE.
Пользуюсь такой штукой skeletonreact.com, результат очень крутой, на входе твоя svg, на выходе svg с анимацией. Есть под популярные фреймворки. Скопировал svg и вставил куда надо, никаких зависимостей. Преимущество svg в том, что оптимизация анимаций в браузере под капотом, в отличии от css анимаций. Размещать можно хоть 1000 анимированных элементов на странице, она не будет подвисать.
Ну, нужен он самому реакту, это понятно. Но зачем его использовать у себя в коде, совсем не понятно. Описанные преимущества ценны в сравнении и наглядном примере. Но сравнений нет, а примеры неудачные. Потому что рекомендованный вариант превратит код в нечитабельный кусок г, а нестандартные не соответствуют друг другу, так как предоставляют разные возможности.
Только с очевидными вещами в пределах предложения, и это очень смахивает на матчинг. Выделяет слова, ищет предложение и подбирает остаток. Достаточно задать вопрос так, чтоб он не содержал ключевых слов намекающих на ответ, то нейронка сломается и выдаст бред.
Что будет с человеком, если в него влетит металлическая конструкция весом в 1.5-2 тонны на скорости 60км в час? Ночью эта скорость скорее всего будет раза в 1.5-2 выше.
В городе плотность пешеходов и машин несравненно выше чем на трассе. Отсюда и статистика смертности.
onClickв обработке, в react, ничем не отличается отclassName. Как и не отличаютсяdivиCounter. Проверится предыдущее значение, провериться следующее значение, если какой-то параметр изменился, то функция компонента выполнится и результат уйдет на рендер. То, как результат попадет в реальный DOM, уже не так важно.Ивенты тут вообще ни при чем, потому что вместо
clickHandlerможет быть какой-тоonSomeAction, который должен вызываться, если в компоненте что-то поменялось, и это никаким образом не будет связано с ивентами. Но работать будет идентично, и проблемы будут идентичные.События тут вообще ни при чем. Тут все упирается в непонимание того как работает компонент. При каждом его обновлении, вызывается его функция, и все, что объявлено в этой функции будет заново объявлено. Все ссылки станут новыми, все старые ссылки никуда не делись, и продолжают висеть в памяти. В примере из статьи, этой самой ссылкой является
clickHandler. Следовательно, надо вручную отследить, отписать от неактуальной и подписать на актуальную. Сделать все то, что делает сам реакт под капотом.У них отработает brotli или gzip
Это не надо, когда есть уже счетчик распечатанных страниц, и принтер блокируется, пока не продлишь подписку.
Думаю это хорошо подходит под категорию рандомных скриптов. Чтоб все хорошо работало, нужен единый инструмент, который все разруливает. А если N модулей используют по такому инструменту, то в результате бандл будет больше примерно в N раз.
Как правило, разработчик никак не может повлиять на сторонние скрипты, которые встраиваются в сайт. Это метрики, аналитика, реклама, капчи и тд. Так-же не может повлиять на установленные в браузер расширения и блокировщики. Все это пишется непонятно кем, непонятно как. Но по итогу, каким бы ни был вылизан твой код, в консоли будет насрано.
Современный фронтенд очень легковесный, потому что на этапе сборки удаляется все не используемое, делится на небольшие кусочки, и в браузере загружается ровно то, что необходимо (в разумных пределах), в автоматическом режиме.
Дикие десятки мегабайт появляются тогда, когда надо поддерживать легаси десятилетней давности, давно не поддерживаемые библиотеки, потом к этому прикрутить современный фронтенд фреймворк и наладить взаимодействие с десятками рандомных сторонних скриптов, которым что-то нужно, а так-же добавить метрики, аналитику и рекламу. И все это должно работать в IE.
Да, это гг. Переползти на что-то другое другое будет очень больно. Потому что сложно придумать что-то минималистичнее, компактнее, и удобнее.
Ага, и обмазываться обсерверами, превращая создание любого компонента в г.
Это плохой пример, потому что такие ситуации должны решаться батчингом. Там, где устанавливается state1, должен устанавливаться и state2.
const newState1 = {...}
setState1(newState1)
if (newState1 === any) setState2();
Пользуюсь такой штукой skeletonreact.com, результат очень крутой, на входе твоя svg, на выходе svg с анимацией. Есть под популярные фреймворки. Скопировал svg и вставил куда надо, никаких зависимостей. Преимущество svg в том, что оптимизация анимаций в браузере под капотом, в отличии от css анимаций. Размещать можно хоть 1000 анимированных элементов на странице, она не будет подвисать.
Ну, нужен он самому реакту, это понятно. Но зачем его использовать у себя в коде, совсем не понятно. Описанные преимущества ценны в сравнении и наглядном примере. Но сравнений нет, а примеры неудачные. Потому что рекомендованный вариант превратит код в нечитабельный кусок г, а нестандартные не соответствуют друг другу, так как предоставляют разные возможности.
Можно сделать самоподписанный сертификат, добавить и собирать под ним ПО для себя.
В городе плотность пешеходов и машин несравненно выше чем на трассе. Отсюда и статистика смертности.