Di recente ho scoperto Redux . Sembra tutto a posto. Ci sono aspetti negativi, aspetti negativi o compromessi nell'uso di Redux over Flux? Grazie

Redux autore qui!

Vorrei dire che userete i seguenti compromessi:

• Dovrai imparare a evitare le mutazioni. Flux non èopinionato sui dati mutanti, ma a Redux non piacciono le mutazioni e molti pacchetti complementari a Redux presumono che non mutiate mai lo stato. Puoi imporlo con pacchetti solo per dev come redux-immutable-state-invariant , usare Immutable.js o affidarti a te stesso e al tuo team per scrivere codice non mutativo, ma è qualcosa di cui devi essere consapevole, e questo deve essere una decisione consapevole accettata dalla tua squadra.

• Dovrai scegliere con cura i tuoi pacchi. Mentre Flux non cerca esplicitamente di risolvere problemi "vicini" come annulla / ripristina , persistenza o moduli , Redux ha punti di estensione come middleware e potenziatori di negozi e ha generato un ecosistema giovane ma ricco . Ciò significa che la maggior parte dei pacchetti sono nuove idee e non hanno ancora ricevuto la massa critica di utilizzo. Potresti dipendere da qualcosa che sarà chiaramente una cattiva idea qualche mese dopo, ma è difficile da dire ancora.

• Non avrai ancora una buona integrazione Flow. Flux attualmente ti consente di eseguire controlli statici di tipo molto impressionante che Redux non supporta ancora . Ci arriveremo, ma ci vorrà del tempo.

Penso che il primo sia il più grande ostacolo per i principianti, il secondo può essere un problema per i primi utenti troppo entusiasti e il terzo è la mia pipì personale. A parte questo, non credo che l'uso di Redux apporti particolari inconvenienti che Flux evita, e alcune persone dicono che ha anche dei lati positivi rispetto a Flux.

Vedi anche la mia risposta agli aspetti positivi dell'utilizzo di Redux .

Sia Redux che Flux richiedono una notevole quantità di codice boilerplate per coprire molti modelli comuni, in particolare quelli che implicano il recupero asincrono dei dati. La documentazione di Redux ha già una manciata di esempi per la riduzione del boilerplate: http://redux.js.org/docs/recipes/ReducingBoilerplate.html . Puoi ottenere tutto ciò di cui potresti aver bisogno da una libreria Flux come Alt o Fluxxor, ma Redux preferisce la libertà alle funzionalità. Questo potrebbe essere un aspetto negativo per alcuni sviluppatori perché Redux fa alcune ipotesi sul tuo stato che potrebbero essere inavvertitamente ignorate.

L'unico modo per rispondere davvero alla tua domanda è provare Redux se puoi, magari in un progetto personale. Redux è nato a causa della necessità di una migliore esperienza degli sviluppatori ed è orientato verso la programmazione funzionale. Se non hai familiarità con concetti funzionali come riduttori e composizione delle funzioni, potresti essere rallentato, ma solo leggermente. Il vantaggio di abbracciare queste idee nel flusso di dati è il test e la prevedibilità più facili.

Disclaimer: sono migrato da Flummox (una popolare implementazione Flux) a Redux e gli aspetti positivi superano di gran lunga qualsiasi aspetto negativo. Preferisco molta meno magia nel mio codice. Meno magia ha un costo di un po 'più di potenza, ma è un prezzo molto piccolo da pagare.

Flux e Redux . . .

Redux non è un'implementazione di Flux pura ma sicuramente ispirata a Flux. La differenza più grande è che utilizza un singolo negozio che avvolge un oggetto stato contenente tutto lo stato per l'applicazione. Invece di creare negozi come farai in Flux, scriverai funzioni di riduzione che cambieranno lo stato di un singolo oggetto. Questo oggetto rappresenta tutto lo stato nella tua app. In Redux otterrai l'azione e lo stato correnti e restituirai un nuovo stato. Ciò significa che le azioni sono sequenziali e lo stato è immutabile. Ciò mi porta alla truffa più ovvia di Redux (secondo me).

Perché l'immutabilità?

Ci sono alcuni motivi per questo:
1. Coerenza : lo stato del negozio viene sempre modificato da un riduttore, quindi è facile rintracciare chi cambia cosa.
2. Prestazioni : poiché è immutabile, Redux deve solo verificare se lo stato precedente! == stato corrente e in tal caso renderizzare. Non è necessario eseguire il loop dello stato ogni volta per il rendering determinato.
3. Debug : nuovi fantastici concetti come il debug dei viaggi nel tempo e il ricaricamento rapido .

