React-native-router-flux: Mengapa v4 ada jika didasarkan pada navigasi reaksi?

Pertanyaan bagus. Saya akan mengirimkan Lighting Talk tentangnya untuk ReactiveConf:
https://blog.reactiveconf.com/open-call-for-reactiveconf-lightning-talks-2017-a4f5394e5f96

Akan segera mempostingnya.

Proposal pembicaraan saya
https://Gist.github.com/aksonov/e2d7454421e44b1c4c72214d14053410

Saya mulai dengan React Navigation dan memiliki banyak masalah untuk menjalankannya sebagian besar karena kurangnya dokumentasi yang baik untuk contoh kompleks dan kasus penggunaan. Saya juga memiliki bug yang berbeda. Dengan semua itu saya juga mendapat dukungan yang sangat sedikit, saya bahkan mengirim umpan balik dan mempertanyakan mengapa FB menjadikan React Navigation sebagai lib router resmi, saya rasa tidak seharusnya.

Saya melihat React Native Router sebagai pembungkus React Navigation API sehingga lebih mudah digunakan dan dukungan yang lebih baik.

@Maxwell2022 ini akan membantu ketika membandingkan keduanya...

1. react native router flux (RNRF) lebih matang dan tidak terlalu bermasalah (hanya 7 dari ~1600 masalah yang terbuka, dibandingkan reactNavigation yang memiliki 75% dari ~1000 masalah yang masih terbuka (tidak layak produksi, dan menurut saya tidak dapat diterima) )

2. jika Anda hanya seorang programmer, reactNavigation adalah pilihan yang tepat, tetapi jika Anda seorang programmer dan pebisnis yang membutuhkan efisiensi, maka reactNavigation adalah pilihan yang buruk (inilah alasannya: reactNavigation lebih rumit dari yang seharusnya, dan memiliki kurva belajar yang jauh lebih lama, terutama ketika aplikasi Anda memiliki persyaratan navigasi yang rumit dan dokumentasi lib yang tidak memadai membuat Anda tidak perlu bereksperimen selama berjam-jam (saya setuju dengan @AlmogRnD )... ini bagus untuk programmer yang mencari tantangan dan ingin meningkatkannya keterampilan pemecahan masalah, tetapi tidak dapat diterima untuk toko pengembang atau pebisnis di mana efisiensi waktu diperlukan )

3. reactNavigation, pada intinya, memang memiliki API yang bagus, tetapi tidak perlu rumit (saya setuju dengan @AlmogRnD )... tujuan lib RNRF ini dan apa yang dilakukan @aksonov dengan v4, bukan untuk bersaing dengan atau mengganti reactNavigation, tetapi untuk mengabstraksi semua kerumitan yang tidak perlu dari reactNavigation

4. jika Anda penggemar rendering komponen/layar bersyarat, yang merupakan pola yang sangat umum di React Native, maka RNRF lebih kondusif untuk pola ini

5. react native kehilangan haknya untuk menyebut dirinya sebagai kerangka kerja yang tidak memiliki opini ketika ia memilih satu perpustakaan di atas yang lain (seperti pemerintah yang mencoba memilih pemenang dan pecundang perusahaan di pasar)... reactNavigation... saya yakin keputusan aksonov untuk menggunakan api reactNavigation di RNRF v4, adalah untuk membuat "asosiasi" dengan bias reaksi-asli, dan mempertahankan relevansi perpustakaan ini...

6. reactNavigation tidak memiliki implementasi modal yang sebenarnya*, di mana seperti RNRF (dan dengan modal saya mengacu pada pop-up gaya Prompt/peringatan dengan latar belakang abu-abu), dan ketika Anda menyebut diri Anda perpustakaan navigasi, ini menjadi kelalaian mencolok / terang-terangan saya bisa menambahkan

https://github.com/react-community/react-navigation/issues/2031

Itu bukan hanya untuk saya tetapi untuk semua orang. Ini harus ditambahkan di README.

