Redux заснований на 3 головних концепціях:
- Існує єдине джерело правди для всього стану програми.
- Цей стан тільки для читання.
- Всі зміни в стані додатки робляться чистими функціями.
При використанні в поєднанні з кращими практиками, розробленими спільнотою, ці принципи дозволяють створювати підтримувані і прості в тестуванні додатка до радості розробників.
Основні концепції
1. Єдине джерело істини
Незалежно від розміру програми, всі дані стану зберігаються в одному об'єкті. Про техніку управління ним у великому додатку буде сказано пізніше.
2. Стан тільки для читання
Рівень уявлень ніколи не буде безпосередньо маніпулювати станом вашого застосування. Наприклад, обробник додавання завдання до списку не зможе безпосередньо додати нове завдання в масив. Замість цього обробник відправить дію. казала: "Привіт, додаток. Пора додати завдання "Купити молока" в масив із завданнями. "
3. Зміни виробляються чистими функціями
Функція є чистою, коли вона завжди повертає однакове значення для однакового набору аргументів.
У чистій функції аргументи A і B завжди ведуть до результату C. Якщо функція не є чистою, то вона, отримавши A і B, може повернути не тільки C, але і D. Результат чистої функції зумовлений її вхідними аргументами і нічим більше. У чистих функцій немає побічних ефектів, так як вони не роблять мережевих запитів або запитів до баз даних. Також чисті функції не модифікують передані їм аргументи - замість цього вони розраховують результат і повертають його.
Продовжимо з нашим списком завдань: функція для дії 'ADD_TODO "не додає нове значення в масив завдань. У такому випадку вона не буде чистою, так як модифікує масив. Замість цього функція для 'ADD_TODO' створить копію масиву завдань, додасть нове завдання в кінець цього масиву і потім поверне новий масив як новий стан додатки.
Кращі практики
форма стану
Плоскі (однорівневі) об'єкти
Ми можемо зробити ще один крок вперед і створити окремий об'єкт, з індексними ідентифікаторами для наших завдань. Тепер наш список завдань буде представлятися в вигляді простого масиву ідентифікаторів.
Якщо ви опинитеся в пошуках способу зробити однорівневими запити JSON API для зберігання стану вашого застосування, вам варто використовувати бібліотеку Normalizr. допомагає робити JSON однорівневим.
Зберігайте дії невеликими! Кожна дія має містити тільки мінімальну інформацію, необхідну для трансформування стану програми. Наприклад, кожна задача в нашому додатку включає логічне значення completed. Так як ми знаємо, що поле completed завжди буде в значенні false для нового завдання, нам не потрібно ставити це поле в дії 'ADD_TODO'.
Також в додатках React поширений перенесення логіки для створення дій з коду уявлень додатки до функцій, які можуть використовуватися різними частинами програми. Ці витягнуті функції називаються творці дій. Вони повинні розташовуватися окремо від ваших уявлень і редукторів. Творці дій дуже зручні для створення документації, так як вони надають повний список дій, які ваші компоненти можуть виробляти для модифікації стану програми.
Кнопка, що додає завдання в ваше додаток Redux може виглядати як ця, без використання творців дій.
Та ж логіка додатка буде виглядати наступним чином при використанні творців дій (в прикладі творцем дії є функція addTodo).
Помітили, що кнопці додавання завдання вже не потрібно знати наступний ідентифікатор завдання? Цією інформацією тепер займається творець дії addTodo. що дає можливість додавати об'єкти завдань іншим уявленням (елементам користувальницького інтерфейсу). Додатково творець дії addTodo спрощує додавання кнопки 'Feed Cat'. Скрипт, що містить творця дії надає список дій, доступних для наших уявлень.
Так як наші редуктори повинні бути чистими, творці дій це гарне місце для коду з побічними ефектами або викликами асинхронних функцій. І, так як наші творці дій відокремлені від логіки уявлень, це спрощує тестування всього програми.
На самому початку ми створили редуктор для управління завданнями в додатку:
Щоб поєднати все це, ми створимо кореневої редуктор, який об'єднує об'єкти з відповідними редукторами в єдиному об'єкті стану.
- Зберігайте об'єкт стану однорівневим.
- Передавайте мінімально можливу кількість даних в діях.
- Використовуйте творців дій для відправки дій замість того, щоб створювати і відправляти їх безпосередньо з уявлень.
- Ваш кореневої редуктор повинен бути складений з менших редукторів, які керують окремими частинами стану програми.
Враховуйте ці поради при проектуванні і створенні додатків з Redux і ви не програєте.
тестування
Написання тестів для додатка Redux залишає досить приємні враження. Чисті редуктори полегшують розуміння того, який результат повинен бути у дії, а творці дій полегшують ізоляцію і тестування логіки додатка, задіяної в ваших виставах. Я збираюся використовувати бібліотеку expect. але це не єдиний фреймворк, який ви можете вибрати для тестування програми. У документації Redux рекомендується використовувати Mocha як движка для тестування.