Redux: Apakah Redux's Time Come and Gone

https://github.com/rackt/redux/issues/464

Banyak orang yang cukup senang dengan Redux. Anda harus bertanya-tanya — saya tidak benar-benar memenuhi syarat untuk menjawab pertanyaan ini. Menurut saya, jika aplikasi Anda sangat padat data ala Facebook (banyak entitas bersarang dengan hubungan yang kompleks), sebaiknya Anda berinvestasi dalam backend GraphQL dan mempelajari Relay. Saya hanya mendengar hal-hal baik tentang itu.

Redux tentu saja lebih eksplisit dan tidak menyelesaikan pengambilan data deklaratif untuk Anda. Ada upaya untuk mengintegrasikan Redux dan GraphQL tetapi saya tidak dapat mengevaluasinya terhadap Relay — saya tahu terlalu sedikit tentangnya.

Redux jauh lebih rendah daripada Relay, dan tidak lebih "masa lalu" dari objek JS biasa dan fungsi "masa lalu". Relay adalah kerangka kerja, dan Redux, tanpa pemeriksaan kewarasan, memiliki sepuluh fungsi 10-liner, jadi seharusnya tidak mengherankan jika mereka memiliki cakupan yang berbeda. Pilih mana yang paling cocok untuk Anda dan beri tahu kami.

Pengambilan deklaratif dari GraphQL luar biasa, terbaik. Namun Relay masih memiliki API HoC, yang tidak bersifat deklaratif. Jika Relay menawarkan API yang lebih fleksibel, tidak dipasangkan dari pohon komponen, maka pengikatan Redux yang tepat dapat ditulis?

Saya pikir mereka adalah 2 jenis sistem yang memecahkan 2 masalah berbeda.
Tiket ini seperti tukang kayu yang menanyakan apakah waktu palu telah berlalu.
Sistem berbasis graphql menurut saya adalah solusi yang direkayasa secara berlebihan untuk banyak aplikasi, sebaliknya aplikasi dengan struktur data kompleks kemungkinan besar tidak direkayasa jika dibangun menggunakan redux.

Sistem berbasis graphql menurut saya adalah solusi yang direkayasa secara berlebihan untuk banyak aplikasi, sebaliknya aplikasi dengan struktur data kompleks kemungkinan besar tidak direkayasa jika dibangun menggunakan redux.

Cara yang bagus untuk menjelaskannya; itulah yang saya rasakan tentang itu juga.

@gaearon terus bekerja dengan baik dengan redux! Salah satu alat terbaik! Saya menggunakannya di 5 aplikasi besar dan 2 aplikasi kecil di perusahaan saya dan menyukainya!

@gaearon terus bekerja dengan baik dengan redux! Salah satu alat terbaik! Saya menggunakannya di 5 aplikasi besar dan 2 aplikasi kecil di perusahaan saya dan menyukainya!

: 100:

saya pikir mereka tidak sama:

• relay - untuk menyelesaikan manajemen pengambilan data dari server
• redux - untuk menyelesaikan manajemen aplikasi negara

banyak aplikasi kompleks berisi status yang tidak terkait dengan server yang perlu Anda kelola. Saya akan berpendapat bahwa jika Anda akan menggunakan relay, Anda akan melihat diri Anda pada akhirnya membutuhkan redux juga. sebaliknya, relai tampak seperti dorongan yang sangat bagus tetapi hanya untuk hal-hal yang berhubungan dengan server

Pertanyaannya adalah bagaimana Relay berhubungan dengan pola desain yang terinspirasi fluks? Di mana Relay berakhir, kapan kita membutuhkan Redux? Apakah Relay Flux 2.0?

Contoh Todo Relay: apakah itu membuat redux usang?

Mungkin ada cara untuk memberi tahu peredam Anda bagaimana memetakan dirinya ke dan dari GraphQL dan kapan? Bukan mengatakan hal-hal yang tidak rumit tetapi cara paling sederhana untuk membuatnya masuk akal.

Perlu mempelajari lebih lanjut tentang apa itu Relay. Bukan beberapa ratus baris kode yang pasti!

@oriSomething Anda kurang tepat. Relay juga memecahkan banyak manajemen negara.

@gyzerok yang saya maksud adalah status aplikasi sisi klien

@oriSomething Ya, saya berbicara tentang status aplikasi sisi klien

@gyzerok saya pasti melewatkannya. dapatkah Anda memberi saya tautan tentang ini?

@oriSomething tidak ada link khusus karena Relay mengelolanya secara implisit. Mungkin Anda bisa mencoba menonton pembicaraan FB tentang Relay. Mereka berbicara tentang bagaimana Relay memecahkan masalah cache. Cache aplikasi sisi klien = status. Saya tidak ingat pembicaraan pasti, maaf.

