Основи Redux для початківців

Redux - Це інструмент для керування станом програми. Побудований на принципах технології Flux та функціонального програмування. Створений компанією FaceBook, але всупереч поширеній думці може використовуватися не тільки у зв'язці з React, але також з іншими фреймворками/бібліотеками.

Flux – це тип архітектури та набір патернів проектування веб-додатків. Детальніше на Wiki

Redux використовує методологію flux. Вона складається з 4 понять:

• Інтерфейс користувача (View) - у React це компоненти
• Сховище (Store)
• Диспатчер
• Action

У React за умовчанням немає якогось глобального state (стану), який був би доступний у всьому додатку. Ви можете лише зберігати дані в межах одного компонента. Наприклад, у вас є інтернет-магазин і в ньому є кошик з товарами. Якщо працювати тільки зі стейтом компонента Кошик, то ці дані будуть недоступні в інших компонентах. Також, наприклад, у вас є іконка кошика в кутку екрана, яка повинна показувати кількість товару, які користувач додав туди. Так от засобами чисто React, це буде складно реалізувати.

Саме тому є такі бібліотеки як Redux, для зберігання всіх даних програми в одному місці та зручного їх оновлення.

Основні поняття Redux

Як я вже писав вище, основні поняття редаксу actions, dispatcher, store.

Store - Це стан веб-компонента, який зберігає в собі всю інформацію (або ту, яку ви вирішили зберегти в нього). Надалі сторінка буде доступна з будь-якого компонента вашої програми.

Action - Дія, що визначає що потрібно зробити. Відповідно до принципів функціонального програмування, ми не можемо змінювати об'єкт безпосередньо, тому нам потрібні екшени, щоб передати їх у диспатчер і «сказати», що потрібно зробити.

Dispatcher — повідомляє сховищу про якусь дію (action) та передає йому оновлену інформацію.

Тепер коли ми розібрали основні поняття, давайте подивимося, як працює Redux:

Схема роботи Redux

Компонент генерує дію (action), диспатчер повідомляє про це сховище (store), сховище змінює стан та дані передаються в компонент (View).

Є ще одне поняття у Redux – це reducer (редюсер). Редюсер – це чиста функція, яка приймає як аргумент сховище та екшен. Основні правила редюсерів:

• У цих функціях повинно бути «side effects» (побічних ефектів). Наприклад, не можна робити API запит для отримання будь-яких даних
• Вони не повинні мутувати (змінювати) прийняті аргументи чи стан.
• Не можна викликати нечисті функції всередині редюсерів (наприклад, Date.now() або Math.random())

Докладніше про чисті функції можна прочитати тут.

Простий приклад використання Redux

Тепер на простому практичному прикладі розберемо, як працювати з Redux.

Ми зробимо простий додаток ToDo, який дасть можливість створювати свої таски зі збереженням їх у store. Це буде простий додаток для прикладу, основний наголос зроблений на роботу з Redux.

Отже, є два варіанти, ви можете завантажити стартовий проект і просто запустити установку, або покроково пройти і створити проект зі старту.

Встановлення та налаштування проекту

Щоб створити програму заново, відкриваємо командний рядок або Git Bash

npx create-react-app redux-first-app

Далі заходимо в папку проекту та встановлюємо Redux та пакет для Реакту – react-redux

cd redux-first-app/ // Потім npm i redux react-redux

Якщо ви завантажили архів з готовим додатком, тоді його потрібно розпакувати, увійти в папку з додатком і в командному рядку/терміналі запустити команду:

Тепер, щоб запустити наш проект, потрібно скористатися наступною командою:

Проект буде зібраний та запущений, автоматично відкриється вкладка у браузері

Результат виконання команди npm run start

Для того, щоб не верстати все знову, ми використовуємо Bootsrap. Давайте його встановимо.

npm install react-bootstrap bootstrap

Також підключимо стилі у файлі src/index.js

import React from 'react'; import ReactDOM від 'react-dom'; import './index.css'; import App from './App'; import reportWebVitals від './reportWebVitals'; import 'bootstrap/dist/css/bootstrap.min.css'; ReactDOM.render( 
, document.getElementById('root') ); reportWebVitals();