Apakah lebih masuk akal untuk memusatkan upaya pada peningkatan navigasi reaksi (inti atau dokumentasi)?

Saya telah menggunakan RNRF di proyek sebelumnya dan saya juga menghadapi frustrasi karena dokumen tidak mutakhir atau informasi sulit ditemukan. Saya pikir ini adalah masalah umum untuk setiap perpustakaan yang kompleks, dokumentasi mungkin adalah bagian yang lebih sulit untuk dipelihara.

@Maxwell2022 Meningkatkan navigasi reaksi bukan?? Mungkin Anda bercanda, sungguh. Hanya untuk percobaan saya mengirimkan PR yang sangat berguna https://github.com/react-community/react-navigation/pull/1999 , butuh 2 minggu (!) untuk menyelesaikan ulasan, saya memperbaiki semua (!) saran dari pengulas dan setelahnya yang satu dari penulis mengatakan bahwa PR saya tidak diperlukan karena dia mengerjakan 'refactoring' navbar API! Huh, mungkin perubahan baru yang melanggar... Dan periksa PR lainnya, banyak PR yang sangat berguna tidak digabungkan untuk BULAN.

Dan ya, dokumen adalah bagian yang lebih sulit untuk dipelihara, terutama untuk proyek sumber terbuka. Masalah yang kebanyakan masyarakat lebih suka hanya menggunakan open source tanpa kontribusi apapun.

@aksonov jika ReactNavigation sulit untuk ditingkatkan (karena penggabungan PR yang lambat dan sebagainya) bukankah itu akan menjadi masalah untuk v4?

Banyak masalah seperti kustomisasi navbar (seperti menyetel gambar navbar kanan/kiri), pemrosesan tindakan (seperti menambahkan popTo yang tidak terjawab) dapat diselesaikan dengan RNRF.
Tapi untuk beberapa masalah seperti #2012, ya, kita harus menunggu untuk memperbaikinya. Kita dapat melakukan fork ReactNavigation dan menerapkan PR yang disarankan di masa mendatang (benar, banyak PR memecahkan masalah tetapi masih belum digabungkan).

Bagaimanapun, v3 didasarkan pada reaksi-asli-eksperimental-navigasi usang, jadi saya tidak melihat alternatif yang lebih baik.

Saya sedang menerapkan react-native-router-flux pada sebuah proyek sekarang dan saya mempertahankan v3 untuk saat ini. Saya mencoba V4 dan itu merusak semuanya.
Saya pikir saya akan menunggu sedikit untuk v4 menjadi sedikit lebih matang dan kemudian saya akan mencobanya lagi.
Sementara itu saya akan membuat proyek sampingan untuk bermain-main dengan v4 dan melihat apakah saya dapat membantu dengan cara apa pun.

Ini 2 sen saya.
Saya telah menggunakan RNRF di salah satu proyek saya untuk waktu yang cukup lama, dan inilah yang saya hadapi:

• transisi yang menyakitkan, saya memiliki banyak transisi yang akan memakan waktu cukup lama (sampai beberapa detik) sebelum memulai setelah menekan tombol. Dan saya pasti sudah menggunakan Manajer Interaksi.
• Hirarki perutean sulit digunakan. Saya sering menghabiskan waktu berjam-jam sebelum mengatur semuanya dengan benar dan dapat berpindah dari satu adegan ke adegan lainnya
• Masih tidak mengerti apa arti PUSH/PULL yang berbeda dan hal-hal lain sebenarnya
• Mengakses perutean sebagai ketergantungan implisit daripada menjadikannya sebagai alat peraga khusus untuk RNRF dan entah bagaimana mengganggu. Ini memasangkan proyek dengan erat ke navigasi.
• Anda mungkin mengatakan doc buruk tentang ReactNavigation, tetapi doc untuk RNRF tidak ramah sama sekali. Contoh Terperinci tidak pernah benar-benar membantu saya, dan doc tidak memberi tahu banyak tentang cara kerjanya. Dokumentasi ReactNavigation mungkin rusak atau beberapa, tetapi saya pribadi tidak pernah mengalami masalah dengannya, karena saya mutakhir. Saya bahkan mulai mengerjakan penulisan ulang dokumen secara lengkap sekali, tetapi saya tidak punya cukup waktu untuk menyelesaikannya. Saya percaya dokumen RNRF memerlukan penulisan ulang dokumentasi yang lengkap.

