Pertanyaan Mengapa menggunakan Redux melalui Facebook Flux?


Saya telah membaca jawaban ini, mengurangi boilerplate, melihat beberapa contoh GitHub dan bahkan mencoba redux sedikit (aplikasi todo).

Seperti yang saya mengerti, motivasi redux doc resmi menyediakan pro dibandingkan dengan arsitektur MVC tradisional. TAPI itu tidak memberikan jawaban untuk pertanyaan:

Mengapa Anda harus menggunakan Redux melalui Facebook Flux? 

Apakah itu hanya masalah gaya pemrograman: fungsional vs non-fungsional? Atau pertanyaannya ada pada kemampuan / dev-tools yang mengikuti dari pendekatan redux? Mungkin scaling? Atau pengujian?

Apakah saya benar jika saya mengatakan bahwa redux adalah fluks untuk orang yang berasal dari bahasa fungsional? 

Untuk menjawab pertanyaan ini Anda dapat membandingkan kompleksitas implementasi titik-titik motivasi redux pada flux vs redux.

Berikut adalah poin motivasi dari motivasi redux doc resmi:

  1. Menangani pembaruan yang optimis (seperti yang saya mengerti, itu hampir tidak tergantung pada poin ke-5. Apakah sulit untuk menerapkannya dalam fluks facebook?)
  2. Rendering pada server (fluks facebook juga bisa melakukan ini. Ada manfaat dibandingkan dengan redux?)
  3. Mengambil data sebelum melakukan transisi rute (Mengapa itu tidak bisa dicapai dalam fluks facebook? Apa manfaatnya?)
  4. Reload panas (Itu mungkin dengan Bereaksi Ulang Panas. Kenapa kita perlu redux?)
  5. Fungsi Undo / Redo
  6. Ada poin lain? Seperti keadaan bertahan ...

1003
2017-09-08 15:05


asal


Jawaban:


Penulis Redux di sini!

Redux tidak bahwa berbeda dari Flux. Secara keseluruhan memiliki arsitektur yang sama, tetapi Redux mampu memotong beberapa sudut kompleksitas dengan menggunakan komposisi fungsional di mana Flux menggunakan registrasi panggilan balik.

Tidak ada perbedaan mendasar dalam Redux, tetapi saya merasa itu membuat abstraksi tertentu lebih mudah, atau setidaknya mungkin untuk diterapkan, yang akan sulit atau tidak mungkin untuk diimplementasikan dalam Flux.

Komposisi Peredam

Ambil, misalnya, paginasi. Saya Contoh Flux + React Router menangani pagination, tetapi kode untuk itu mengerikan. Salah satu alasannya mengerikan adalah itu Flux membuatnya tidak wajar untuk menggunakan kembali fungsi di seluruh toko. Jika dua toko perlu menangani paginasi dalam menanggapi tindakan yang berbeda, mereka perlu mewarisi dari toko basis umum (buruk! Anda mengunci diri ke dalam desain tertentu ketika Anda menggunakan warisan), atau memanggil fungsi dari handler, yang perlu entah bagaimana beroperasi pada keadaan pribadi toko Flux. Semuanya berantakan (meskipun pasti di ranah mungkin).

Di sisi lain, dengan paginasi Redux adalah wajar berkat komposisi pereduksi. Ini reduksi ke bawah, jadi Anda bisa menulis a pabrik peredam yang menghasilkan pengurang paginasi lalu gunakan di pohon peredam Anda. Kunci mengapa begitu mudah adalah karena di Flux, toko-toko bersifat datar, tetapi di Redux, reduksi dapat disarangkan melalui komposisi fungsional, seperti halnya komponen React yang dapat diulang.

Pola ini juga memungkinkan fitur-fitur luar biasa seperti no-user-code batalkan / ulangi. Dapatkah Anda membayangkan memasukkan Undo / Redo ke aplikasi Flux menjadi dua baris kode? Susah. Dengan Redux, itu—berkata, berkat pola komposisi pereduksi. Saya perlu menyoroti tidak ada yang baru tentang hal itu — ini adalah pola yang dipelopori dan dijelaskan secara terperinci Arsitektur Elm yang itu sendiri dipengaruhi oleh Flux.

Rendering Server

Orang-orang telah melakukan rendering pada server dengan Flux, tetapi melihat bahwa kami memiliki 20 perpustakaan Flux yang masing-masing mencoba untuk membuat server rendering "lebih mudah", mungkin Flux memiliki beberapa sisi kasar pada server. Yang benar adalah Facebook tidak melakukan banyak rendering server, jadi mereka tidak terlalu peduli tentang itu, dan bergantung pada ekosistem untuk membuatnya lebih mudah.