Створення базової структури для сховища

Тепер зробимо базову структуру для Redux. Створимо папку src/store, а в ній 4 файли

• actions.js
• actionTypes.js
• reducer.js
• store.js

Спочатку визначимо, які типи екшенів нам потрібні у файлі actionTypes.js. Можна типи і не визначати, але надалі це дасть нам змогу скоротити час на дебагінг, якщо раптом знадобиться змінити ім'я екшену, всі вони знаходяться в одному місці, що теж зручно. Якщо нам знадобиться екшен в іншому місці, нам буде достатньо імпортувати його в іншому модулі.

У нашому додатку, наприклад, нам потрібен буде екшен у 2 файлах: actions та reducer. Створимо файл actionTypes.js і в ньому визначимо наші типи:

export const TASK_ADD = 'TASK_ADD'; export const TASK_TOGGLE = 'TASK_TOGGLE'; export const TASK_REMOVE = 'TASK_REMOVE';

У файлі store/actions.js ми опишемо всі екшени, які нам потрібні для застосування:

import * as actions from './actionTypes'; export const addTask = task => (<type: actions.TASK_ADD, payload: task>); export const toggleTask = (<type: actions.TASK_TOGGLE, payload:<id>>); export const removeTask = (< type: actions.TASK_REMOVE, payload: < id >>)

Вище ви бачите типову структуру екшену: це функція, яка повертає об'єкт із двома властивостями:

• type - Тип екшену (ми його визначали в actionTypes)
• payload - дані, які нам потрібно передати до редюсера

Тепер розглянемо функцію редюсер (store/reducer.js):

import * as actions from './actionTypes'; let lastId = 0; export default function reducer(state = [], action) < switch (action.type) < case actions.TASK_ADD: return [. state, < id: ++lastId, title: action.payload.title, completed: false, >]; case actions.TASK_TOGGLE: return state.map(task => < if (task.id === action.payload.id) return < . task, completed: !task.completed >return task; >); case actions.TASK_REMOVE: return state.filter(task => action.payload.id !== task.id); default: return state; > >

Тут ми імпортуємо наші типи екшенів, потім визначаємо змінну для того, щоб задавати ID кожному новому таску.

Сам reducer приймає як аргументи state (або дорівнює порожньому масиву) і екшен. Далі ми перевіряємо тип екшену і залежно від цього робимо певні маніпуляції зі стейтом.

Давайте розмеберемо з прикладу екшену TASK_ADD. При додаванні нового таска, нам необхідно зробити копію поточного стейту та додати до нього новий таск

Далі на підставі цього редюсера нам потрібно створити store за допомогою функції createStore. Створимо файл store.js з таким вмістом:

import < createStore > від 'redux'; import reducer від "./reducer"; const store = createStore( reducer, window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__() ); export default store;

* У мене також другим параметром додано слід. рядок

window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__()

Це для роботи плагіна для Chrome – Redux DevTools. Зручний плагін для дебагінгу.

Тепер після створення store, ми можемо використовувати його у будь-якому модулі нашого додатку.

Основні методи роботи зі store

• store.dispatch() - Диспатч будь-якого екшену
• store.getState() - Отримання даних, які зберігаються в store
• store.subscribe() - Підписка на зміни store.

Redux у функціональних компонентах (хукі)

Наш додаток буде побудовано за допомогою функціональних компонентів та хуків, тому ми трохи розглянемо, які хуки надає нам Redux для роботи в таких компонентах.

• useDispatch() — заміна mapDispatchToProps(). Цей хук повертає метод dispatch. За його допомогою ми потім можемо диспатчити потрібні екшени.
• useSelector() — аналог mapStateToProps() — Цей хук приймає колбек, який як аргумент приймає поточний стан. Ви можете повернути весь state або певні дані з нього.
• useStore() - цей хук повертає посилання на той самий state, який був переданий в . У документації редаксу йдеться про те, що краще цей хук не використовувати часто, а краще useSelector()

