Я нещодавно відкрив Redux . Це все добре виглядає. Чи є якісь недоліки, прихильність чи компроміси використання Redux over Flux? Дякую

Автор Redux тут!

Хочеться сказати, що ви збираєтесь робити наступні компроміси, використовуючи це:

• Вам потрібно буде навчитися уникати мутацій. Flux не підтримує мутацію даних, але Redux не любить мутацій, і багато пакунків, що доповнюють Redux, припускають, що ви ніколи не мутуєте стан. Ви можете застосувати це за допомогою пакетів, що розроблені лише для розробників, таких як redux-неизменяемый стан-інваріант , використовувати Immutable.js або довіряти собі та своїй команді для написання немутативного коду, але це щось, що вам потрібно знати, і це потрібно бути свідомим рішенням, прийнятим вашою командою.

• Вам доведеться ретельно вибирати ваші пакунки. Хоча Flux явно не намагається вирішити "сусідні" проблеми, такі як скасувати / повторити , наполегливість або форми , Redux має точки розширення, такі як програмне забезпечення середнього програмного забезпечення та магазину, і він породив молоду, але багату екосистему . Це означає, що більшість пакунків - це нові ідеї та ще не отримали критичної маси використання. Ви можете залежати від чогось, що буде явно поганою ідеєю через кілька місяців, але важко сказати поки що.

• У вас ще не буде приємної інтеграції Flow. На даний момент Flux дозволяє робити дуже вражаючі перевірки статичного типу, які Redux ще не підтримує . Ми туди потрапимо, але пройде певний час.

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

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

І Redux, і Flux потребують значної кількості кодового шаблону для покриття багатьох загальних зразків, особливо тих, що передбачають асинхронний збір даних. Документація Redux вже містить кілька прикладів скорочення котлів: http://redux.js.org/docs/recipes/ReducingBoilerplate.html . Ви можете отримати все, що може знадобитися, з бібліотеки Flux, наприклад, Alt або Fluxxor, але Redux віддає перевагу свободі над можливостями. Це може бути недоліком для деяких розробників, оскільки Redux робить певні припущення щодо вашого стану, які можуть бути ненавмисно проігноровані.

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

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

Флюс і Редукс . . .

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

Чому незмінність?

Причин тому мало:
1. Узгодженість - стан магазину завжди змінюється за допомогою редуктора, тому легко відстежувати, хто що змінить.
2. Продуктивність - оскільки це незмінне, Redux потрібно лише перевірити, чи попередній стан! == поточний стан і якщо так, щоб він надав. Немає необхідності циклічно концентрувати стан для певного відображення.
3. Налагодження - нові дивовижні концепції, такі як налагодження подорожей у часі та гаряча перезавантаження .

ОНОВЛЕННЯ: якщо це було недостатньо переконливим, дивіться, як Лі Байрон чудово розмовляє про незмінний інтерфейс користувача .

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

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

Після цього я маю визнати, що Redux - це те, куди йде майбутній розвиток JS (як для написання цих рядків).

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

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

Також Redux отримав більшу гнучкість, використовуючи інші популярні рамки, такі як Angular . Як би там не було, подивимось, як Redux представляє себе як рамки.

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

Єдине джерело істини

Стан всієї вашої програми зберігається в дереві об'єктів в одному магазині.

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

console.log(store.getState())

/* Prints
{
  visibilityFilter: 'SHOW_ALL',
  todos: [
    {
      text: 'Consider using Redux',
      completed: true,
    },
    {
      text: 'Keep all state in a single tree',
      completed: false
    }
  ]
}
*/

Держава доступна лише для читання

Єдиний спосіб змінити стан - це випромінювати дію, об’єкт, що описує те, що сталося.

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

store.dispatch({
  type: 'COMPLETE_TODO',
  index: 1
})

store.dispatch({
  type: 'SET_VISIBILITY_FILTER',
  filter: 'SHOW_COMPLETED'
})

Зміни вносяться за допомогою чистих функцій

Щоб вказати, як дерево стану трансформується діями, ви пишете чисті редуктори.

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

function visibilityFilter(state = 'SHOW_ALL', action) {
  switch (action.type) {
    case 'SET_VISIBILITY_FILTER':
      return action.filter
    default:
      return state
  }
}

function todos(state = [], action) {
  switch (action.type) {
    case 'ADD_TODO':
      return [
        ...state,
        {
          text: action.text,
          completed: false
        }
      ]
    case 'COMPLETE_TODO':
      return state.map((todo, index) => {
        if (index === action.index) {
          return Object.assign({}, todo, {
            completed: true
          })
        }
        return todo
      })
    default:
      return state
  }
}

import { combineReducers, createStore } from 'redux'
let reducer = combineReducers({ visibilityFilter, todos })
let store = createStore(reducer)

для отримання додаткової інформації відвідайте тут

Redux вимагають дисципліни щодо непорушності. Щось я можу порекомендувати - це заморожування ng, щоб повідомити про будь-які випадкові мутації стану.

Наскільки мені відомо, редукс надихається флюсом. flux - така архітектура, як MVC (контролер перегляду моделі). facebook вводить флюс через проблему масштабованості при використанні MVC. тому флюс - це не реалізація, це лише концепція. Власне редукційним є реалізація флюсу.