Dalam Flux tradisional, toko adalah lajang. Ini berarti sulit untuk memisahkan data untuk berbagai permintaan di server. Bukan tidak mungkin, tapi sulit. Inilah sebabnya mengapa sebagian besar perpustakaan Flux (serta yang baru Utilitas Flux) sekarang menyarankan Anda menggunakan kelas, bukan lajang, sehingga Anda dapat memberi tahu toko per permintaan.

Masih ada masalah berikut yang perlu Anda pecahkan dalam Flux (baik diri Anda sendiri atau dengan bantuan pustaka Flux favorit Anda seperti Membingungkan atau Alt):

  • Jika toko adalah kelas, bagaimana cara membuat dan menghancurkannya dengan dispatcher per permintaan? Kapan saya mendaftar toko?
  • Bagaimana cara menghidrasi data dari toko dan kemudian rehidrasi pada klien? Apakah saya perlu menerapkan metode khusus untuk ini?

Kerangka Flux yang diakui (bukan vanilla Flux) memiliki solusi untuk masalah ini, tetapi saya menemukan mereka terlalu rumit. Sebagai contoh, Flummox meminta Anda untuk menerapkan serialize() dan deserialize() di toko Anda. Alt memecahkan ini lebih baik dengan menyediakan takeSnapshot() yang secara otomatis membuat serialisasi status Anda di pohon JSON.

Redux hanya melangkah lebih jauh: karena hanya ada satu toko (dikelola oleh banyak pengecil), Anda tidak memerlukan API khusus untuk mengelola hidrasi (kembali). Anda tidak perlu "menyiram" atau "melembabkan" toko — hanya ada satu toko, dan Anda dapat membaca keadaannya saat ini, atau membuat toko baru dengan negara baru. Setiap permintaan mendapat turunan toko terpisah. Baca lebih lanjut tentang rendering server dengan Redux.

Sekali lagi, ini adalah kasus sesuatu yang mungkin baik dalam Flux dan Redux, tetapi perpustakaan Flux memecahkan masalah ini dengan memperkenalkan satu ton API dan konvensi, dan Redux bahkan tidak harus menyelesaikannya karena tidak memiliki masalah dalam tempat pertama berkat kesederhanaan konseptual.

Pengalaman Pengembang

Saya sebenarnya tidak berniat Redux untuk menjadi perpustakaan Flux yang populer — saya menulisnya saat saya mengerjakannya BereaksiEurope berbicara tentang reload panas dengan perjalanan waktu. Saya memiliki satu tujuan utama: memungkinkan untuk mengubah kode peredaran dengan cepat atau bahkan "mengubah masa lalu" dengan mencoret tindakan, dan melihat keadaan yang dihitung kembali.

Saya belum melihat satu pun perpustakaan Flux yang mampu melakukan ini. React Hot Loader juga tidak membiarkan Anda melakukan ini — sebenarnya ini rusak jika Anda mengedit flux store karena tidak tahu apa yang harus dilakukan dengan mereka.

Ketika Redux perlu memuat ulang kode peredam, itu panggilan replaceReducer(), dan aplikasi berjalan dengan kode baru. Dalam Flux, data dan fungsi terjerat di toko Flux, jadi Anda tidak bisa "mengganti fungsi" saja. Selain itu, Anda harus mendaftar ulang versi baru dengan Dispatcher — sesuatu yang bahkan tidak dimiliki Redux.

Ekosistem

Redux memiliki ekosistem yang kaya dan cepat tumbuh. Ini karena ia menyediakan beberapa titik ekstensi seperti middleware. Ini dirancang dengan menggunakan kasus seperti penebangan, mendukung Janji, Dapat diamati, rute, pemeriksaan dev immutability, kegigihan, dll, dalam pikiran. Tidak semua ini akan berguna, tetapi bagus untuk memiliki akses ke serangkaian alat yang dapat dikombinasikan dengan mudah untuk bekerja bersama.

Kesederhanaan

Redux menjaga semua manfaat Flux (merekam dan memutar ulang tindakan, aliran data searah, mutasi dependen) dan menambahkan manfaat baru (mudah undo-redo, reload panas) tanpa memperkenalkan Dispatcher dan pendaftaran toko.

Menjaganya tetap sederhana adalah penting karena membuat Anda tetap waras saat Anda menerapkan abstraksi tingkat lebih tinggi.

Tidak seperti kebanyakan pustaka Flux, permukaan API Redux kecil. Jika Anda menghapus peringatan pengembang, komentar, dan pemeriksaan kewarasan, itu 99 baris. Tidak ada kode asinkron yang rumit untuk melakukan debug.