AGGIORNAMENTO: se ciò non fosse abbastanza convincente, guarda Lee Byron parlare in modo eccellente delle interfacce utente immutabili .

Redux richiede una disciplina per gli sviluppatori attraverso la base di codice / librerie per mantenere questa idea. Dovrai assicurarti di scegliere le librerie e scrivere il codice in modo non mutevole.

Se desideri saperne di più sulla diversa implementazione dei concetti di Flux (e su ciò che funziona meglio per le tue esigenze), dai un'occhiata a questo utile confronto.

Detto questo, devo ammettere che Redux è la destinazione del futuro sviluppo di JS (come per la scrittura di queste righe).

Uno dei maggiori vantaggi dell'utilizzo di Redux rispetto alle altre alternative di Flux è la sua capacità di riorientare il tuo pensiero verso un approccio più funzionale. Una volta capito come tutti i fili si collegano, ti rendi conto della sua straordinaria eleganza e semplicità nel design e non potrai più tornare indietro.

Preferisco usare Redux in quanto utilizza un negozio che rende la gestione dello stato molto più semplice rispetto a Flux , anche Redux DevTools è strumenti davvero utili che ti consentono di vedere cosa stai facendo con il tuo stato con alcuni dati utili ed è davvero in linea con gli strumenti di sviluppo di React.

Inoltre Redux ha una maggiore flessibilità grazie ad altri framework popolari come Angular . Comunque, vediamo come Redux si presenta come un framework.

Redux ha tre principi che possono introdurre Redux molto bene e sono anche la principale differenza tra Redux e Flux.

Singola fonte di verità

Lo stato dell'intera applicazione è archiviato in una struttura ad oggetti all'interno di un singolo archivio.

Ciò semplifica la creazione di app universali, poiché lo stato dal server può essere serializzato e idratato nel client senza ulteriore sforzo di codifica. Un singolo albero di stato semplifica inoltre il debug o l'ispezione di un'applicazione; ti consente inoltre di mantenere lo stato della tua app in fase di sviluppo, per un ciclo di sviluppo più rapido. Alcune funzionalità che sono state tradizionalmente difficili da implementare, ad esempio Annulla / Ripristina, possono improvvisamente diventare banali da implementare, se tutto il tuo stato è archiviato in un singolo albero.

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
    }
  ]
}
*/

Lo stato è di sola lettura

L'unico modo per cambiare lo stato è emettere un'azione, un oggetto che descriva ciò che è accaduto.

Ciò garantisce che né le viste né i callback di rete possano mai scrivere direttamente nello stato. Invece, esprimono l'intenzione di trasformare lo stato. Poiché tutti i cambiamenti sono centralizzati e avvengono uno ad uno in un ordine rigoroso, non ci sono condizioni di gara sottili a cui prestare attenzione. Poiché le azioni sono solo oggetti semplici, possono essere registrate, serializzate, archiviate e riprodotte successivamente a scopo di debug o test.

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

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

Le modifiche vengono apportate con funzioni pure

Per specificare come l'albero degli stati viene trasformato dalle azioni, scrivi riduttori puri.

I riduttori sono solo funzioni pure che accettano lo stato precedente e un'azione e restituiscono lo stato successivo. Ricordare di restituire nuovi oggetti stato, anziché mutare lo stato precedente. Puoi iniziare con un singolo riduttore e, man mano che la tua app cresce, suddividila in riduttori più piccoli che gestiscono parti specifiche dell'albero dello stato. Poiché i riduttori sono solo funzioni, è possibile controllare l'ordine in cui vengono chiamati, passare ulteriori dati o persino realizzare riduttori riutilizzabili per attività comuni come l'impaginazione.

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)

per maggiori informazioni visita qui

Redux richiede disciplina per quanto riguarda l'immutabilità. Qualcosa che posso consigliare è ng-freeze per farti conoscere qualsiasi mutazione accidentale dello stato.

Per quanto ne so, il redux si ispira al flusso. flux è un'architettura come MVC (controller vista modello). Facebook introduce il flusso a causa di problemi di scalabilità durante l'utilizzo di MVC. quindi il flusso non è un'implementazione, è solo un concetto. In realtà redux è l'implementazione del flusso.