Тепер давайте повернемося до нашої програми. В index.js нам потрібно обернути нашу програму в компонент Provider і передати йому store через пропси. Store ми створили у файлі store/store.js

import React from 'react'; import ReactDOM від 'react-dom'; import < Provider >from 'react-redux'; import './index.css'; import App from './App'; import reportWebVitals від './reportWebVitals'; import 'bootstrap/dist/css/bootstrap.min.css'; import store from './store/store'; ReactDOM.render( >


, document.getElementById('root') ); reportWebVitals();

Наступним кроком давайте створимо папку, в якій зберігатимемо наші компоненти і назвемо її componetns. У ній створимо 3 файли:

• Task.js — цей компонент відповідатиме за виведення окремого тяга
• TaskList.js - це буде список тяган
• AddNewTask.js — а цей компонент відповідатиме за створення нового тяга

import React від "react"; import < useDispatch >з "react-redux"; import < Form, ListGroup >з "react-bootstrap"; import < toggleTask, removeTask >з "../store/actions"; const Task = (< task >) => < const < id, title, completed >= task; const dispatch = useDispatch(); // Отримуємо диспатч із хука return ( > checked= onChange= < () =>dispatch(toggleTask(id)) > // диспатчім потрібний екшен під час кліку по тяганню 

dispatch(removeTask(id))>>Видалити // Диспатчі екшен removeTask для видалення тяга зі стору
  ) > export default Task;

Спочатку імпортуємо хук useDispatch(), т.к. у цьому компоненті ми будемо диспатчити 2 екшени: виконання таска (toggleTask) та видалення (removeTask). У компоненті у нас є подія onChange - при кліку на цей компонент ми будемо диспатчити екшен для перемикання стану таска, ну а при кліку кнопки видалити - диспатчім екшен для видалення таска з нашого стору.

Далі файл src/components/TaskList.js

import React from 'react'; import < ListGroup >з "react-bootstrap"; import Task from './Task'; // імпортуємо компонент таска, створений раніше const TaskList = (< tasks >) => < if (tasks.length) return ( 
< // пробегаемся методом map по нашему массиву с тасками и выводим для каждый таск tasks.map(task => task= /> ) > ) else return null; > export default TaskList;

Тепер останній компонент AddNewTask.js

import React, < useState > from 'react'; import < Button, FormControl, InputGroup >з "react-bootstrap"; import * as actions from "../store/actions"; import < useDispatch >з "react-redux"; const AddNewTask = () => < const [taskTitle, setTaskTitle] = useState(''); const dispatch = useDispatch(); const handleTaskTitleChange = (e) => < setTaskTitle(e.target.value); >const handleTaskSubmit = () => < dispatch(actions.addTask(< title: taskTitle >)); setTaskTitle(''); > return (  onChange=handleTaskTitleChange(e)> /> >Зберегти 
 ) > export default AddNewTask;

Тут у нас буде 2 обробники handleTaskTitleChange() і handleTaskSubmit() Останній буде диспатчити екшен для створення нового тяга.

Тепер залишився заключний крок, змінити файл scr/App.js та додати трохи стилів

import React from 'react'; import < Container, Colw >from "react-bootstrap"; react-redux"; import './App.css'; function App() < // Отримуємо наш state const tasks = useSelector(state =>state); 



>
Список завдань
 />

 ); > export default App;

У результаті у нас вийшов такий додаток

Запитання з міткою [redux]

Бібліотека для JavaScript з відкритим вихідним кодом, призначена для керування станом програми. Найчастіше використовується у зв'язці з React або Angular для розробки клієнтської частини.

• Конкурсні 0
• Невідповідні
• Цитовані
• Рейтинг
• Популярні
• За тиждень
• За місяць
• Невідповідні (мої мітки)

Проблема з redux, не бачить store.

Намагаюся зробити щоб модалка завантажувалася окремим чанком і потім довелося через це міняти slice Знайшов таку статтю в документації Redux Toolkit code spliting import < combineReducers, Reducer, .

Чому запит, який ініційований інвалідуванням тега надсилається зі старим access токеном? Rtk query

