OR
Про мемо не понял
Он почему-то думает, что Коннект компонент не перерендеривает детей.
Size: a a a
2020 October 03
|
А такие тесты имею смысл?
ス。
Про мемо не понял
я увидел, что если редакс коммпонент А делает рендер, то его ребенок редакс компонент Б не будет делать рендер если значениия из mapToProps у Б не менялись.
то есть если Б читает значение X от стейта, и при ре рендера А, Х не меняется, то и Б не будет делать рендер. это при connect
теперь с хуакми получается что ребенок всегда будет делать ре рендер если рендер сделает родитель, пока не юзать react.memo
то есть если Б читает значение X от стейта, и при ре рендера А, Х не меняется, то и Б не будет делать рендер. это при connect
теперь с хуакми получается что ребенок всегда будет делать ре рендер если рендер сделает родитель, пока не юзать react.memo
GO
ребят правильно понимаю ? . если редакс юзать с хуками (useSelector, useDispatch), то там dispatch не работет с action creators, собственно будет глобалюный метод dispatch, и еще там если parent компонент сделает рендер, то и редакс-ребенок будет делать рендер, вне зависимости от пропов, если не юзать react.memo (чего нет если юзать connect)
получаетсся для нормальной имитации работы редакса с хуками надо все редакс компоненты засунуть в react.memo , и что делать с dispatch. идея action creators очень хорошая, а тут вот вам один метод.
получаетсся для нормальной имитации работы редакса с хуками надо все редакс компоненты засунуть в react.memo , и что делать с dispatch. идея action creators очень хорошая, а тут вот вам один метод.
ス。
Green Orange
во, спасибо
EM
"Но что касается Redux, то я придерживаюсь мнения, что с хуками код выглядит сложнее. Нарушается принцип единой ответственности, сложнее тестировать и дебажить компоненты. Если вынести хуки в отдельный компонент, то получится тот же самый connect, но без дополнительных полезных обработчиков для оптимизации перерендеров."
😑😑😑
😑😑😑
VK
"Но что касается Redux, то я придерживаюсь мнения, что с хуками код выглядит сложнее. Нарушается принцип единой ответственности, сложнее тестировать и дебажить компоненты. Если вынести хуки в отдельный компонент, то получится тот же самый connect, но без дополнительных полезных обработчиков для оптимизации перерендеров."
😑😑😑
😑😑😑
А где нарушается принцип единой ответственности?
OR
"Но что касается Redux, то я придерживаюсь мнения, что с хуками код выглядит сложнее. Нарушается принцип единой ответственности, сложнее тестировать и дебажить компоненты. Если вынести хуки в отдельный компонент, то получится тот же самый connect, но без дополнительных полезных обработчиков для оптимизации перерендеров."
😑😑😑
😑😑😑
Привет ты чё. От тебя такого не ожидал.
MK
MK
Цитата из желтой книги следом:
Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что-то одно. Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности.
Фактически принцип можно перефразировать так: "Модуль должен отвечать за одного и только за одного пользователя или заинтересованное лицо."
Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что-то одно. Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности.
Фактически принцип можно перефразировать так: "Модуль должен отвечать за одного и только за одного пользователя или заинтересованное лицо."
|
Правильно ли выделять функциональные компоненты? Раскидывать по отдельным файлам коннект и mapDispatchToProps
MK
Цитата из желтой книги следом:
Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что-то одно. Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности.
Фактически принцип можно перефразировать так: "Модуль должен отвечать за одного и только за одного пользователя или заинтересованное лицо."
Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что-то одно. Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности.
Фактически принцип можно перефразировать так: "Модуль должен отвечать за одного и только за одного пользователя или заинтересованное лицо."
компонент фетчит данные !== нарушение srp, так что хз
И
я увидел, что если редакс коммпонент А делает рендер, то его ребенок редакс компонент Б не будет делать рендер если значениия из mapToProps у Б не менялись.
то есть если Б читает значение X от стейта, и при ре рендера А, Х не меняется, то и Б не будет делать рендер. это при connect
теперь с хуакми получается что ребенок всегда будет делать ре рендер если рендер сделает родитель, пока не юзать react.memo
то есть если Б читает значение X от стейта, и при ре рендера А, Х не меняется, то и Б не будет делать рендер. это при connect
теперь с хуакми получается что ребенок всегда будет делать ре рендер если рендер сделает родитель, пока не юзать react.memo
Получается, что да. Нужны ли эти сокрытые оптимизации — другой вопрос.
МК
подскажите пожалуйста, вот к примеру есть такое меню. Нужно чтобы текущий пункт меню имел другие стили.
Предположим, сделать как на втором скрине - это нормальное решение или есть какой-то совсем другой, более красивый способ? Может быть только чисто с css как-то?
Предположим, сделать как на втором скрине - это нормальное решение или есть какой-то совсем другой, более красивый способ? Может быть только чисто с css как-то?
МК
A
Миша Ковальчук
подскажите пожалуйста, вот к примеру есть такое меню. Нужно чтобы текущий пункт меню имел другие стили.
Предположим, сделать как на втором скрине - это нормальное решение или есть какой-то совсем другой, более красивый способ? Может быть только чисто с css как-то?
Предположим, сделать как на втором скрине - это нормальное решение или есть какой-то совсем другой, более красивый способ? Может быть только чисто с css как-то?
Нормальное если работает и устраивает того кто ревьювит
МК
Нормальное если работает и устраивает того кто ревьювит
никто не ревьюит, я сам для себя делаю. Поэтому хочу понять как подобное вообще обычно решается
A
Миша Ковальчук
никто не ревьюит, я сам для себя делаю. Поэтому хочу понять как подобное вообще обычно решается
Поищи примеры