DT
но лучше жаловаться что примера в доке нет
Size: a a a
2020 October 14
М
во, еще раз спасибо, то что я и искал. Для того что бы без гемора возвращать объекты, нужно еще юзать shallowEqual из редакса, помимо всего
AP
Ребят, посоветуйте, как правильно... есть SPA календарь сотрудников на React-MobX..есть переключение видов на месяц на год на день и есть события которые подтягиваются через фетч...где хранить состояние для переключалок(месяц, год, вид) в MobX или в useState корневого компонента?
AP
Всем привет,пишу мини приложение с нуля,но не могу задать стили для компонента,в чем может быть проблема?
И
Ну то есть, когда код уже написан, протестирован, куча компонентов, потом начинаешь смотреть: а куда бы мне засунуть мемо, а то чот тормозить стало?
а когда во время тестирования баги вылезают, ты тоже расстраиваешься, что теперь “начинаешь смотреть: а куда бы мне засунуть typeof X !== “undefined”, а то чот падать стало?”
AP
Всем привет,пишу мини приложение с нуля,но не могу задать стили для компонента,в чем может быть проблема?
И
Всем привет,пишу мини приложение с нуля,но не могу задать стили для компонента,в чем может быть проблема?
переименуй в cityCard.module.css
AP
переименуй в cityCard.module.css
ооо,спасибо,раньше такого не нужно біло делать,это нововведение такое?
IN
чего это?
Это не интуитивно. Одни начинают преждевременную оптимизацию всего и вся, другие мучительно думать: а не обернуть ли мне это в юзколбек? Ковыряться апостериори в девтулзах из-за сломанного перфа — имхо, такое.
IN
а когда во время тестирования баги вылезают, ты тоже расстраиваешься, что теперь “начинаешь смотреть: а куда бы мне засунуть typeof X !== “undefined”, а то чот падать стало?”
при багах я заранее могу поставить проверку на андефайнд, а не мучаться "А не будет ли это преждевременной оптимизацией?")
И
Это не интуитивно. Одни начинают преждевременную оптимизацию всего и вся, другие мучительно думать: а не обернуть ли мне это в юзколбек? Ковыряться апостериори в девтулзах из-за сломанного перфа — имхо, такое.
интуитивно — это побежать с палкой на медведя и умереть в 5346м году до н.э.
а всё, на чём построена человеческая цивилизация, оно не интуитивно, тут головой думать надо
а всё, на чём построена человеческая цивилизация, оно не интуитивно, тут головой думать надо
MK
интуитивно — это побежать с палкой на медведя и умереть в 5346м году до н.э.
а всё, на чём построена человеческая цивилизация, оно не интуитивно, тут головой думать надо
а всё, на чём построена человеческая цивилизация, оно не интуитивно, тут головой думать надо
Красиво
RU
фонд золотых цитат реакт чата...
IN
интуитивно — это побежать с палкой на медведя и умереть в 5346м году до н.э.
а всё, на чём построена человеческая цивилизация, оно не интуитивно, тут головой думать надо
а всё, на чём построена человеческая цивилизация, оно не интуитивно, тут головой думать надо
и ковыряться во вкладке performance вместо того, чтобы заранее сделать так, чтобы железно работало
RU
при багах я заранее могу поставить проверку на андефайнд, а не мучаться "А не будет ли это преждевременной оптимизацией?")
правильность кода и перформанс - изначально разные задачи, поэтому и делается это поразному
если ты пишешь идеальный код - то конечно можешь в каждом компоненте проводить оценку, что тебе даст выигрышь в ререндерах и производительности
но реальный софт так не пишут: преформанс - это граница сверху, в которую надо влезть с минимальными телодвижениями
если ты пишешь идеальный код - то конечно можешь в каждом компоненте проводить оценку, что тебе даст выигрышь в ререндерах и производительности
но реальный софт так не пишут: преформанс - это граница сверху, в которую надо влезть с минимальными телодвижениями
М
Всех приветствую. Недавно начал кодить на реакте в связке с тайпскриптом и возник такой вопрос: как для стейта я могу определить тип конкретного компонента, чтобы на другие компоненты и вообще объекты тайпскрипт ругался?
И
при багах я заранее могу поставить проверку на андефайнд, а не мучаться "А не будет ли это преждевременной оптимизацией?")
ну вот тебе жизненный опыт подсказывает, когда следует проверку вставить, а когда — нет. так же и с оптимизациями. постепенно доходит
оптимизация от кучи параметров зависит
вот есть список.
если в списке тысяча элементов, очевидно нужно оптимизировать ререндеры элементов списка. а если в списке никогда не будет больше 5 элементов, завчем оптимизировать перерисовку? незачем.
но, с другой стороны, если внутри каждого элемента списка лежит дерево из тысячи неоптимизированных компонентов, то надо оптимизировать. а если не тысяча, а два — зачем оптимизировать?
оптимизация от кучи параметров зависит
вот есть список.
если в списке тысяча элементов, очевидно нужно оптимизировать ререндеры элементов списка. а если в списке никогда не будет больше 5 элементов, завчем оптимизировать перерисовку? незачем.
но, с другой стороны, если внутри каждого элемента списка лежит дерево из тысячи неоптимизированных компонентов, то надо оптимизировать. а если не тысяча, а два — зачем оптимизировать?
ДШ
ну вот тебе жизненный опыт подсказывает, когда следует проверку вставить, а когда — нет. так же и с оптимизациями. постепенно доходит
оптимизация от кучи параметров зависит
вот есть список.
если в списке тысяча элементов, очевидно нужно оптимизировать ререндеры элементов списка. а если в списке никогда не будет больше 5 элементов, завчем оптимизировать перерисовку? незачем.
но, с другой стороны, если внутри каждого элемента списка лежит дерево из тысячи неоптимизированных компонентов, то надо оптимизировать. а если не тысяча, а два — зачем оптимизировать?
оптимизация от кучи параметров зависит
вот есть список.
если в списке тысяча элементов, очевидно нужно оптимизировать ререндеры элементов списка. а если в списке никогда не будет больше 5 элементов, завчем оптимизировать перерисовку? незачем.
но, с другой стороны, если внутри каждого элемента списка лежит дерево из тысячи неоптимизированных компонентов, то надо оптимизировать. а если не тысяча, а два — зачем оптимизировать?
В если всегда мемоизировать, тогда и думать не надо 🤔
И
и ковыряться во вкладке performance вместо того, чтобы заранее сделать так, чтобы железно работало
хз, зачем вообще девтулзы, тесты, статическую типизацию придумали
можно же просто заранее писать высокопроизводительный код без багов 🤷♂️
можно же просто заранее писать высокопроизводительный код без багов 🤷♂️
И
В если всегда мемоизировать, тогда и думать не надо 🤔
если всегда мемоизировать, то код будет работать и читаться медленнее, чем если мемоизировать не всегда