У мене є форма оновлення даних користувача (нікнейму та аватара) і коли я роблю запит на сервер для оновлення переданих даних, у мене інвалід тег 'User' і робиться новий запит на .

Як оптимізувати перемальовування реактивних компонентів?

У мене є компонент сторінки Events всередині якої лежить компонент EventFilter. При першому завантаженні кожна з них перемальовується 6 разів. Якщо закоментувати EventFilter, то компонент Events .

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

При перезавантаженні сторінки, у мене обнулюється favorite. І якщо стояв лайк, то він не стоїть, хоча лічильник і всі дані отримані з data вірні файли з помилкою: import < Link, useNavigate, useParams >.

Питання з архітектури FSD (Feature Slice Design)

Освоюю Feature Slice Design та намагаюся застосувати архітектуру, методологію FSD на своєму особистому проекті. У додатку бувають різні тоггли, перемикання і тд, ось у мене зараз є тоггл по .

Некоректно працює функція через асинхронність React+Redux

Така проблема. Є код, в ньому функція resultToColor().Код з пет-проекту, звичайна гра в колесо червоне-чорне Функція виводить колір, який прийшов із сервера і пішов у redux-state. Зараз вона.

Використовуючи функцію connect з react-redux не передаються пропси компонент

Ось весь код, який відповідає за логінізацію на сайті import < Field, reduxForm >from "redux-form" import < withElement >from "../common/FormsControl/FormsControls" import < .

TS2769: No overload matches this call

Тільки почав вивчати TypeScript і зіткнувся з такою помилкою: Overload 1 of 3, (thunkAction: ThunkAction, unknown, ActionsTypes>): unknown , стріляти .

Помилка в типізації dispatch

Підкажіть, хто стикався з такою помилкою при роботі з createAsyncThunk? Argument of type 'AsyncThunkAction>' is not assignable to parameter of type 'AnyAction'

Поле введення тексту втрачає фокус після введення символу

Намагаюся зробити простий додаток, який відображатиме на сторінці введений текст. По-перше, введений текст не відображається. По-друге, поле введення втрачає фокус після кожного введеного .

Де зберігати багато картинок для сайту на React? [закритий]

Я зелений новачок. Розробляю pet-проект на React суть якого – велика галерея картинок. Зіткнувся із запитанням, де мені всі ці картинки зберігати. Невже потрібно кожне зображення додавати до .

Як кешувати дані компонента у react сесії?

Зупинився використання redux. Є сторінка на сторінці приблизно 5 фільтрів. Кожен фільтр - це колекція, яка підвантажується з API. Реалізував зберігання отриманих даних для КОЖНОГО фільтра.

Конфлікт React та react-redux

Я закінчив проект, який легко запускається локально на комп'ютері. Але при спробі вивантажити його на Vercel отримав таку помилку: Я пробував по-різному вирішити цю проблему. І за допомогою -legacy-.

Не працює mock-server MSW та RTK хук висить у стані pending

Пишу тест, який перевірятиме роботу хука з Redux RTK Query. Намагався зробити mock сервер використовуючи MSW бібліотеку, але з якоїсь причини сервер не працює, а хук при запиті висить у стані .

Redux проти MobX без плутанини

В останні роки я часто використовував Redux, але останнім часом використовую MobX як альтернативу керуванню станом. Здається, що альтернативи Redux природно перетворюються на безлад. Люди не впевнені, яке рішення вибрати. Проблема не обов'язково "Redux vs MobX". Щоразу, коли існує альтернатива, людям цікаво, як найкраще вирішити їхню проблему. Я пишу ці рядки, щоб усунути плутанину навколо рішень щодо управління станами Redux та MobX.

Про що буде ця стаття? По-перше, я хочу коротко повернутися до проблеми, яку вирішує бібліотека управління станом. Зрештою, все буде добре, якщо ви просто використовуєте this.setState() і this.state в React або його варіацію в іншій бібліотеці рівня вистави або в середовищі SPA. По-друге, я продовжуватиму давати вам огляд обох рішень, показуючи послідовність та відмінності. І останнє, але не менш важливе: якщо у вас вже є програма, яка працює з MobX або Redux, я хочу розповісти вам про рефакторинг з однієї в іншу бібліотеку управління станами.