@oriSomething , satu-satunya tempat pengembang harus melakukan beberapa manajemen keadaan eksplisit ada di sini .

@gyzerok ok, jadi dalam hal ini, apakah ada manajemen negara yang tidak terkait dengan server yang melakukan relay? sejauh yang saya mengerti tidak, atau apakah itu?

@oriSomething Jika saya memahami Anda dengan benar, Relay melakukan semua hal tentang normalisasi data pada klien dan menggabungkan data dari kueri ke dalam satu penyimpanan.

@oriSomething ya, berhasil => https://facebook.github.io/relay/img/Guides-Containers-HOC-Relay.png
Periksa: https://facebook.github.io/relay/docs/guides-ready-state.html#content

Hanya jika ada data yang tidak mencukupi pada klien, Relay mengirimkan permintaan ke server untuk lebih banyak data.

Redux jauh lebih rendah daripada Relay, dan tidak lebih "masa lalu" dari objek JS biasa dan fungsi "masa lalu". Relay adalah kerangka kerja, dan Redux, tanpa pemeriksaan kewarasan, memiliki sepuluh fungsi 10-liner, jadi seharusnya tidak mengherankan jika mereka memiliki cakupan yang berbeda.

Jadi saya membuat slim-redux.js hanya untuk bersenang-senang — versi Redux tanpa komentar, peringatan pengembang, dan pemeriksaan kewarasan. Ini melewati semua tes Redux penting (kecuali tes pemeriksaan kewarasan), dan 99 baris: wink:. Ini harus menyegel poin saya bahwa Relay dan Redux adalah alat dengan cakupan yang sangat berbeda.

@IwanKaramazow saya rasa saya kurang jelas, apa yang saya coba katakan, tidak semua data tentang server, ada data yang tidak terkait dengan server untuk dikelola, dan saya benar-benar tidak berpikir relay adalah "alat" masuk meskipun bisa untuk mengelola data ini

@oriSomething dapat Anda berikan contoh?

Setuju sepenuhnya @mattapperson . Semuanya bermuara pada definisi kompleks, atau lebih baik, di mana setiap individu mengenali "hal yang kompleks"

@IwanKaramazow Saya rasa @oriSomething berbicara tentang status bentuk sisi klien misalnya

Saya pindah dari Redux => Relay karena GraphQL. Hampir semua sumber daya dalam aplikasi saya bersifat hierarkis. Mereka secara alami masuk akal untuk menjadi entitas bersarang. Menyimpan cache model ini di Redux sangat mengagumkan. Saya memiliki pandangan yang waras tentang data saya dan dapat dengan cepat beralih dengan redux-devtools yang mengagumkan.

Tetapi tanpa GraphQL, saya harus melakukan beberapa perjalanan untuk memetakan sumber daya jarak jauh ke pohon redux.

1. / resource1-list
2. / resource2-list? resource1 =
3. / resource3-list? resource2 =

Jelas ini adalah masalah dengan REST, bukan Redux. Seandainya saya melihat beberapa binding Redux-GraphQL sebelumnya, mungkin saya akan menggunakannya. Mengadopsi Relay sangat sedikit berubah dalam aplikasi saya. Alih-alih @connect Saya menggunakan Relay.createContainer . Kedua produk tersebut memiliki visi arsitektur yang sama dengan API yang berbeda. Saya menulis posting singkat tentang ini.

Saat ini saya menggunakan redux dan relai / graphql dan meskipun relai luar biasa untuk pengambilan data, saya dapat melihat diri saya selalu menggunakan redux. Saat ini saya menggunakan redux karena 2 alasan dan saya dapat melihat diri saya menemukan lebih banyak alasan di masa mendatang

1) Keadaan lain-lain yang perlu dibagi antara komponen yang tidak hidup dalam database
2) Formulir persiapan. Saya sebenarnya memiliki satu bagian dari aplikasi saya di mana saya memiliki komponen toolbar yang memiliki tombol kirim, dan komponen panel yang menampung semua bidang masukan saya. Saat saya mengetik di formulir, saya mengabaikan masukan saya ke "peredam formulir" yang disimpan di redux sehingga bilah alat saya dapat memiliki akses ke data sebelum saya mengirimkannya.

Selain itu, redux devtools juga luar biasa.

Astaga. Saya telah membaca Relay hari ini, dan saya harus mengakui bahwa kodenya tidak mudah dibaca dan juga tidak mudah dimengerti. Saya melihat beberapa contoh Redux dan saya dapat memahami konsep inti hanya dengan membaca kodenya.

