Випущено React 16.3.0, і API контексту вже не є експериментальною функцією. Ден Абрамов (творець Redux) написав хороший коментар тут про це, але це було 2 роки , коли контекст був ще особливість експериментальної.
Моє питання, на вашу думку / досвід, коли я повинен використовувати React Context над React Redux і навпаки?
Відповіді:
Оскільки Context більше не є експериментальною функцією, і ви можете використовувати Context у своїй програмі безпосередньо, і він буде чудовим для передачі даних до глибоко вкладених компонентів, для чого він був розроблений.
Як Марк Еріксон написав у своєму блозі :
Якщо ви використовуєте Redux лише для того, щоб уникнути передачі реквізиту, контекст може замінити Redux - але тоді вам, напевно, Redux не знадобився.
Контекст також не дає вам нічого подібного
Redux DevTools, можливість відстежувати оновлення свого стану,middlewareдодавати централізовану логіку програми та інші потужні можливості, що цеReduxдозволяє.
Reduxнабагато потужніший і надає велику кількість функцій, які Context Apiне надає, також, як згадував @danAbramov
React Redux використовує контекст внутрішньо, але він не викриває цей факт у відкритому API. Тож вам слід відчувати себе набагато безпечніше, використовуючи контекст через React Redux, ніж безпосередньо, тому що якщо він зміниться, тягар оновлення коду ляже на React Redux, а не на вас.
Його upto Redux фактично оновить свою реалізацію, щоб вона відповідала останнім контекстним API
Останній API контексту може бути використаний для програм, де ви просто використовуєте Redux для передачі даних між компонентами, однак додаток, який використовує централізовані дані та обробляє запит API у творців Action, використовуючи redux-thunkабо redux-sagaвсе ще потребує скорочення. Крім цього скорочення, пов'язані інші бібліотеки, redux-persistякі дозволяють зберігати дані зберігання в localStorage та повторно регідрувати оновлення, що те, що API API все ще не підтримує.
Як згадував @dan_abramov у своєму блозі, вам може не потрібен Redux , що у redux є корисна програма, як-от
- Залиште стан до місцевого сховища, а потім завантажте його з коробки.
- Попередньо заповніть стан на сервері, надішліть його клієнтові в HTML і завантажте з нього з вікна.
- Серіалізуйте дії користувача та додайте їх разом із знімком стану до автоматизованих звітів про помилки, щоб розробники продуктів
могли відтворити їх для відтворення помилок.- Передайте об’єкти дій по мережі для реалізації середовищ спільної роботи без різких змін у тому, як пишеться код.
- Зберігайте історію скасування або впроваджуйте оптимістичні мутації без різких змін у тому, як пишеться код.
- Подорожуйте між історією стану в розробці та переоцініть поточний стан з історії дій, коли код змінюється, a la TDD.
- Забезпечте повний огляд та контроль можливостей для розробки інструментів, щоб розробники продуктів могли створювати власні інструменти для своїх
додатків.- Надайте альтернативні інтерфейси користувача, використовуючи при цьому більшість бізнес-логіки.
Завдяки цим багатьом додаткам ще занадто рано говорити про те, що Redux буде замінений новим API контексту
Якщо ви використовуєте Redux лише для уникнення передачі реквізиту до глибоко вкладених компонентів , ви можете замінити Redux на ContextAPI. Він саме призначений для цього випадку використання.
З іншого боку, якщо ви використовуєте Redux для всього іншого (мати передбачуваний контейнер стану, керувати логікою вашого додатка поза компонентами, централізувати стан програми, використовувати Redux DevTools для відстеження, коли, де, чому і як стан вашої програми змінивши або використовуючи плагіни, такі як Redux Form , Redux Saga , Redux Undo , Redux Persist , Redux Logger тощо…), то немає абсолютно ніяких причин відмовлятися від Redux. ContextAPI не надає будь - якого з цього.
І я особисто вважаю, що розширення Redux DevTools є дивовижним, заниженим інструментом налагодження, який виправдовує себе, продовжуючи використовувати Redux.
Деякі посилання:
Я вважаю за краще використовувати redux з функцією redux-thunk для здійснення дзвінків API (також використовуючи Axios) та відправлення відповіді на редуктори. Це чисто і легко зрозуміти.
API контексту дуже специфічний для частини реакції-редукції щодо того, як компоненти React підключаються до магазину. Для цього добре реагувати-редукція. Але якщо ви хочете, оскільки Context офіційно підтримується, ви можете використовувати API контексту замість react-redux.
Отже, питання повинно бути в контексті API Context vs react-redux, а не Context API vs redux. Також питання злегка сумнівно. Оскільки я знайомий з реагуванням-редуксом і використовую його у всіх проектах, буду продовжувати його використовувати. (Для мене немає стимулу змінюватися).
Але якщо ви сьогодні вивчаєте редукс, і ви його ніде не використовували, варто спробувати API контексту та замінити реакцію-редукцію на свій спеціальний код API контексту. Можливо, так набагато чистіше.
Особисто це питання знайомства. Немає чітких причин вибирати одне над іншим, оскільки вони рівнозначні. І внутрішньо, реакція-редукс використовує Context так чи інакше.
Єдині причини використовувати Redux для мене:
Ймовірно, вам не потрібен рівень непрямості для всього вашого додатка, тому добре змішувати стилі та використовувати локальний стан / контекст та Redux одночасно.
- Якщо вам потрібно використовувати проміжне програмне забезпечення для різних цілей. Наприклад, реєстрація дій, повідомлення про помилки, відправлення інших запитів залежно від відповіді сервера тощо.
- Коли дані, що надходять з декількох кінцевих точок, впливають на один компонент / представлення.
- Коли ви хочете мати більший контроль над діями у своїх програмах. Redux дозволяє відстежувати дії та зміни даних, це значно спрощує налагодження.
- Якщо ви не хочете, щоб відповідь сервера безпосередньо змінила стан вашої програми.Redux додає шар, де ви можете вирішити, як, коли і якщо ці дані слід застосовувати. Шаблон спостерігача. Замість створення декількох видавців та передплатників у всьому додатку ви просто підключите компоненти до магазину Redux.
duixпакет npm. Це лише простий менеджер штатів із зворотними дзвінками, дійсно простий у виконанні. Просто, щоб було зрозуміло: я творець.