Яку проблему вирішуємо?

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

В даний час статус-кво полягає в побудові фронтенд-додатку з компонентами. Компоненти мають внутрішній стан. У зростаючому додатку управління станом може стати хаотичним з локальним станом, оскільки:

• компонент повинен ділитися станом з іншим компонентом
• компонент повинен видозмінити стан іншого компонента

Рішення, таким чином, полягає в тому, щоб ввести бібліотеку керування станом, таку як MobX або Redux. Вона дає вам інструменти для збереження вашого стану, зміни стану та отримання оновлень стану. У вас є одне місце для пошуку, одне місце для зміни та одне місце для отримання оновлень стану. Він дотримується принципу єдиного джерела правди. Це полегшує міркування щодо змін вашого стану та станів, тому що вони відокремлюються від ваших компонентів.

Бібліотеки управління станом, такі як Redux та MobX, часто мають доповнення до утиліт, наприклад, для Angular вони мають angular-redux та mobx-angular, щоб дати вашим компонентам доступ до стану. Часто ці компоненти називають контейнерними компонентами або, якщо бути точнішим, пов'язаними компонентами. З будь-якої точки вашої ієрархії компонентів ви можете отримати доступ до стану та змінити його, оновивши свій компонент до пов'язаного.

У чому різниця між REDUX та MOBX?

Перед тим, як ми поринемо в різницю, я хочу розповісти вам про схожість між MobX та Redux.

Обидві бібліотеки використовуються для керування станом у JavaScript-додатках. Вони не обов'язково пов'язані з бібліотекою, як Angular. Вони також використовуються в інших бібліотеках, таких як ReactJs та VueJs.

Якщо ви виберете одне з рішень щодо керування станом, ви не зіткнетеся з блокуванням постачальника. Ви можете у будь-який час перейти на інше рішення щодо управління станом. Можна перейти з MobX на Redux або з Redux на MobX. Згодом я продемонструю вам, як це відбувається.

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

На Redux впливають принципи функціонального програмування (FP). FP може бути зроблено на JavaScript, але багато людей походять з об'єктно-орієнтованого фону, як Java, і мають труднощі у прийнятті принципів функціонального програмування в першу чергу. Пізніше це пояснює, чому MobX може бути легко освоїти як новачок.

Оскільки Redux включає функціональне програмування, він використовує чисті функції.

Чиста функція — функція, яка отримує вхід, повертає вихід і не має інших залежностей, крім таких самих функцій. Така функція робить завжди той самий вихід з тим самим входом і не має жодних побічних ефектів. Докладніше.

(state, action) => NewState

Ваш стан Redux є незмінним. Замість того щоб мутувати, ви завжди повертаєте новий стан. Ви не виконуєте мутацій стану та не залежите від посилань на об'єкти.

 // не робіть цього в Redux, тому що він мутує масив function addAuthor(state, action) < return state.authors.push(action.author); >// залишайтеся незмінним і завжди повертайте новий об'єкт function addAuthor(state, action)

І останнє, але не менш важливе: в ідіоматичному Redux ваше стан нормалізованояк у базі даних. Сутності посилаються один на одного тільки за id. Це найкраща практика. Незважаючи на те, що не все так роблять, ви можете використовувати бібліотеку типу normalizr для досягнення такого нормалізованого стану. Нормалізований стан дозволяє вам зберігати плоский стан та сутності як єдине джерело істини.

Для порівняння, на MobX Мішеля Вестстрата впливає не лише об'єктно-орієнтоване програмування, а й реактивне програмування. Він обгортає ваш стан у об'єкти, що спостерігаються. Таким чином, у вас є всі можливості "Observable" у вашому стані. Дані можуть мати прості сеттери та гетери, але спостерігається дозволяє отримувати оновлення після зміни даних.

У Mobx ваше стан мінливий. Таким чином, ви змінюєте стан безпосередньо:

function addAuthor(author)

