React-Redux: Якщо всі стани компонентів зберігатимуться в Redux Store

Скажімо, у мене є простий перемикач:

Коли я натискаю кнопку, компонент Колір змінюється між червоним та синім

Я міг би досягти цього результату, роблячи щось подібне.

index.js

Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red

container.js

connect(mapStateToProps)(indexPage)

action_creator.js

function changeColor(){
 return {type: 'CHANGE_COLOR'}
}

reducer.js

switch(){
case 'CHANGE_COLOR':
return {color: true}

але це надзвичайно багато коду для написання чогось, чого я міг досягти за 5 секунд за допомогою jQuery, деяких класів та деяких css ...

Тож я здогадуюсь, що я насправді запитую, що я тут роблю не так?

Redux в першу чергу призначений для "стану програми". Тобто все, що пов’язано з логікою вашого додатка. Погляд, побудований поверх нього, є відображенням цього стану, але не повинен використовувати виключно цей контейнер стану для всього, що він робить.

Просто задайте такі запитання: чи важливий цей стан для решти програми? Чи будуть інші частини програми поводитися інакше залежно від цього стану? У багатьох незначних випадках цього не буде. Візьміть спадне меню: той факт, що він відкритий або закритий, ймовірно, не вплине на інші частини програми. Отже, підключити його до вашого магазину, мабуть, надмірно. Це, звичайно, дійсний варіант, але насправді не приносить вам ніяких переваг. Вам краще використовувати this.stateі називати це на день.

У вашому конкретному прикладі, чи перемикається колір цієї кнопки, щоб щось змінити в інших частинах програми? Якщо це якийсь загальний перемикач увімкнення / вимкнення для більшої частини вашої програми, він точно належить магазину. Але якщо ви просто перемикаєте колір кнопки, натискаючи кнопку, ви можете залишити стан кольору локально визначеним. Дія натискання кнопки може мати інші ефекти, що вимагають відправки дії, але це окремо від простого питання, якого кольору вона повинна бути.

Загалом, намагайтеся, щоб стан вашої програми був якомога меншим. Вам не потрібно засовувати все туди. Робіть це, коли потрібно, або є сенс тримати щось там. Або якщо це полегшує вам життя під час використання Dev Tools. Але не варто занадто перевантажувати його важливість.

Поширені запитання щодо Redux: Держава-організатор, що
ця частина офіційного документа redux добре відповіла на ваше запитання.

Використовувати стан локальних компонентів добре . Як розробник, ваша робота визначати, до якого типу штату входить ваша заявка, і де має жити кожен штат. Знайдіть баланс, який вам підходить, і подумайте.

Деякі загальні емпіричні правила визначення того, який тип даних слід розміщувати в Redux:

• Інші частини програми дбають про ці дані?
• Чи потрібно мати можливість створювати подальші похідні дані на основі цих вихідних даних?
• Чи використовуються однакові дані для керування кількома компонентами?
• Чи є для вас цінністю можливість відновити цей стан до заданого моменту часу (тобто налагодження подорожей у часі)?
• Ви хочете кешувати дані (тобто використовувати те, що знаходиться в стані, якщо воно вже є, замість того, щоб повторно запитувати його)?

Для того, щоб виділити чудове посилання, яке надає @ AR7, і тому, що воно посилалося на деякий час назад:

Використовуйте React для ефемерного стану, який не має значення для програми в усьому світі і не мутує складним чином. Наприклад, перемикання в якомусь елементі інтерфейсу, стан введення форми. Використовуйте Redux для стану, який має значення у всьому світі або мутується складними способами. Наприклад, кешовані користувачі або чернетка публікації.

Іноді вам захочеться перейти зі стану Redux у стан React (коли зберігати щось у Redux стає незручно) або навпаки (коли більше компонентів повинні мати доступ до якогось стану, який раніше був локальним).

Емпіричне правило: робити все, що є менш незручним.

Ден Абрамов: https://github.com/reactjs/redux/issues/1287#issuecomment-175351978

Так, варто прагнути зберігати всі стани компонентів у Redux . Якщо ви це зробите, ви отримаєте користь від багатьох функцій Redux, таких як налагодження подорожей у часі та звіти про помилки, які можна повторно відтворити. Якщо ви цього не зробите, ці функції можуть бути абсолютно непридатними .

Кожного разу, коли ви не зберігаєте зміну стану компонента в Redux, ця зміна повністю втрачається із стеку змін Redux, і користувальницький інтерфейс вашої програми буде не синхронізований із сховищем. Якщо для вас це не важливо, то запитайте себе, навіщо взагалі використовувати Redux? Без нього ваша заявка буде менш складною!

З міркувань продуктивності, можливо, ви захочете повернутися до this.setState()будь-чого, що могло б багато разів надсилати багато дій. Наприклад: збереження стану поля введення в Redux кожного разу, коли користувач вводить ключ, може призвести до низької продуктивності. Ви можете вирішити це, розглядаючи це як транзакцію: після того, як дія користувача "здійснена", збережіть остаточний стан у Redux.

У вашому оригінальному дописі згадується, як спосіб Redux - це "дуже багато коду для написання". Так, але ви можете використовувати абстракції для загальних зразків, таких як стан локальних компонентів.