Sejak saya beralih ke React Navigation, ya ada cukup banyak hal yang belum saya gunakan, dan ya itu benar-benar banyak abstraksi yang sangat memperumit banyak hal. Tetapi sejauh ini satu-satunya masalah yang saya miliki adalah betapa menyakitkannya menerapkan sistem login yang menonaktifkan pengguna untuk kembali. Dengan sedikit kode peretasan, itu berhasil tetapi tetap saja, itu tidak normal. Mari kita ingat bahwa itu muda dan didorong di sekitar kebutuhan khusus. Saya percaya itu akan menjadi lebih baik.

Bukan bermaksud meludahi pekerjaanmu, guys. RNRF benar-benar pilihan yang luar biasa, saat itu adalah yang terbaik yang saya temukan, dan banyak artikel di google mendukungnya. Tapi saya benar-benar frustrasi dengan masalah di atas. Dan React Navigation cukup menyelesaikannya bagi saya.

Setuju banget sama

Mengenai transisi lambat:
@Rewieer apakah Anda melewatkan banyak alat peraga atau memuat data dari status melalui Redux atau yang serupa? Juga apakah ini hanya diuji di simulator iOS atau Android?

Saya bertanya karena tidak ada masalah dengan transisi. Satu-satunya saat saya melihat transisi yang lambat adalah ketika saya memiliki beberapa kode kereta di proyek asli reaksi saya. Sesuatu terdengar off meskipun.

Maaf keluar topik.

@typeslower sejauh ini berfungsi dengan baik di emulator tetapi sangat lambat di ponsel.
Saya ingat saat itu saya menggunakan Immutable dengan Redux tetapi basis entitas tidak begitu berat. Saya memiliki Redux-Persist dengan debouncing 200ms juga. Jadi mungkin memuat data dari status menggunakan Immutable dengan sort & filter dapat membuat kesepakatan tetapi, pada daftar <100 elemen sulit untuk berpikir ini dapat memiliki dampak sebesar ini.
Tidak pernah mengalami di iOS karena saya tidak punya barang Apple. Ini telah diuji hanya di Android. Tapi saya ingat menggunakan alat navigasi lain baik-baik saja.

Saya akan minta maaf karena saya masih kebalikan dari V4, karena menurut saya V3 masih yang terbaik.

• V3 memberikan konsistensi dalam pengalaman pengguna navigasi di seluruh perangkat & sistem, yang paling saya sukai.
• Ya, di V3 react-native-experimental-navigation sudah usang sejak lama, tetapi masih valid untuk dipertahankan, meskipun V3 tidak dipertahankan lagi, saya akan mencoba yang terbaik untuk mempertahankan salinan fork dari V3.
• V3 doc tidak cukup baik? Memang tidak masalah, karena kita bisa mendapatkan awal yang lambat, tapi cepat atau lambat kita akan mencari tahu semuanya, ada baiknya, bagi saya itu tidak cukup di awal, tidak sekarang.
• V4 cukup banyak diperlukan dan saya mengerti semua tujuannya, tetapi navigasi reaksi adalah masalah besar saat ini, karena saya belum siap untuk terjun ke dalamnya dengan aplikasi produksi.

