В целом да, согласен, конечно. Но это, вполне очевидно, как раз тот самый 1% edge-case, когда надо подумать. Вполне интересная задачка, понятное узкое место, а не скучная рутина.)
Я мог бы согласиться, но каждый выбор мемоизировать или нет заставляет меня думать: "подгружать" контекст, подгружать особенности, анализировать необходимость, делать выбор. Каждый раз когда я думаю о таких мусорных, не относящихся к конкретной задаче, вещах, я трачу своё время, и, главное, своё "процессорное время". Пускай в каждом конкретном случае это немного, но в целом - это заметно сказывается на продуктивности. Гораздо приятнее или мемоизировать всегда, или "мемоизировать потом", потому что это можно сделать навыком, не требующим мышления.
В целом, я считаю что фреймворк/библиотека должен думать за меня в 99% случаев, оставляя на меня edge-case вещи, действительно требующие осознанного решения. Идиоматичный же реакт заставляет меня либо думать в этих самых 99% случаев, либо забить(тем или иным образом), но чувствовать себя говнокодером(пусть даже и неоправданно).
Дык это как раз суть их подхода: мемоизируем сейчас, чтоб не выстрелить себе в ногу потом.
Да, в button onClick мемоизация не нужна, но вот при следующей итерации на месте button окажется CoolButton, где она нужна, но её, по недогляду, не будет.
Так оно сломаное. Пропусти мемоизацию в одном месте и оно водопадом обрушится до самого конца.
Я прекрасно знаю идеологию реакт: «забей на оптимизацию сейчас, оптимизируй узкое место потом».
Проблема в том, что она не работает. Нет никакого узкого места. Каждый компонент в котором забили на оптимизацию — «чуть-чуть» тормозит. Потом они складываются в кучку и получается Patreon.
Тормоза размазаны по всем компонентам и починить можно, только переписав каждый. Ну или переписав «достаточно», чтоб тормозить стало незаметно. До следующего раза.
По факту в реакте практически невозможно без профилирования сказать полезна ли мемоизация в конкретном случае, т.к. из-за архитектурных особенностей всё зависит по большей части не от человеческой логики, а от глубокой логики js-движка.
Более-менее «защитить» можно элементарно. Запоминать предыдущие точку и время запроса и сравнивать с новой. Если скорость перемещения больше ~250км/ч — клиент на подозрении, если повтор — бан за нарушение условий использования.
Да и useCallback выкинуть - в ref положить массив\объект и функцию-обёртку сразу же первым ключом.)
В целом да, согласен, конечно. Но это, вполне очевидно, как раз тот самый 1% edge-case, когда надо подумать. Вполне интересная задачка, понятное узкое место, а не скучная рутина.)
"computed от computed за O(1)"
0_o, а это нужно?
Имхо, Vue 2 самое близкое пока, что видел к этому идеалу. (В Vue 3 просрали все полимеры.)
Я мог бы согласиться, но каждый выбор мемоизировать или нет заставляет меня думать: "подгружать" контекст, подгружать особенности, анализировать необходимость, делать выбор. Каждый раз когда я думаю о таких мусорных, не относящихся к конкретной задаче, вещах, я трачу своё время, и, главное, своё "процессорное время". Пускай в каждом конкретном случае это немного, но в целом - это заметно сказывается на продуктивности. Гораздо приятнее или мемоизировать всегда, или "мемоизировать потом", потому что это можно сделать навыком, не требующим мышления.
В целом, я считаю что фреймворк/библиотека должен думать за меня в 99% случаев, оставляя на меня edge-case вещи, действительно требующие осознанного решения. Идиоматичный же реакт заставляет меня либо думать в этих самых 99% случаев, либо забить(тем или иным образом), но чувствовать себя говнокодером(пусть даже и неоправданно).
Дык это как раз суть их подхода: мемоизируем сейчас, чтоб не выстрелить себе в ногу потом.
Да, в button onClick мемоизация не нужна, но вот при следующей итерации на месте button окажется CoolButton, где она нужна, но её, по недогляду, не будет.
Я прекрасно знаю идеологию реакт: «забей на оптимизацию сейчас, оптимизируй узкое место потом».
Проблема в том, что она не работает. Нет никакого узкого места. Каждый компонент в котором забили на оптимизацию — «чуть-чуть» тормозит. Потом они складываются в кучку и получается Patreon.
Тормоза размазаны по всем компонентам и починить можно, только переписав каждый. Ну или переписав «достаточно», чтоб тормозить стало незаметно. До следующего раза.
В этом вопросе я скорее согласен с этими ребятами Why We Memo All the Things.