Anda benar-benar dapat membacanya dan memahami semua Redux.


Lihat juga jawaban saya pada kelemahan menggunakan Redux dibandingkan dengan Flux.


1804
2017-10-03 08:26



Di Quora, seseorang berkata: 

Pertama-tama, itu benar-benar mungkin untuk menulis aplikasi dengan Bereaksi tanpa   Aliran.

Juga ini diagram visual yang saya buat menunjukkan pandangan cepat dari keduanya, mungkin jawaban cepat untuk orang-orang yang tidak ingin membaca seluruh penjelasan: Flux vs Redux

Tetapi jika Anda masih tertarik untuk mengetahui lebih banyak, baca terus.

Saya percaya Anda harus mulai dengan React murni, kemudian belajar Redux dan Flux.   Setelah Anda akan memiliki beberapa pengalaman NYATA dengan Bereaksi, Anda akan melihat   apakah Redux bermanfaat untuk Anda atau tidak.

Mungkin Anda akan merasa bahwa Redux persis untuk aplikasi Anda dan mungkin Anda   akan mencari tahu, bahwa Redux sedang mencoba untuk memecahkan masalah Anda tidak   benar-benar mengalami.

Jika Anda memulai langsung dengan Redux, Anda mungkin berakhir dengan over-engineered   kode, kode lebih sulit untuk dikelola dan dengan lebih banyak bug dan daripada tanpa   Redux.

Dari Dokumentasi redux:

Motivasi 
 Sebagai persyaratan untuk JavaScript aplikasi satu halaman menjadi semakin rumit, kami   kode harus mengelola lebih banyak keadaan daripada sebelumnya. Keadaan ini bisa termasuk   respons server dan data cache, serta data yang dibuat secara lokal itu   belum disimpan ke server. Keadaan UI juga meningkat   dalam kompleksitas, karena kami perlu mengatur rute aktif, tab yang dipilih,   pemintal, kontrol paginasi, dan sebagainya.

Mengelola keadaan yang selalu berubah ini sulit. Jika suatu model dapat memperbarui   model lain, maka tampilan dapat memperbarui model, yang memperbarui yang lain   model, dan ini, pada gilirannya, mungkin menyebabkan pandangan lain untuk memperbarui. Di beberapa   titik, Anda tidak lagi memahami apa yang terjadi di aplikasi Anda seperti yang Anda miliki   kehilangan kendali atas kapan, mengapa, dan bagaimana keadaannya. Ketika sebuah sistem   buram dan tidak-deterministik, sulit untuk mereproduksi bug atau menambahkan   fitur baru.

Seolah-olah ini tidak cukup buruk, pertimbangkan persyaratan baru menjadi   umum dalam pengembangan produk front-end. Sebagai pengembang, kami   diharapkan untuk menangani pembaruan yang optimis, rendering sisi server, mengambil   data sebelum melakukan transisi rute, dan seterusnya. Kami menemukan diri kami   mencoba mengelola kompleksitas yang tidak pernah kita hadapi   sebelumnya, dan kami mau tidak mau mengajukan pertanyaan: Apakah sudah waktunya untuk menyerah? Itu   jawabannya tidak.

Kompleksitas ini sulit untuk ditangani karena kami mencampur dua konsep   yang sangat sulit bagi akal manusia untuk berpikir tentang: mutasi dan   asynchronicity. Saya menyebutnya Mentos dan Coke. Keduanya bisa menjadi hebat ketika   terpisah, tetapi bersama-sama mereka menciptakan kekacauan. Perpustakaan seperti Bereaksi   mencoba memecahkan masalah ini di lapisan tampilan dengan menghapus keduanya   manipulasi DOM asynchrony dan langsung. Namun, mengelola keadaan   data Anda diserahkan kepada Anda. Di sinilah Redux masuk.

Mengikuti jejak Flux, CQRS, dan Event Sourcing, Redux   upaya untuk membuat mutasi negara dapat diprediksi dengan memberlakukan tertentu   pembatasan bagaimana dan kapan pembaruan dapat terjadi. Batasan ini   tercermin dalam tiga prinsip Redux.

Juga dari Dokumentasi redux:

Konsep inti
 Redux sendiri sangat sederhana.

Bayangkan status aplikasi Anda digambarkan sebagai objek biasa. Sebagai contoh,   status aplikasi todo mungkin terlihat seperti ini:

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