Omong-omong, @Rewieer , saya telah melihat masalah yang sama, dan saya membuat sedikit perubahan untuk mencapai transisi yang lebih baik di antara adegan dalam navigasi, menunda Animiated.timing di DefaultReducer, untuk membuat dan menyelesaikan adegan akan bolak-balik antara javascript inti dan kode asli, jika keduanya mulai bersamaan, ini bisa menjadi gangguan. Alasannya, untuk menjaga tampilan konten utama hanya muncul setelah selesai di Pengelola Interaksi.

Bagaimanapun, saya masih sangat mendukung untuk versi baru, tetapi untuk saat ini tetap menggunakan V3. Karena saya sangat menyukai konsistensi di antara perangkat yang berbeda.

Ini benar-benar tergantung pada seberapa cepat Anda perlu mengirimkan pekerjaan Anda. Saya bekerja di lingkungan agen pemasaran dan RNRF sangat berharga bagi kami. Tidak ada waktu untuk menguasai kerumitan React Navigation, jadi kami memutuskan untuk menggunakan RNRF sejak hari pertama. Saya mengalami sedikit kesulitan dengan dokumentasi, tetapi saya berhasil melewatinya dan mengirimkan aplikasi yang saat ini ada. berjalan pada 60FPS di sebagian besar perangkat.
Sekali lagi - pekerjaan saya adalah mengirimkan aplikasi pada tanggal tertentu. Saya tidak peduli jika RNRF adalah abstraksi dari teknologi lain. Saya tidak peduli jika satu proyek memiliki 100 masalah terbuka dan 200 lainnya. Saya tidak peduli tentang bagian-bagian yang mendasari RNRF. Itu menyelesaikan semua masalah saya dan saya 100% senang dengan itu.

@rodperottoni tolong beri tahu kami lebih banyak tentang kerumitan seperti apa yang Anda bicarakan ketika Anda merujuk ke React Navigation, hanya karena penasaran.

@Rewieer dengan senang hati.
Perlu diingat saya tidak menentang React Navigation. Alasan mengapa saya menggunakan RNRF adalah karena memungkinkan saya melakukan hal yang sama, tetapi lebih cepat. Saya tidak tahu bagaimana menjelaskannya, tetapi pengalaman pengembang hanya... lebih baik.

• Bagi saya, jauh lebih masuk akal untuk mendeklarasikan rute saya di BEJ murni, seperti yang diizinkan oleh RNRF. Tidak hanya lebih sederhana, tetapi juga lebih bersih dan lebih mudah dibaca. Sekarang saya tidak mengatakan bahwa JS sulit dibaca (karena rute React Navigation dideklarasikan dalam js murni), tetapi kadang-kadang ketika saya memiliki seorang desainer atau manajer proyek yang meninjau sesuatu dengan saya, itu jauh lebih cepat bagi saya (dan tidak terlalu membosankan bagi mereka ) untuk menemukan rute dan langsung mengubahnya.
• Saya benar-benar percaya bahwa konvensi penamaan yang baik dapat membuat segalanya lebih mudah. Saya pribadi lebih menyukai konvensi penamaan pada RNRF daripada yang digunakan pada React Navigation.
• Meskipun dokumentasi RNRF tidak "lengkap" seperti React Navigation, saya tetap menyukainya. GIF dan contoh yang dipasang @aksonov membuat saya ketagihan sejak pertama kali mempelajari lib ini. Mereka juga diperbarui baru-baru ini dan jauh lebih baik daripada dokumen v3.
• Last but not least, mencoba perpustakaan baru membutuhkan waktu. RNRF bekerja dengan sempurna untuk saya, dan oleh karena itu saya tidak melihat nilai dalam mencoba perpustakaan perutean lain tanpa alasan yang baik. Mungkin jika saya menemukan masalah besar, saya akan mempertimbangkan untuk melompat ke kapal lain, tetapi untuk saat ini saya cukup senang dengan RNRF (terima kasih @aksonov).

Pemberitahuan: masalah ini telah ditutup karena tidak aktif selama lebih dari 30 hari.
Anda dapat membuka kembali masalah ini jika telah ditutup karena kesalahan.