5 esempi di utilizzo ottimale di Ruby
Vi siete mai chiesti cosa possiamo fare con Ruby? Beh, il cielo è probabilmente il limite, ma siamo felici di parlare di alcuni casi più o meno noti...
Il giorno in cui è necessario familiarizzare con una tecnologia diversa è in realtà ogni giorno nella vita di uno sviluppatore. In questo particolare scenario, sono approdato a un progetto che si è rivelato essere l'ultimo all'interno dell'azienda che utilizza Redux per gestire lo stato nell'applicazione React.
Prima o poi, lo sposteremo nella sezione MobX stato, proprio come abbiamo fatto con le altre applicazioni. Per questo motivo ho deciso di dare un'occhiata veloce. Non ci sarà molto codice qui e credo che abbiate già sentito parlare di Redux. Cominciamo.
Come indicato in redux.js.orgè "uno stato prevedibile di contenitore per Applicazioni JS." È stato creato da Dan Abramov e Andrew Clark nel 2015.
Può essere descritto da 3 principi:
Non c'è da sorprendersi, MobX è anch'essa una libreria per la gestione degli stati, ma applica in modo trasparente la programmazione reattiva funzionale (TFRP) per renderla semplice e scalabile. Analogamente alla libreria precedente, la sua filosofia è descritta in 3 punti:
1. Semplicità: codice minimalista e privo di errori e non sono necessari strumenti speciali per utilizzarlo,
2. Rendering ottimale senza sforzo: si assicura che tutti i calcoli siano ottimizzati al meglio e non è necessario farlo manualmente,
3. Libertà architettonica: l'implementazione è libera e può essere utilizzata senza alcun framework per l'interfaccia utente.
React è noto per il serio boilerplate che circonda la configurazione iniziale. Non si può trascurare. Soprattutto quando si ha un'applicazione più grande, con molti riduttori e azioni, probabilmente si è già deciso di mantenere i tipi di azione come costanti nelle stringhe, il che è un buon approccio, ma poi c'è ancora più codice! Fortunatamente, la funzione Kit di strumenti Redux sta diventando sempre più popolare ed è ora raccomandato di scrivere Redux logica. Se lo chiedete a me, mi piace! C'è ancora molto da imparare, ma la semplice configurazione di base con il Toolkit è sufficiente.
Quando ho guardato il Documentazione MobXEro come un bambino atterrato per sbaglio in una fabbrica di cioccolato. Mentre scorrevo gli esempi, continuavo a chiedermi come potesse funzionare, ma lo fa e apparentemente lo fa bene. Ma forse gestire tutti i riduttori, le azioni, i middleware e altre cose rende così facile farsi affascinare da qualcos'altro. Tuttavia, se avete familiarità con l'OOP, MobX vi verrà naturale. La codifica iniziale è molto più limitata e molte cose avvengono dietro le quinte, quindi nella maggior parte dei casi non è necessario occuparsene.
In Reduxdobbiamo usare le primitive, gli array o il semplice JS come dati per il nostro stato.
Inoltre, c'è una pratica comune quando si memorizzano i dati in array, ovvero normalizzarli per motivi di prestazioni. Purtroppo, anche con le funzioni di aiuto del Toolkit di Redux (ad esempio, createEntityAdapter
) che aggiunge comunque codice aggiuntivo.
In MobX, si creano proprietà, interi oggetti, array, mappe e insiemi. osservabile.
Sì, le primitive non sono menzionate qui perché i loro valori in JS sono immutabili e per questo motivo devono essere trattati in modo diverso. Tutto quello che dovete sapere se scegliete una osservabile
è che avvolgerà la primitiva in una "scatola" e il getter e il setter del valore effettivo saranno disponibili tramite .get()
e .set(newValue)
rispettivamente vedere observable.box(value)
importare { observable, autorun } da "mobx".
const cityName = observable.box("Vienna") // come observable("Vienna")
autorun(() => {
console.log(cityName.get())
})
// Stampa: 'Vienna'
cityName.set("Amsterdam")
// Stampa: 'Amsterdam'
Non è necessaria la normalizzazione dei dati, in quanto MobX osservabile
clona l'oggetto, lo rende osservabile e, quindi, si assicura che tutte le modifiche si riflettano nell'archivio una volta aggiornate le proprietà osservabili.
Abbiamo un'unica fonte di verità in Redux. Mantenendo lo stato in un'unica posizione, ci assicuriamo che i dati non siano duplicati in tutta l'applicazione e che sia più facile eseguire il debug.
MobX incoraggia la presenza di almeno due archivi separati, uno per lo stato dell'interfaccia utente e uno o più per lo stato del dominio. Questa separazione ci permette di riutilizzare il dominio in diverse applicazioni.
Perché non siamo limitati a JS sembra naturale creare le proprie classi per particolari oggetti di dominio, come suggeriscono gli autori. Qui, Mobx brilla per coloro che amano la programmazione orientata agli oggetti. È possibile avere metodi, controllare ciò che deve essere osservabile o meno. Inoltre, è possibile combinare più negozi e condividere i riferimenti.
Redux richiede che l'aggiornamento dello stato non muta lo stato originale. Quindi, se vogliamo aggiungere un nuovo elemento a un array esistente, dobbiamo restituire una nuova istanza, invece di aggiungere semplicemente l'elemento a quello attuale.
function todoReducer(state = [], action) {
// qui creiamo un nuovo array e usiamo un operatore di spread per mantenere i vecchi valori
restituisce [
...stato,
azione.carico
]
}
Poi, in MobX, possiamo mutare le proprietà osservabili, qui: l'elemento todos
array. Notate che mutiamo l'array originale in aggiungiTodo
classe ObservableTodoStore {
todos = [];
costruttore() {
makeObservable(this, {
todos: osservabile,
addTodo: azione,
});
autorun(() => console.log(this.todos.length))
}
addTodo(task) {
/qui stiamo solo spingendo il nuovo elemento nell'array esistente!
this.todos.push({
compito: compito,
completato: false,
});
}
}
const observableTodoStore = new ObservableTodoStore();
observableTodoStore.addTodo("Una cosa difficile da fare");
Inoltre, possiamo anche aggiornare direttamente il file todo
e vedremo che autorun
verrà lanciato (noterà un cambiamento nell'array osservabile di todos
).
observableTodoStore.todos.push("Qualche altro compito difficile");
// La cosa più interessante è che solo quando si aggiorna la proprietà di un particolare todo
// MobX avvertirà (in modalità strict) che non è il caso di farlo direttamente
observableTodoStore.todos[1].task = ("Forse qualcosa di più semplice");
Personalmente, mi piace molto il Chrome Estensione dei Redux DevTools. Permette di dare una rapida occhiata allo stato dell'applicazione e ha la possibilità di andare avanti e indietro per ogni modifica dello stato (viaggio nel tempo!). Tutto ciò è possibile grazie al principio di non mutare lo stato precedente.
L'ulteriore livello di astrazione del negozio rende più difficile il processo di debug. Il Estensione MobX per Chrome mi sembra così macchinoso, soprattutto se confrontato con l'esperienza precedente, ma forse ho bisogno di un po' di tempo per abituarmi.
Ma abbiamo, ad esempio, la autorun
che probabilmente utilizzerete molto quando inizierete a usare il programma MobX e si vuole verificare quando lo stato cambia. È necessario notare che la funzione terrà traccia solo delle modifiche che osserva. Questo viene determinato una volta che la funzione viene eseguita per la prima volta. MobX si abbonerà a tutti gli osservabili che sono stati letti durante la prima invocazione e sarà attivato ogni volta che cambiano.
Se si considera la popolarità, qui prevale Redux. Vicino a 4M download da npm a settimana rispetto a 450k per MobX. Inoltre, il numero di collaboratori (~870 > 270) e di stelle (57k > 24k) sul repository di GitHub per ogni libreria mostra che Redux è un marchio ben noto.
D'altra parte, Rapporto sullo stato di JS 2020 mostra che la soddisfazione derivante dal loro utilizzo è pressoché uguale, quindi non vi aiuterà di certo a decidere quale scegliere per il vostro prossimo progetto.
Il grado di soddisfazione in questo grafico è stato descritto come "lo userei di nuovo / (lo userei di nuovo + non lo userei di nuovo)".
Non ci sono vincitori in questo concorso... ancora! BTW, non c'è stato alcun concorso 😉 Credo che entrambe le librerie stiano facendo un ottimo lavoro nel portare a termine il loro compito di base, che è quello di avere una gestione solida dello stato nel vostro computer. Applicazione JS . Avrò bisogno di più tempo per vedere come funziona il giornaliero con MobX differisce da Redux e per quali casi potrei raccomandarlo.
Per ora, posso dire che mi manca già il "viaggio nel tempo" dei DevTools di Redux, ma d'altra parte l'impostazione di uno stato con MobX sembra così semplice e il codice scritto appare molto più leggibile.
Tuttavia, sono così curioso di sapere come il osservabile
gestisce le prestazioni, poiché ogni volta che vedo una magia, mi chiedo quante risorse del mio PC (che si tratti di tempo della CPU, memoria o disco) vengano utilizzate e quanto sia efficiente. Questa sarà sicuramente la mia prossima fase di ricerca.
Spero di potervi rispondere con delle spiegazioni davvero entusiasmanti su come risolvere particolari problemi con MobX. Ci vediamo allora!