Objek ini seperti "model" kecuali bahwa tidak ada setter. Ini   adalah agar bagian kode yang berbeda tidak dapat mengubah negara   secara sewenang-wenang, menyebabkan bug yang sulit di-reproduksi.

Untuk mengubah sesuatu di negara bagian, Anda perlu mengirim tindakan. Sebuah   tindakan adalah objek JavaScript sederhana (perhatikan bagaimana kami tidak memperkenalkan apa pun   magic?) yang menggambarkan apa yang terjadi. Berikut ini beberapa contoh tindakan:

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

Menegakkan bahwa setiap perubahan digambarkan sebagai tindakan yang memungkinkan kita memiliki   pemahaman yang jelas tentang apa yang terjadi di aplikasi. Jika sesuatu   berubah, kita tahu mengapa itu berubah. Tindakan seperti remah roti dari apa   sudah terjadi. Akhirnya, untuk mengikat keadaan dan tindakan bersama, kami menulis a   fungsi yang disebut peredam. Sekali lagi, tidak ada keajaiban tentang itu - hanya saja   fungsi yang mengambil status dan tindakan sebagai argumen, dan mengembalikan   keadaan aplikasi selanjutnya. Akan sulit untuk menulis fungsi seperti itu untuk a   aplikasi besar, jadi kami menulis fungsi yang lebih kecil mengelola bagian dari negara:

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;
  }
}

Dan kami menulis peredam lain yang mengelola keadaan lengkap kami   aplikasi dengan memanggil kedua pengecil untuk kunci negara yang sesuai:

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

Ini pada dasarnya adalah gagasan tentang Redux. Perhatikan bahwa kami belum pernah menggunakan   API Redux apa pun. Itu datang dengan beberapa utilitas untuk memfasilitasi ini   pola, tetapi gagasan utamanya adalah bahwa Anda menggambarkan bagaimana keadaan Anda   diperbarui dari waktu ke waktu sebagai tanggapan terhadap objek tindakan, dan 90% dari kode   Anda menulis hanya JavaScript polos, tanpa menggunakan Redux itu sendiri, itu   API, atau sihir apa pun.


74
2018-03-22 12:59



Anda mungkin lebih baik memulai dengan membaca posting ini oleh Dan Abramov di mana dia membahas berbagai implementasi Flux dan trade-off mereka pada saat ia menulis redux: Evolusi Kerangka Kerja Flux

Kedua, halaman motivasi yang Anda tautkan tidak benar-benar membahas motivasi Redux seperti motivasi di balik Flux (dan Bereaksi). Itu Tiga Prinsip lebih spesifik Redux meskipun masih tidak berurusan dengan perbedaan implementasi dari arsitektur Flux standar.

Pada dasarnya, Flux memiliki beberapa toko yang menghitung perubahan status sebagai tanggapan terhadap interaksi UI / API dengan komponen dan menyiarkan perubahan ini sebagai peristiwa yang dapat dijadikan langganan komponen. Di Redux, hanya ada satu toko yang berlangganan setiap komponen. IMO itu merasa setidaknya seperti Redux lebih menyederhanakan dan menyatukan aliran data dengan menyatukan (atau mengurangi, seperti Redux akan mengatakan) aliran data kembali ke komponen - sedangkan Fluks berkonsentrasi pada penyatuan sisi lain dari aliran data - lihat model.


50
2017-09-23 14:51



Saya adalah pengguna awal dan menerapkan aplikasi satu halaman besar-tengah menggunakan pustaka Flux Facebook.

Karena saya agak terlambat untuk percakapan, saya akan menunjukkan bahwa meskipun harapan saya Facebook tampaknya mempertimbangkan penerapan Flux mereka untuk menjadi bukti konsep dan tidak pernah menerima perhatian yang layak.

Saya akan mendorong Anda untuk bermain dengannya, karena ini memperlihatkan lebih banyak kerja batin dari arsitektur Flux yang cukup mendidik, tetapi pada saat yang sama tidak memberikan banyak manfaat yang disediakan oleh perpustakaan seperti Redux (yang tidak yang penting untuk proyek-proyek kecil, tetapi menjadi sangat berharga untuk proyek yang lebih besar).

Kami telah memutuskan bahwa bergerak maju kami akan pindah ke Redux dan saya sarankan Anda melakukan hal yang sama;)


22
2018-01-05 13:45



Berikut ini penjelasan sederhana tentang Redux over Flux. Redux tidak memiliki dispatcher. Ini bergantung pada fungsi-fungsi murni yang disebut reduksi. Tidak perlu dispatcher. Setiap tindakan ditangani oleh satu atau lebih reduksi untuk memperbarui toko tunggal. Karena data tidak dapat diubah, pengecil mengembalikan status baru yang diperbarui yang memperbarui tokoenter image description here

