Jawaban:
Penulis redux di sini!
Saya ingin mengatakan Anda akan membuat kompromi berikut untuk menggunakannya:
Anda harus belajar untuk menghindari mutasi. Flux tidak memiliki pilihan tentang mutasi data, tetapi Redux tidak menyukai mutasi dan banyak paket yang melengkapi Redux menganggap Anda tidak pernah bermutasi. Anda dapat menegakkan ini dengan paket dev-only seperti redux-immutable-state-invariant , menggunakan Immutable.js , atau percayai diri Anda sendiri dan tim Anda untuk menulis kode non-mutatif, tetapi itu adalah sesuatu yang perlu Anda waspadai, dan ini perlu Anda perhatikan. menjadi keputusan sadar yang diterima oleh tim Anda.
Anda harus hati-hati memilih paket Anda. Sementara Flux secara eksplisit tidak mencoba untuk menyelesaikan masalah "terdekat" seperti undo / redo , kegigihan , atau bentuk , Redux memiliki titik ekstensi seperti middleware dan penambah toko, dan Flux telah menghasilkan ekosistem muda namun kaya . Ini berarti sebagian besar paket adalah ide baru dan belum menerima banyak penggunaan kritis. Anda mungkin bergantung pada sesuatu yang jelas merupakan ide buruk beberapa bulan kemudian, tetapi masih sulit untuk mengatakannya.
Anda belum memiliki integrasi Flow yang bagus. Flux saat ini memungkinkan Anda melakukan pemeriksaan tipe statis yang sangat mengesankan yang belum didukung Redux . Kami akan sampai di sana, tetapi itu akan memakan waktu.
Saya pikir yang pertama adalah rintangan terbesar bagi pemula, yang kedua bisa menjadi masalah bagi pengadopsi awal yang terlalu antusias, dan yang ketiga adalah kesal pribadi saya. Selain itu, saya tidak berpikir menggunakan Redux membawa kerugian khusus yang dihindari Flux, dan beberapa orang mengatakan itu bahkan memiliki beberapa kelebihan dibandingkan dengan Flux.
Lihat juga jawaban saya di sisi atas menggunakan Redux .
shallowEqualcek reaksi-redux digunakan untuk menentukan jika keadaan berubah. Tapi itu bisa diganti dengan deepEqual atau JSON.stringify dan bandingkan. Akhirnya itu kinerja yang sedikit lebih rendah - tapi itu perhitungan murni tanpa berurusan dengan DOM - cukup cepat. Dan dalam hal apapun rendering itu sendiri sama
Baik Redux dan Flux membutuhkan sejumlah besar kode boilerplate untuk mencakup banyak pola umum, terutama yang melibatkan pengambilan data asinkron. Dokumentasi Redux sudah memiliki beberapa contoh untuk pengurangan boilerplate: http://redux.js.org/docs/recipes/ReducingBoilerplate.html . Anda bisa mendapatkan semua yang Anda butuhkan dari pustaka Flux seperti Alt atau Fluxxor, tetapi Redux lebih suka kebebasan daripada fitur. Ini bisa menjadi kerugian bagi beberapa pengembang karena Redux membuat asumsi tertentu tentang keadaan Anda yang dapat secara tidak sengaja diabaikan.
Satu-satunya cara bagi Anda untuk benar-benar menjawab pertanyaan Anda adalah mencoba Redux jika Anda bisa, mungkin dalam proyek pribadi. Redux muncul karena kebutuhan untuk pengalaman pengembang yang lebih baik, dan itu bias terhadap pemrograman fungsional. Jika Anda tidak terbiasa dengan konsep-konsep fungsional seperti reduksi dan komposisi fungsi maka Anda mungkin diperlambat, tetapi hanya sedikit. Sisi positif untuk merangkul ide-ide ini dalam aliran data adalah pengujian dan prediksi yang lebih mudah.
Penafian: Saya bermigrasi dari Flummox (implementasi Flux yang populer) ke Redux dan keuntungannya jauh melebihi kerugian. Saya lebih suka sihir yang kurang dalam kode saya. Lebih sedikit sihir datang dengan biaya sedikit lebih keras, tapi itu harga yang sangat kecil untuk dibayar.
Redux bukan implementasi Flux murni tetapi pasti terinspirasi oleh Flux. Perbedaan terbesar adalah bahwa ia menggunakan satu toko yang membungkus objek negara yang berisi semua negara untuk aplikasi Anda. Alih-alih membuat toko seperti yang akan Anda lakukan di Flux, Anda akan menulis fungsi peredam yang akan mengubah status objek tunggal. Objek ini mewakili semua status di aplikasi Anda. Di Redux Anda akan mendapatkan tindakan dan status saat ini, dan mengembalikan status baru. Itu berarti bahwa tindakan berurutan dan keadaan tidak berubah. Itu membawa saya ke penipu paling jelas di Redux (menurut saya).
Ada beberapa alasan untuk itu:
1. Koherensi - keadaan toko selalu diubah oleh peredam sehingga mudah melacak siapa yang mengubah apa.
2. Kinerja - karena tidak berubah, Redux hanya perlu memeriksa apakah kondisi sebelumnya! == kondisi saat ini dan jika demikian untuk membuat. Tidak perlu mengulang keadaan setiap kali untuk rendering yang ditentukan.
3. Debugging - konsep luar biasa baru seperti Time Travel Debugging dan Hot Reloading .
PEMBARUAN: jika itu tidak cukup meyakinkan, saksikan Lee Byron berbicara dengan sangat baik tentang Antarmuka Pengguna yang Tidak Berubah .
Redux membutuhkan disiplin pengembang melalui basis kode / pustaka untuk mempertahankan gagasan ini. Anda harus memastikan bahwa Anda memilih perpustakaan dan menulis kode dengan cara yang tidak bisa diubah.
Jika Anda ingin mempelajari lebih lanjut tentang penerapan konsep Flux yang berbeda (dan apa yang paling sesuai untuk kebutuhan Anda), lihat perbandingan yang bermanfaat ini .
Setelah mengatakan itu, saya harus mengakui bahwa Redux adalah tempat pengembangan JS di masa depan (seperti untuk menulis baris ini).
Salah satu manfaat terbesar dalam menggunakan Redux dibandingkan alternatif Flux lainnya adalah kemampuannya untuk mengubah arah pemikiran Anda menuju pendekatan yang lebih fungsional. Setelah Anda memahami bagaimana semua kabel terhubung, Anda menyadari keanggunan dan kesederhanaan yang menakjubkan dalam desain, dan tidak pernah bisa kembali.
Saya lebih suka menggunakan Redux karena menggunakan satu toko yang membuat manajemen negara jauh lebih mudah dibandingkan dengan Flux , juga Redux DevTools itu alat yang sangat membantu yang memungkinkan Anda melihat apa yang Anda lakukan dengan keadaan Anda dengan beberapa data yang berguna dan itu benar-benar sejalan dengan Bereaksi mengembangkan alat.
Juga Redux telah mendapat lebih fleksibel menggunakan dengan kerangka populer lainnya seperti sudut . Bagaimanapun, mari kita lihat bagaimana Redux memperkenalkan dirinya sebagai kerangka kerja.
Redux memiliki Tiga Prinsip yang dapat memperkenalkan Redux dengan sangat baik dan mereka adalah perbedaan utama antara Redux dan Flux juga.
Sumber kebenaran tunggal
Keadaan seluruh aplikasi Anda disimpan dalam pohon objek dalam satu toko.
Ini membuatnya mudah untuk membuat aplikasi universal, karena keadaan dari server Anda dapat diserialisasi dan dihidrasi ke klien tanpa upaya pengkodean tambahan. Satu pohon negara juga memudahkan untuk debug atau memeriksa aplikasi; itu juga memungkinkan Anda untuk mempertahankan status aplikasi Anda dalam pengembangan, untuk siklus pengembangan yang lebih cepat. Beberapa fungsi yang secara tradisional sulit diimplementasikan - Undo / Redo, misalnya - tiba-tiba bisa menjadi sepele untuk diterapkan, jika semua negara Anda disimpan dalam satu pohon.
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
}
]
}
*/Status hanya baca
Satu-satunya cara untuk mengubah keadaan adalah memancarkan tindakan, objek yang menggambarkan apa yang terjadi.
Ini memastikan bahwa baik pandangan maupun panggilan balik jaringan tidak akan pernah menulis langsung ke negara. Sebaliknya, mereka mengekspresikan niat untuk mengubah negara. Karena semua perubahan dipusatkan dan terjadi satu per satu dalam urutan yang ketat, tidak ada kondisi balapan yang harus diwaspadai. Karena tindakan hanyalah objek biasa, tindakan dapat dicatat, diserialisasi, disimpan, dan kemudian diputar ulang untuk tujuan debugging atau pengujian.
store.dispatch({
type: 'COMPLETE_TODO',
index: 1
})
store.dispatch({
type: 'SET_VISIBILITY_FILTER',
filter: 'SHOW_COMPLETED'
})Perubahan dilakukan dengan fungsi murni
Untuk menentukan bagaimana pohon negara ditransformasikan oleh tindakan, Anda menulis reduksi murni.
Pereduksi hanyalah fungsi murni yang mengambil status dan tindakan sebelumnya, dan mengembalikan status berikutnya. Ingatlah untuk mengembalikan objek keadaan baru, alih-alih mengubah keadaan sebelumnya. Anda bisa mulai dengan satu peredam, dan seiring pertumbuhan aplikasi Anda, bagilah menjadi peredam kecil yang mengelola bagian tertentu dari pohon negara. Karena reduksi hanyalah fungsi, Anda dapat mengontrol urutan pemanggilannya, memberikan data tambahan, atau bahkan membuat reduksi yang dapat digunakan kembali untuk tugas-tugas umum seperti pagination.
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)untuk info lebih lanjut kunjungi di sini
Sejauh yang saya tahu, redux terinspirasi oleh fluks. fluks adalah arsitektur seperti MVC (model view controller). Facebook memperkenalkan fluks karena masalah skalabilitas saat menggunakan MVC. jadi fluks bukan implementasi, itu hanya konsep. Sebenarnya redux adalah implementasi dari fluks.