Навіщо використовувати Redux через Facebook Flux? [зачинено]

Я прочитав цю відповідь , зменшивши котельну табличку , переглянув кілька прикладів GitHub і навіть спробував трохи зменшити (програми todo).

Наскільки я розумію, офіційні мотивації doc домен надають переваги порівняно з традиційними архітектурами MVC. Але НЕ дає відповіді на питання:

Чому слід використовувати Redux через Facebook Flux?

Це лише питання стилів програмування: функціональний проти нефункціональний? Або питання полягає у здібностях / інструментах для розробників, які випливають із редукційного підходу? Можливо масштабування? Або тестування?

Я маю рацію, якщо кажу, що редукс - це флюс для людей, які походять з функціональних мов?

Щоб відповісти на це запитання, ви можете порівняти складність впровадження мотиваційних балів redux на флюс та redux.

Ось мотиваційні моменти з офіційних мотивацій doc-редукцій :

1. Поводження з оптимістичними оновленнями ( як я розумію, це навряд чи залежить від 5-ї точки. Чи важко це реалізувати у флюс-флюсі? )
2. Візуалізація на сервері ( також може зробити це потік facebook. Будь-які переваги порівняно зі скороченням? )
3. Отримання даних перед виконанням маршрутних переходів ( Чому цього не можна досягти у флюс-флюсі? Які переваги? )
4. Гаряче перезавантаження ( можливе за допомогою React Hot Reload . Навіщо нам потрібен редукс? )
5. Скасувати / Повторити функціональність
6. Будь-які інші моменти? Наче збережена держава ...

Автор Redux тут!

Redux НЕ що відрізняється від флюсу. В цілому він має таку ж архітектуру, але Redux здатний вирізати кути складності, використовуючи функціональну композицію, де Flux використовує реєстрацію зворотних викликів.

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

Склад редуктора

Візьмемо, наприклад, пагинацію. На прикладі мого маршрутизатора Flux + React обробляються сторінки, але код для цього жахливий. Однією з причин, що це жахливо, є те, що Flux робить неприродним повторне використання функціональних можливостей у магазинах. Якщо двом магазинам потрібно обробляти пагинацію у відповідь на різні дії, вони або повинні успадковуватись із загального базового магазину (погано! Ви замикаєтесь у певному дизайні, коли використовуєте спадкування), або зателефонуйте зовнішньо визначеній функції зсередини обробник подій, якому потрібно якось працювати в приватному стані магазину Flux. Вся справа безладна (хоча, безумовно, у царині можливого).

З іншого боку, падінація Redux природна завдяки складу редуктора. Це редуктори аж донизу, тому ви можете написати заводські редуктори, які генерують редуктори пагінації, а потім використовувати їх у вашому дереві редукторів . Ключовим моментом, чому це так просто, є те, що в магазинах Flux плоскі магазини, а в Redux, редуктори можуть вкладатись за допомогою функціональної композиції, як і вбудовані компоненти React.

Цей візерунок також дозволяє чудові функції, такі як скасування / повторення коду, який не використовується користувачем . Чи можете ви уявити, як підключення Undo / Redo до програми Flux має два рядки коду? Навряд чи. З Redux це - знову , завдяки схемі композиції редуктора. Мені потрібно підкреслити, що в цьому немає нічого нового - це шаблон, вперше розроблений та докладно описаний в Elm Architecture, на який саме впливав Flux.

Надання сервера

Люди рендерують на сервері прекрасно за допомогою Flux, але бачачи, що у нас є 20 бібліотек Flux, кожна з яких намагається зробити візуалізацію сервера “простішою”, можливо, у Flux є деякі нерівні краї на сервері. Правда в тому, що Facebook не робить багато серверного рендерінгу, тому вони не дуже переймаються цим і покладаються на екосистему, щоб зробити це простіше.

У традиційному магазині Flux магазини є однотонними. Це означає, що важко розділити дані для різних запитів на сервері. Не неможливо, але важко. Ось чому більшість бібліотек Flux (як і нові утиліти Flux ) тепер пропонують використовувати класи замість одинарних клавіш, щоб ви могли інстанціювати магазини за запитом.

Є ще такі проблеми, які потрібно вирішити в Flux (самостійно або за допомогою вашої улюбленої бібліотеки Flux, таких як Flummox або Alt ):

