Redux: 스마트 구성 요소와 멍청한 구성 요소 사이의 "행복한 매체"는 어디에 있습니까?

우리는 이전 버전의 문서에서 덜 연결된 구성 요소를 갖는 것이 더 낫다고 말했지만화물 컬트가 얼마나 될지 예상하지 못했습니다. 😞 예, 모든 구성 요소를 연결하는 것은 종종 과잉이지만 모든 것을 맨 위에 놓는 것입니다! dispatch 를 얻기 위해 연결하는 것은 특히 무해하므로이 작업을 자주 수행하는 것에 대해 나쁘지 않아야합니다.

귀하의 코드는 나에게 절대적으로 괜찮아 보입니다. 👍

감사합니다. 적어도 나는 내 코드가 괜찮고 아마도 더 나은 회사에서 일할 것이라는 강력한 주장을 가지고 있습니다. :)

하지만 여전히 connect 이 (가) 과도한 시나리오를 이미징 할 수 없습니다. 이 데이터를 사용하지 않는 부모 컨트롤에서 자식 컨트롤로 데이터를 전달하거나 코드에 connect 를 추가해야하는 규칙을 파악하기 위해이 기술을 개발하는 방법 (특히 작은 데이터 덩어리를 읽는 경우) 상점에서)?

앱에서 많은 connect 에서 어떤 종류의 문제가 발생합니까?

Redux의 구독자 알림 프로세스는 모든 구독자 콜백을 실행하는 간단한 루프이므로 분명히 O (n)입니다. 이론적으로 구독자 콜백이 복잡한 작업을 수행하거나 구독자 수가 _ 매우 _ 크게 증가하면 성능 문제가 될 수 있습니다.

실제로는 별 문제가되지 않을 것입니다. 현실적으로 문제가되기 전에 많은 작업이 1 초에 발송되는 수천 개의 활성 구독이 있어야한다고 생각합니다. (아마도 최근의 MobX / Redux 비교가 관련이 있지 않는 한) 나는 그것을 검증하기 위해 지적 할 수있는 특정 벤치 마크를 현재로서는 알지 못합니다.

전반적으로, 나는 당신이 고전적인 "작동하고, 올바르게 만들고, 빨리 만들기"접근 방식을 따르는 것이 안전해야한다고 생각합니다. 애플리케이션의 기능이 제대로 작동하도록하는 코드를 작성하십시오. 작성한 내용을보고 필요한 경우 구조를 조정하여 더 이해하기 쉽습니다. 느리게 느껴지면 실제로 느린 부분을 측정하고 벤치마킹하고 수정합니다.