З іншого боку, організації залишаються у (глибоко) вкладеної структурі даних стосовно друг до друга. Ви не нормалізуєте свій стан. Стан залишається денормалізованим та вкладеним.

Одне сховище проти кількох

У Redux ви зберігаєте весь свій стан у одному глобальному сховищі або в одному глобальному стані. Єдиний об'єкт стану — ваше єдине джерело правди. Численні редуктори, з іншого боку, дозволяють йому змінювати незмінний стан.

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

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

Як виглядає реалізація?

У Redux для додавання конфігурації програми до глобального стану знадобляться наступні рядки коду.

const initialState = < users: [ < name: 'Alex' >, < name: 'Nik' >] >; // reducer function users(state = initialState, action) < switch (action.type) < case 'USER_ADD': return < . state, users: [ . state.users, action.user]>; default: return state; > > // action < type: 'USER_ADD', user: user >;

У сховищі MobX буде керувати лише станом (як редуктор у Redux управляє станом), але ви можете безпосередньо змінювати стан. Анотація @observable дозволяє спостерігати зміни стану.

Тепер можна викликати userStore.users.push(user); на екземплярі магазину. Тим не менш, рекомендується зберігати мутації стану більш очевидними за допомогою дій.

class userStore < @observable users = [ < name: 'Nikita' >]; > @action addUser = (user) =>

Ви можете суворо застосувати його, налаштувавши MobX за допомогою configure();. Тепер можна змінити свій стан, викликавши userStore.addUser (user); на екземплярі магазину.

Ви бачили, як оновлювати стан як у Redux, так і MobX. У Redux ваш стан доступний тільки для читання. Ви можете змінити стан лише за допомогою явних дій. На відміну від цього, у MobX стан включає читання та запис.Ви можете мутувати стан безпосередньо, не використовуючи дії, але можна вибрати явні дії, використовуючи конфігурацію примусових дій (enforceActions).

Крива навчання станом React

І Redux, і MobX в основному використовуються у програмах React. Але це автономні бібліотеки для керування станом, які можна використовувати скрізь без React. Їхні бібліотеки взаємодії дозволяють легко комбінувати їх з компонентами Angular. Це react-redux для React + Redux та mobx-react для React + MobX. Пізніше я поясню, як використовувати обидва компоненти Angular в дереві.

У недавніх дискусіях траплялося так, що люди сперечалися про криву навчання у Redux. Часто це відбувалося у контексті React: люди почали вивчати React і вже хотіли використовувати керування станом із Redux. Більшість людей стверджують, що React та Redux самі мають хорошу криву навчання, але обидва разом можуть бути приголомшливими. Тому альтернативою буде MobX, тому що він більше підходить для початківців.

Тим не менш, я б запропонував інший підхід для користувачів React початківців для вивчення управління станом в екосистемі React. Почніть вивчати React зі своїми власними локальними функціями керування станом у компонентах. У React ви спочатку вивчите методи життєвого циклу React і розберетеся з керуванням локальними станами за допомогою setState() і this.state. Я дуже раджу цей шлях навчання. В іншому випадку ви будете швидко перевантажені екосистемою React. Зрештою, на цьому шляху ви зрозумієте, що керування (внутрішнім) станом компонентів стає складним.

Redux чи MobX для новачків?

Ознайомившись із компонентами Angular та внутрішнім керуванням станом, ви можете вибрати бібліотеку керування станом для вирішення вашої проблеми. Після того, як я використовував обидві бібліотеки, я сказав би, що MobX може бути дуже зручний для початківців. Ми вже переконалися, що MobX потребує меншої кількості коду, хоча й використовує деякі магічні примітки, про які нам поки що знати не обов'язково.
У MobX Вам не потрібно бути знайомим із функціональним програмуванням. Такі терміни, як незмінність, можуть бути ще іноземними.

Функціональне програмування - це парадигма, що зростає, але нова для більшості людей в JavaScript. Існує чітка тенденція до цього, але оскільки не всі мають досвід функціонального програмування, людям з об'єктно-орієнтованим фоном, можливо, буде простіше прийняти принципи MobX.

Перехід на Redux

