Як зауваження: я прочитав документи для Redux (також Baobab), і я зробив неабияку частку в Google і тестуванні.
Чому так наполегливо пропонується, що програма Redux має лише один магазин?
Я розумію плюси та мінуси налаштування одного магазину проти декількох налаштувань магазину ( на цю тему існує багато запитань і відповідей ).
IMO, це архітектурне рішення належить розробникам додатків виходячи з потреб їх проектів. То чому ж так наполегливо пропонується Redux, майже до того, що звучить обов'язково ( хоча нас нічого не заважає зробити кілька магазинів )?
EDIT: відгуки після переходу на одноразовий магазин
Після кількох місяців роботи з наддувом над тим, що багато хто вважатиме складним СПА, я можу сказати, що структура єдиного магазину була чистим захопленням працювати.
Кілька моментів, які можуть допомогти іншим зрозуміти, чому один магазин проти багатьох магазинів є суперечливим питанням у багатьох, багатьох випадках використання:
- це надійно : ми використовуємо селектори, щоб перекопати стан програми та отримати інформацію, що стосується контексту. Ми знаємо, що всі необхідні дані знаходяться в одному магазині. Це дозволяє уникнути будь-яких сумнівів щодо того, де можуть бути державні питання.
- це швидко : наш магазин наразі має близько 100 редукторів, якщо не більше. Навіть при такому підрахунку лише декілька редукторів обробляють дані про будь-яку відправлення, інші просто повертають попередній стан. Аргумент про те, що величезний / складний магазин ( кількість редукторів ) є повільним, є суперечливим. Принаймні, ми не бачили жодних проблем із продуктивністю, які надходять звідти.
- дружнє налагодження : хоча це найбільш переконливий аргумент для використання скорочення в цілому, це також стосується одного магазину проти кількох магазинів. Створюючи додаток, у вас обов'язково виникають помилки стану в процесі ( помилки програміста ), це нормально. PITA - це коли на помилки потрібні години для налагодження. Завдяки єдиному магазину ( та увімкненому реєстратору ) ми ніколи не витрачали більше ніж кілька хвилин на будь-яку проблему стану.
кілька покажчиків
Справжня проблема у створенні магазину редукцій - це вирішення питання про його структурування . По-перше, тому що зміна структури в дорозі - це лише головний біль. По-друге, тому що він значною мірою визначає, як ви будете використовувати та запитувати дані додатків для будь-якого процесу. Є багато пропозицій щодо структури магазину. У нашому випадку ми виявили ідеальне:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}
Сподіваємось, цей відгук допоможе іншим.
EDIT 2 - корисні інструменти магазину
Для тих із вас, хто замислювався про те, як «легко» керувати єдиним магазином , який швидко може скластись. Існують інструменти, які допомагають ізолювати структурні залежності / логіку вашого магазину.
Існує Normalizr, який нормалізує ваші дані на основі схеми. Потім він надає інтерфейс для роботи з вашими даними та отримання інших частин ваших даних id, подібно до словника.
Не знаючи на той час Normalizr, я щось будував за тими ж лініями. relational-json приймає схему і повертає інтерфейс на основі таблиці ( трохи схожий на базу даних ). Перевага реляційного json полягає в тому, що ваша структура даних динамічно посилається на інші частини ваших даних ( по суті, ви можете переміщати свої дані в будь-якому напрямку, як і звичайні об'єкти JS ). Він не такий зрілий, як Normalizr, але я його успішно використовую у виробництві вже кілька місяців.