Tutorial atau contoh Todo tampak sama sekali tidak elegan. Saya pikir React dan FLUX bangga karena menjadi sederhana. Saya belum merasakan perasaan itu dari Relay.

Mengingat ikatan Relay yang kuat dengan React dan relatif berlebihan dalam kompleksitas untuk sebagian besar aplikasi, saya lebih tertarik pada Falcor belakangan ini. Nyatanya, karena antarmukanya yang berbasis janji, ia sangat cocok dengan cara Anda melakukan sebagian besar perilaku asinkron di Redux. Dan karena dipisahkan dari React, saya dapat menggunakannya di mana saja di aplikasi saya dengan lebih mudah. Selain itu, rendering sisi server belum sepenuhnya matang , yang bukan merupakan permulaan bagi saya.

Saya juga menyukai react-resolver , yang _sortir_ mirip dengan "Relay Lite". Yang itu mungkin menjadi yang terbaik untuk proyek yang sangat sederhana atau yang mengandalkan API REST pihak ketiga.

@timdorr Sudahkah Anda mencoba menyimpan semua negara Anda di Falcor? Meminta reduksi Anda menggunakan objek Falcor, misalnya.

Belum. Saya masih dalam mode eksperimental dengannya dan saya punya ikan yang lebih besar untuk digoreng dalam proyek saya, jadi saya belum memberikan perhatian yang cukup.

Saya telah bermain-main dengan Falcor, dan saya sangat merekomendasikannya. Faktanya, saya sedang bekerja untuk mengintegrasikan aplikasi Redux dengan backend Falcor sekarang. Itu tidak memberi Anda agregasi kueri Relay, tetapi memiliki lapisan cache yang sangat canggih di perpustakaan kliennya yang mencegah pengambilan berlebih. Saya pikir itu mungkin cukup baik, tetapi waktu akan menjawabnya.

@gaearon Bagaimana menulis aplikasi web React dengan pengambilan data deklaratif dibandingkan dengan menulis aplikasi yang sama di Elm?

Menurut saya perbedaan utamanya adalah pengambilan data lebih deklaratif dengan Relay & GraphQL (Elm meminta Anda untuk menentukan URL, dan terserah Anda untuk memilah-milah data yang kembali), dan yang lainnya lebih deklaratif di Elm .

Sebenarnya, sepertinya ekosistem Elm bisa mendapatkan keuntungan dari port Relay / GraphQL.

Berkenaan dengan agregasi kueri, ada metode Model.batch . Ini membutuhkan interval (dalam milidetik) atau penjadwal tetapi, saya tidak menemukan banyak dokumentasi tentang penjadwal.

Jika Anda tidak keberatan saya bertanya, bagaimana Anda mengintegrasikan Redux dan Falcor? Semua usaha saya membuat saya frustrasi.

Saya juga tertarik melihat contoh redux Falcor. Saya telah membaca semua dokumen Falor dan setuju bahwa ini jauh lebih sederhana daripada relay / graphql. Meski kurang bertenaga.

Bagi siapa pun yang bertanya-tanya tentang hubungan Redux dengan Relay, dan apakah masuk akal untuk menggunakannya bersama, lihat: https://github.com/facebook/relay/issues/114

Intinya adalah Relay pada akhirnya akan menangani data dari berbagai sumber (backend, data efemeral lokal, dll.), Jadi Relay menggantikan implementasi Flux lain yang mungkin Anda gunakan.

https://github.com/facebook/relay/issues/168#issuecomment -135169255:

Perhatikan bahwa Relay adalah implementasi dari pola Flux (dapatkah Flux menggantikan dirinya sendiri? ;-).

Kami menggunakan Redux dan Relay banyak di OpenGov. Memang benar sejak pindah ke Relay, folder reducers/ menjadi jauh lebih kecil. Namun, kami menemukan bahwa Redux masih cukup berguna untuk manajemen status lokal tingkat aplikasi. Mungkin suatu saat Relay akan menggantikannya di area itu juga. Tapi seperti yang dikatakan @josephsavona sekali, "arsitektur Redux" benar-benar hanya ... fungsi :) Bahkan jika suatu hari Anda beralih dari perpustakaan Redux, Anda kemungkinan akan terus menggunakan pembaruan status yang tidak dapat diubah, aliran data reaktif, peredam fungsi, dll. untuk masa mendatang. Itulah bagian berharga dari Redux IMO, belum tentu pustaka <100-line yang ada di repo ini. (Oh, dan komunitas, tentu saja.)