Як тільки ваш додаток стане більше і над ним працюватимуть кілька розробників, вам слід подумати про використання Redux. За своєю природою він зобов'язується використовувати явні дії зміни стану. Дія має тип та корисне навантаження, які редуктор може використовувати для зміни стану. У команді розробників дуже легко розмірковувати про зміни стану в такий спосіб.

Redux надає вам цілу архітектуру для керування станом із чіткими обмеженнями. Історія успіху Redux.

Ще однією перевагою Redux є його використання на стороні сервера. Оскільки ми маємо справу з простим JavaScript, ви можете надіслати стан по мережі. Серіалізація та десеріалізація об'єкта стану працює з коробки. Тим не менш, це можливо і в MobX.

MobX менш самовпевнений, але за допомогою configure (< empceActions: true >) ви можете застосовувати більш чіткі обмеження, як у Redux. Ось чому я не сказав би, що ви не можете використовувати MobX для масштабування додатків, але в Redux є чіткий спосіб зробити щось. Документація в MobX навіть говорить: «[MobX] не говорить вам, як структурувати ваш код, де зберігати стан або як обробляти події». Команда розробників мала спочатку створити архітектуру управління державою.

Зрештою, крива вивчення управління станом не така крута. Коли ми повторимо рекомендації, новачок у React спочатку навчиться правильно використовувати setState() та this.state. Через деякий час ви зрозумієте проблеми використання тільки setState() для підтримки стану у програмі React. При пошуку рішення ви стикаєтеся з бібліотеками керування станами, такими як MobX або Redux. Але який вибрати? Оскільки MobX менш самовпевнений, має менший шаблон і може використовуватися аналогічно setState(), я б порекомендував у невеликих проектах дати MobX шанс. Як тільки додаток збільшиться у розмірі та збільшить кількість учасників, ви повинні розглянути можливість застосування додаткових обмежень у MobX або надати Redux шанс. Мені сподобалося використати обидві бібліотеки. Навіть якщо ви не використовуєте один з них, має сенс побачити альтернативний спосіб управління станом.

Останні думки

Щоразу, коли я читаю коментарі в обговоренні Redux проти MobX, завжди є один коментар: «У Redux занадто багато стандартного зразка, натомість ви повинні використовувати MobX. Я зміг видалити XXX рядків коду».Коментар може бути правдою, але ніхто не рахує компроміс. Redux поставляється з великою кількістю шаблонів, таких, як MobX, тому що він був доданий для конкретних конструктивних обмежень. Це дозволяє вам міркувати про стан вашого додатку, навіть якщо він у ширшому масштабі. Уся церемонія, пов'язана з обробкою стану, проходить не так.

Бібліотека Redux є досить маленькою. Більшу частину часу ви маєте справу тільки з простими об'єктами та масивами JavaScript. Це ближче до ванільного JavaScript, ніж MobX. У MobX об'єкти і масиви обертаються в об'єкти, що спостерігаються, які приховують більшу частину стандартного шаблону. Він будується на прихованих абстракціях у яких відбувається чаклунство, але важче зрозуміти основні механізми. У Redux легше міркувати про це за допомогою простого JavaScript. Це полегшує тестування та налагодження програми.

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

У MobX він знову рухається у зворотному напрямку. Ми знову починаємо мутувати стан безпосередньо, не використовуючи переваг функціонального програмування. Для деяких людей це знову наближається до двосторонньої прив'язки даних. Через деякий час люди можуть знову зіткнутися з тими самими проблемами, перш ніж з'явилася бібліотека керування станом, наприклад Redux. Управління станом розкидано по компонентах і закінчується безладом.

У той час як у Redux у вас є встановлена ​​церемонія налаштування речей, MobX менш самовпевнений. Але було б розумно прийняти найкращий досвід у MobX.Люди повинні знати, як організувати управління станом, аби покращити аргументацію із цього приводу. Інакше люди схильні змінювати стан безпосередньо у компонентах.

Обидві бібліотеки чудові. Хоча Redux вже добре зарекомендував себе, MobX стає дійсною альтернативою для керування станом.