Реагируйте на философию «поднятия состояния вверх»: как избежать попадания в один большой родительский компонент, содержащий весь код?

Question

Это не очень точный вопрос. Я думаю, что понимаю парадигму "реагируй на подъем". Насколько я знаю, это единственный чистый способ для двух родственных компонентов иметь доступ к своим соответствующим свойствам.

Но при этом я получаю один потрясающий класс, содержащий все: данные данных о свойствах всех его дочерних компонентов и все функции, отвечающие за обновление этой информации (отвечающие за вызов setState). Я недоволен тем фактом, что больше не могу отправлять на подкомпоненты работу, связанную с ними.

Мой вопрос таков: как избежать концентрации всего кода в родительских компонентах, используя реагировать, сохраняя при этом хороший чистый механизм состояния / поддержки? Или я, возможно, неправильно жаловался?

Answer 1

Многие люди считают, что переход к редуксу был бы хорошей идеей, но на самом деле он содержит множество вычислительных накладных и шаблонного кода.

Как правило, вы бы просто переместили логику вверх по дереву, которая актуальна не только для дочерних компонентов, но и для братьев и сестер.

Вам также следует взглянуть на концепцию Презентационные и контейнерные компоненты .