Untuk informasi lebih lanjut http://www.prathapkudupublog.com/2017/04/flux-vs-redux.html


13
2018-04-18 14:27



Saya bekerja cukup lama dengan Flux dan sekarang sudah cukup lama menggunakan Redux. Seperti yang ditunjukkan Dan kedua arsitektur tidak begitu berbeda. Masalahnya adalah bahwa Redux membuat semuanya lebih sederhana dan lebih bersih. Ini mengajarkan Anda beberapa hal di atas Flux. Seperti misalnya Flux adalah contoh sempurna dari aliran data satu arah. Pemisahan kekhawatiran di mana kita memiliki data, manipulasi dan lapisan pandangannya dipisahkan. Di Redux kami memiliki hal yang sama tetapi kami juga belajar tentang kekekalan dan fungsi murni.


2
2018-01-25 12:26



Aliran adalah pola dan Redux adalah perpustakaan.

Flux adalah nama yang bagus untuk pola pengamat yang dimodifikasi sedikit agar sesuai dengan React, tetapi Facebook merilis beberapa alat untuk membantu menerapkan pola Flux, jadi berikut ini adalah perbedaan antara menggunakan alat ini (yang biasa disebut dengan menggunakan Flux ) dan menggunakan Redux.

Baik Flux dan Redux memiliki tindakan. Tindakan dapat dibandingkan dengan peristiwa (atau peristiwa pemicu apa). Dalam Flux, tindakan adalah objek JavaScript sederhana, dan itu adalah kasus default di Redux juga, tetapi ketika menggunakan middleware Redux, tindakan juga dapat berupa fungsi dan janji.

Dengan Flux itu adalah konvensi untuk memiliki beberapa toko per aplikasi; setiap toko adalah objek tunggal. Di Redux, konvensi ini memiliki satu toko per aplikasi, biasanya dipisahkan menjadi domain data secara internal (Anda dapat membuat lebih dari satu toko Redux jika diperlukan untuk skenario yang lebih kompleks).

Flux memiliki dispatcher tunggal dan semua tindakan harus melewati petugas operator tersebut. Ini adalah objek tunggal. Aplikasi Flux tidak dapat memiliki beberapa dispatcher. Ini diperlukan karena aplikasi Flux dapat memiliki banyak toko dan ketergantungan antara toko tersebut membutuhkan seorang manajer tunggal, yang merupakan dispatcher.

Redux tidak memiliki entitas dispatcher. Sebaliknya, toko memiliki proses pengiriman yang dipanggang. Toko Redux memaparkan beberapa fungsi API sederhana, salah satunya adalah mengirim tindakan.

Dalam Flux, logika apa yang harus dilakukan pada data berdasarkan tindakan yang diterima ditulis di toko itu sendiri. Toko ini juga memiliki fleksibilitas dari bagian data yang akan ditampilkan secara publik. Pemain paling cerdas dalam aplikasi Flux adalah tokonya.

Di Redux, logika apa yang harus dilakukan pada data berdasarkan tindakan yang diterima adalah dalam fungsi peredam yang dipanggil untuk setiap tindakan yang dikirim (melalui API toko). Toko tidak dapat ditentukan tanpa fungsi peredam. Peredam Redux adalah fungsi sederhana yang menerima status sebelumnya dan satu tindakan, dan mengembalikan keadaan baru berdasarkan tindakan itu. Di aplikasi Redux, Anda dapat membagi peredam menjadi fungsi yang lebih sederhana seperti yang Anda lakukan dengan fungsi lain apa pun. Pemain paling pintar di Redux adalah peredam.

Di Redux, juga, tidak ada banyak fleksibilitas tentang apa yang harus diungkapkan sebagai keadaan toko. Redux hanya akan memaparkan apa pun yang dikembalikan dari peredaran toko. Ini adalah salah satu kendala.

Kendala lain yang lebih besar adalah bahwa negara toko tidak dapat diubah (atau memang tidak boleh). Tidak ada kendala seperti itu di Flux, Anda dapat mengubah keadaan seperti yang Anda inginkan. Keabadian negara, di Redux, dicapai dengan mudah dengan membuat reduksi fungsi murni (tanpa efek samping). Pengecil redux selalu menyalin negara yang mereka terima dan mengembalikan versi modifikasi salinan negara, bukan objek asli itu sendiri. Meskipun ini adalah kendala besar, itu membuat hidup lebih mudah dalam jangka panjang.


0
2018-06-24 07:13