Menurut saya, jika aplikasi Anda sangat padat data ala Facebook (banyak entitas bersarang dengan hubungan yang kompleks), sebaiknya Anda berinvestasi dalam backend GraphQL dan mempelajari Relay.

Setuju, tapi menurut saya GraphQL + Relay adalah investasi yang bagus bahkan untuk aplikasi berukuran sedang, terutama untuk proyek baru yang dimulai dari awal.

Apa pendapat kalian tentang https://github.com/gyzerok/adrenaline?

Kurang pas, karena tidak menggunakan Relay, tapi apa pendapat Anda tentang pendekatan tumpukan penuh opini ini dari Komunitas Meteor? https://github.com/mattkrick/meatier

Hanya arsitektur yang dalam seperti GraphQL / Relay atau Datomic / Om.Next yang dapat memecahkan masalah impedansi objek / relasional ... Berikut adalah pemikiran saya - umpan balik dihargai.

GraphQL / Relay: Akhir dari Redux?

Sepertinya ada banyak orang yang tertarik dengan topik ini (Relay / Redux, GraphQL, dan pengurangan kompleksitas). Saya sedang mengerjakan desain untuk klien GraphQL yang sederhana namun fungsional yang akan bekerja sangat baik dengan pendekatan Redux pada status aplikasi.

Penasaran apa pendapat orang tentang rangkaian prinsip desain ini: https://github.com/apollostack/apollo-client/pull/7/files?short_path=83772ba

Hanya menambahkan 2 sen saya di sini: Saya tidak berpikir bahwa Redux akan berakhir. Sederhana dan indah, dan cukup dalam banyak kasus. Ekosistem JS sangat cepat dan sulit untuk diikuti, dan Redux, seperti React dalam beberapa hal, adalah tonggak sejarah yang dapat kami andalkan untuk beberapa waktu. Kami tidak bisa mengembangkan alur kerja kami setiap bulan (atau setidaknya, saya tidak bisa), dan saya pikir Redux adalah pilihan yang sangat bagus saat ini. Relay (dan pengambilan data secara umum) tidak diperlukan di banyak project…

@gaearon sudah beberapa bulan sejak Anda membuat posting ini, dan Anda baru saja memberikan ceramah tentang Redux pada konferensi React. Menurut Anda, di mana kita sekarang dalam hal integrasi GraphQL dengan Redux dibandingkan dengan Relay /, atau mungkin kombinasi dari ketiganya?

@likeabbas jika Anda mencari integrasi GraphQL-Redux, coba Apollo Client: http://docs.apollostack.com/apollo-client/index.html

Kami belum memiliki paritas fitur 100% dengan Relay, tetapi kami semakin dekat.

@gaearon menggemakan pertanyaan dari @likeabbas : "Menurut Anda, di mana kita sekarang dalam hal integrasi GraphQL dengan Redux dibandingkan dengan Relay /, atau mungkin kombinasi ketiganya?"

Beberapa pemikiran singkat. Redux adalah kerangka kerja umum yang memberikan keseimbangan antara struktur yang cukup dan fleksibilitas yang cukup. Dengan demikian, ini menyediakan platform bagi pengembang untuk membangun manajemen status yang disesuaikan untuk kasus penggunaan mereka, sambil dapat menggunakan kembali hal-hal seperti debugger grafis atau middleware. Kasus penggunaan itu tampaknya tidak akan hilang, jadi daripada "apakah waktu Redux telah datang dan pergi", mungkin pertanyaan yang lebih menarik adalah: jika Anda membangun klien GraphQL, apakah masuk akal untuk membangun di Redux?

Yang mana saya akan menjawab bahwa tidak jelas apakah ada satu jawaban yang benar. Membangun di Redux mungkin mendapatkan keuntungan dari integrasi (perkakas bersama, data bersama), sementara membangun pendekatan khusus lebih banyak pekerjaan tetapi memungkinkan lebih banyak perkakas khusus domain dan dapat memungkinkan kinerja yang lebih baik. Seperti banyak hal dalam pengembangan perangkat lunak, itu tergantung pada kasus penggunaan!

@josephsavona : itu adalah ringkasan _great_ dari Redux! Kami mungkin harus mencurinya untuk dokumen di suatu tempat :)

Ya judul utas ini tidak optimal, dan sepertinya pertanyaannya sudah agak habis. Mungkin sudah waktunya untuk memindahkan diskusi ke tempat lain.

>.> lock the issue

Saya hanya akan menutup ini. Tidak yakin apakah ada resolusi yang bisa didapat. Redux berfungsi untuk beberapa orang dan itu cukup bagus untuk saya.

Ups, tombol salah. Maaf tentang itu 😄