• Якщо магазини - це класи, як я можу створити та знищити їх за допомогою диспетчера за запитом? Коли я реєструю магазини?
• Як я зволожую дані з магазинів і пізніше регідратюю їх на клієнта? Чи потрібно для цього застосовувати спеціальні методи?

Справді, у Flux фреймворк (не ванільний Flux) вирішує ці проблеми, але я вважаю їх складними. Наприклад, Flummox просить вас реалізувати serialize()і deserialize()у своїх магазинах . Alt вирішує це приємніше, забезпечуючи, takeSnapshot()що автоматично серіалізує ваш стан у дереві JSON.

Redux просто йде далі: оскільки існує лише один магазин (керується багатьма редукторами), вам не потрібен спеціальний API для управління (повторною) гідратацією. Вам не потрібно «змивати» або «зволожувати» магазини - є лише один магазин, і ви можете прочитати його поточний стан або створити новий магазин з новим станом. Кожен запит отримує окремий екземпляр магазину. Детальніше про надання сервера за допомогою Redux.

Знову ж таки, це можливо щось можливе як у Flux, так і в Redux, але бібліотеки Flux вирішують цю проблему, вводячи тону API та конвенцій, і Redux навіть не повинен її вирішувати, оскільки у неї немає цієї проблеми в перше місце завдяки концептуальній простоті.

Досвід розробників

Насправді я не мав наміру Redux стати популярною бібліотекою Flux - я написав це, коли працював над моєю розмовою ReactEurope щодо гарячого перезавантаження з подорожами у часі . У мене була одна головна мета: зробити можливим змінити код редуктора на ходу або навіть «змінити минуле», перекресливши дії, і переконатися, що держава перераховується.

Я не бачив жодної бібліотеки Flux, яка могла б це зробити. Реактивний гарячий навантажувач також не дозволяє вам цього робити, адже він редагується, якщо ви редагуєте магазини Flux, оскільки він не знає, що з ними робити.

Коли Redux потрібно перезавантажити код редуктора, він зателефонує replaceReducer(), і програма працює з новим кодом. У Flux дані та функції заплутані у магазинах Flux, тому ви не можете просто замінити функції. Більше того, вам доведеться якось перереєструвати нові версії Dispatcher - чогось Redux навіть не має.

Екосистема

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

Простота

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

Зробити це просто - це важливо, оскільки він забезпечує безпеку при здійсненні абстракцій вищого рівня.

На відміну від більшості бібліотек Flux, поверхня API Redux невелика. Якщо ви видалите попередження, коментарі та перевірку правильності розробника, це 99 рядків . Немає складного коду асинхронізації для налагодження.

Ви можете насправді прочитати його та зрозуміти все Redux.

Дивіться також мою відповідь щодо недоліків використання Redux порівняно з Flux .

У Quora хтось каже :

Перш за все, цілком можливо писати програми за допомогою React без Flux.

Також ця візуальна діаграма, яку я створив для швидкого перегляду обох, ймовірно, швидкої відповіді для людей, які не хочуть читати все пояснення:

Але якщо вам все-таки цікаво знати більше, читайте далі.

Я вважаю, що ви повинні почати з чистого реагування, а потім вивчити Redux та Flux. Після того, як у вас виникне РЕАЛЬНИЙ досвід з React, ви побачите, чи Redux корисний для вас чи ні.

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

Якщо ви почнете безпосередньо з Redux, у вас може виникнути надмірно спроектований код, який важче підтримувати та ще більше помилок і, ніж без Redux.

З документів Redux :

Мотивація
Оскільки вимоги до односторінкових додатків JavaScript стають все складнішими, наш код повинен керувати більш станом, ніж будь-коли раніше. Цей стан може включати відповіді сервера та кешовані дані, а також локально створені дані, які ще не зберігаються на сервері. Стан користувальницького інтерфейсу також збільшується по складності, оскільки нам потрібно керувати активними маршрутами, вибраними вкладками, спінерами, контролем сторінки, і так далі.

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

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

З цією складністю важко впоратися, оскільки ми змішуємо два поняття, про які людському розуму дуже важко міркувати: мутацію та асинхронність. Я називаю їх Ментос і Кокс. Обидва можуть бути чудовими, коли розлучаються, але разом вони створюють безлад. Бібліотеки на зразок React намагаються вирішити цю проблему на рівні перегляду, видаляючи як асинхронність, так і пряму маніпуляцію з DOM. Однак управління станом ваших даних залишається за вами. Сюди заходить Redux.

