Redux: Где находится «золотая середина» между умными и глупыми компонентами?

Мы привыкли говорить, что в более ранних версиях документации лучше иметь меньше связанных компонентов, но я не ожидал, насколько это станет культом карго. 😞 Да, подключение каждого компонента часто является излишним, но также как и размещение всего наверху! Подключение только ради получения dispatch особенно безвредно, поэтому не стоит расстраиваться из-за этого часто.

Ваш код мне кажется абсолютно нормальным. 👍

Спасибо. По крайней мере, сейчас у меня есть веские аргументы, что мой код в порядке и, вероятно, найду работу в лучшей компании :)

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

Какие проблемы будут возникать со многими connect в приложении?

Процесс уведомления подписчика Redux - это простой цикл, который запускает каждый обратный вызов подписчика, так что, очевидно, O (n). Теоретически, если обратные вызовы подписчиков делают что-то сложное или если количество подписчиков становится очень большим, это может стать проблемой для производительности.

На практике это, вероятно, не вызывает большого беспокойства. Я подозреваю, что вам нужно иметь несколько тысяч активных подписок со многими действиями, отправляемыми за секунду, прежде чем это станет реальной проблемой. На данный момент я не знаю каких-либо конкретных тестов, на которые я мог бы указать, чтобы проверить это (если, может быть, недавнее сравнение MobX / Redux не будет иметь отношения).

В целом, я считаю, что вы должны быть в безопасности, следуя классическому подходу «заставить работать, исправлять, делать быстро». Напишите код, обеспечивающий правильную работу функций вашего приложения. Посмотрите на то, что вы написали, и при необходимости измените структуру, чтобы она имела больше смысла. Если это кажется медленным, измерьте, протестируйте и исправьте те части, которые на самом деле работают медленно.