потом начинаешь смотреть: а куда бы мне засунуть мемо, а то чот тормозить стало?
а когда во время тестирования баги вылезают, ты тоже расстраиваешься, что теперь “начинаешь смотреть: а куда бы мне засунуть typeof X !== “undefined”, а то чот падать стало?”
при багах я заранее могу поставить проверку на андефайнд, а не мучаться "А не будет ли это преждевременной оптимизацией?")
правильность кода и перформанс - изначально разные задачи, поэтому и делается это поразному если ты пишешь идеальный код - то конечно можешь в каждом компоненте проводить оценку, что тебе даст выигрышь в ререндерах и производительности но реальный софт так не пишут: преформанс - это граница сверху, в которую надо влезть с минимальными телодвижениями
ну вот тебе жизненный опыт подсказывает, когда следует проверку вставить, а когда — нет. так же и с оптимизациями. постепенно доходит оптимизация от кучи параметров зависит вот есть список. если в списке тысяча элементов, очевидно нужно оптимизировать ререндеры элементов списка. а если в списке никогда не будет больше 5 элементов, завчем оптимизировать перерисовку? незачем. но, с другой стороны, если внутри каждого элемента списка лежит дерево из тысячи неоптимизированных компонентов, то надо оптимизировать. а если не тысяча, а два — зачем оптимизировать?
В если всегда мемоизировать, тогда и думать не надо 🤔
если всегда мемоизировать, то код будет работать и читаться медленнее, чем если мемоизировать не всегда
Ключевое тут — жизненный опыт. Далеко не у всех он есть. Для новичков и не только это — неведомая *баная херня, из-за чего я и начал этот тред.
А замедлением в работе можно пренебречь - оно не значительное в общем случае
приходим к выводу, что надо думать головой и разбираться в теме, а не забивать хуй и лупить по клавиатуре с завязанными глазами
фреймворки сделаны чтобы облегчать разработку, а не усложнять её :)
спорно. ну да бог с тобой
Обсуждают сегодня