Слідуючи Flux, CQRS та Sourcing подій, Redux намагається зробити мутації стану передбачуваними, встановивши певні обмеження щодо того, як і коли можуть відбуватися оновлення. Ці обмеження відображені в трьох принципах Redux.

Також з документів Redux :

Основні поняття
Redux самі по собі дуже прості.

Уявіть, що ваш додаток описано як звичайний об'єкт. Наприклад, стан програми todo може виглядати приблизно так:

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

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

Щоб щось змінити в штаті, потрібно відправити дію. Дія - це звичайний JavaScript-об’єкт (зверніть увагу, як ми не вводимо ніякої магії?), Яка описує те, що сталося. Ось кілька прикладів дій:

{ type: 'ADD_TODO', text: 'Go to swimming pool' }
{ type: 'TOGGLE_TODO', index: 1 }
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

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

function visibilityFilter(state = 'SHOW_ALL', action) {
  if (action.type === 'SET_VISIBILITY_FILTER') {
    return action.filter;
  } else {
    return state;
  }
}

function todos(state = [], action) {
  switch (action.type) {
  case 'ADD_TODO':
    return state.concat([{ text: action.text, completed: false }]);
  case 'TOGGLE_TODO':
    return state.map((todo, index) =>
      action.index === index ?
        { text: todo.text, completed: !todo.completed } :
        todo
   )
  default:
    return state;
  }
}

І ми пишемо ще один редуктор, який керує повним станом нашої програми, викликаючи ці два редуктори для відповідних клавіш стану:

function todoApp(state = {}, action) {
  return {
    todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

Це в основному вся ідея Redux. Зауважте, що ми не використовували жодного API Redux. Він оснащений кількома утилітами для полегшення цього шаблону, але головна ідея полягає в тому, що ви описуєте, як ваш стан оновлюється з часом у відповідь на об’єкти дії, і 90% коду, який ви пишете, - це просто звичайний JavaScript, без використання Redux себе, його API або будь-яку магію.

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

По-друге, сторінка мотивації, на яку ви посилаєтесь, насправді не обговорює мотивації Redux настільки, як мотивації за Flux (і React). В Три принципі більш Redux конкретний , хоча до цих пір не має справи з відмінностями реалізацій від стандартної архітектури Flux.

По суті, Flux має декілька магазинів, які обчислюють зміну стану у відповідь на взаємодію UI / API з компонентами і транслюють ці зміни як події, на які можуть підписатися компоненти. У Redux є лише один магазин, на який підписується кожен компонент. ІМО відчуває, що принаймні, як Redux додатково спрощує і уніфікує потік даних, об'єднуючи (або зменшуючи, як би сказав Redux) потік даних назад до компонентів - тоді як Flux концентрується на об'єднанні іншої сторони потоку даних - з метою модель.

Я є ранньою особою, яка впроваджує середню велику програму на одній сторінці за допомогою бібліотеки Flux Facebook.

Оскільки я трохи запізнююся на розмову, я просто зазначу, що, незважаючи на мої найкращі сподівання, Facebook, здається, вважає їхню реалізацію Flux доказом концепції, і вона ніколи не отримувала уваги, яку вона заслуговує.

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

Ми вирішили, що рухаючись вперед, ми переходимо до Redux, і я пропоную вам зробити те саме;)

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

Для отримання додаткової інформації Flux vs Redux

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

З новим приймачем реагування / скорочення, який мігрує з (кілька років) ExtJS в середині 2018 року:

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

Незабаром я побачив переваги скорочення над потоком, як зазначено у відповідях вище, і працював над цим у своєму першому додатку.

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

Це було багато інтуїтивніше, ніж редукція ванілі, вона вирізала 90% котла і вирізала 75% часу, який я витрачав на редукцію (те, на що я думаю, що повинна робити бібліотека), я зміг отримати пару корпоративних додатків йде відразу.

Він також працює з тією ж редукційними інструментами. Це гарна стаття, яка висвітлює деякі переваги.

Тож для всіх, хто прийшов на цю посаду SO, шукаючи "простішу редукцію", я рекомендую спробувати її як просту альтернативу redux з усіма перевагами та 1/4 котлоагрегату.

Відповідно до цієї статті: https://medium.freecodecamp.org/a-realworld-comppare-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075

Краще використовувати MobX для управління даними у вашому додатку, щоб отримати кращу продуктивність, а не Redux.