Kata pengantar
Ini adalah posting pertama saya di Habré, jadi jangan menilai terlalu kasar (baik, atau menilai, tapi secara konstruktif ).
Saya ingin mencatat bahwa dalam pendekatan ini, keuntungan utama bagi saya adalah kami secara jelas menggambarkan dan mendelegasikan logika bisnis dengan modul. Satu modul bertanggung jawab untuk satu hal dan untuk sesuatu yang sangat spesifik. Artinya, dengan pendekatan ini, selama proses pengembangan, tidak ada pemikiran: "di mana saya lebih baik (lebih tepat) melakukan ini di sini?" Dengan pendekatan ini, jelas terlihat di mana tepatnya tugas / masalah tersebut harus diselesaikan.
Struktur file
Struktur proyek + adalah standar. Saya akan mencoba memberi tahu Anda secara singkat apa yang digunakan dari apa yang terdiri dari rakitan itu sendiri
- Untuk menyiapkan tindakan asinkron, saya menggunakan saga middleware - hal yang jauh lebih fleksibel dan kuat terkait thunk middleware
- Saya memiliki komponen styling modul-css. Sebenarnya, konsepnya sama dengan komponen bergaya, tapi entah mengapa lebih nyaman bagi saya
- Sebuah interlayer antara kontainer dan komponen yang mengontrol props yang dilempar dari penyimpanan ke dalam komponen (pemfilteran, memoization dan kemampuan untuk dengan mudah memanipulasi nama field dari setiap bagian dari status aplikasi) - pilih ulang
Redux saga
Dokumentasi saga redux
Inti utama dari saga (dan tidak hanya) adalah kita memisahkan logika bisnis dalam menangani permintaan berdasarkan modul. Setiap saga bertanggung jawab atas bagian API-nya sendiri. Jika saya perlu mendapatkan data pengguna dan melakukan tindakan pada tanda terima yang berhasil - saya akan melakukannya dalam modul terpisah usersSagas.js
Faktor utama (bagi saya) yang mendukung saga adalah:
UPD (menambahkan poin tentang janji-neraka)
- 1) Fakta bahwa tindakan, dengan cara yang bersahabat, seharusnya hanya fungsi yang memberikan suatu objek. Jika beberapa tindakan terlihat berbeda (dan begitulah yang terjadi dengan penggunaan thunk), saya ingin membawanya ke satu bentuk, karena entah bagaimana ini tidak sesuai dengan satu konsep. Saya ingin memindahkan logika permintaan dan bekerja dengan data untuk permintaan ke dalam modul terpisah - untuk inilah saga
- 2) Sebagai aturan, jika kita perlu membuat beberapa permintaan yang menggunakan data dari tanggapan ke permintaan sebelumnya (dan kita tidak ingin menyimpan data perantara di penyimpanan?), Redux-thunk mengundang kita untuk membuat tindakan baru di mana kita akan memanggil yang lain permintaan async-action, di mana 2 lagi (misalnya) iterasi yang sama dibuat. Itu sangat menjanjikan dan biasanya terlihat berantakan dan, pada prinsipnya, tidak nyaman untuk digunakan (terlalu banyak bersarang), seperti untuk saya
css-modules / komponen bergaya
Saya sering melihat di proyek bahwa orang menulis aturan untuk menata komponen di beberapa modul css umum.
Saya sangat menentangnya. Komponennya adalah sistem yang terisolasi. Ini harus dapat digunakan kembali sebanyak mungkin . Oleh karena itu, alangkah baiknya untuk menatanya secara terpisah.
Pilih kembali
Penyeleksi memiliki beberapa tujuan:
- , . , , ( , ). , , . - getFilteredItems,
- ,
- . - . - . friends. , . , . , , friends contacts. reselect , , . — .
Itu karena poin terakhir saya tenggelam karena fakta bahwa kami membuat ulang untuk setiap bersin. Pilih ulang - tidak hanya untuk memoisasi, tetapi juga untuk pekerjaan yang lebih nyaman dengan menggambar pohon status aplikasi
Komponen dan Kontainer
Dalam pendekatan klasik untuk React (tanpa menggunakan library untuk menyimpan penyimpanan sebagai entitas terpisah), ada dua jenis komponen - Presentational dan Container-Components. Biasanya (seperti yang saya pahami) ini bukan divisi folder yang ketat, melainkan divisi konseptual. Komponen
penyajian itu bodoh. Faktanya, mereka hanyalah tata letak dan tampilan data yang dimasukkan ke dalamnya sebagai properti. (contoh komponen seperti itu dapat ditemukan di atas dalam modul-css)
Komponen-Kontainer - komponen yang merangkum logika kerja, misalnya, siklus hidup komponen. Mereka bertanggung jawab untuk menjalankan tindakan yang bertanggung jawab untuk meminta data, misalnya. Mereka mengembalikan tata letak minimum, karena tata letak diisolasi dalam Komponen-Presentasional.
Contoh + -Container-Component:
Redux Containers sebenarnya adalah lapisan antara sisi redax dan komponen react. Di dalamnya, kami memanggil penyeleksi dan melempar tindakan ke props react komponen.
AKU KARENA memiliki wadah sendiri untuk setiap bersin. Pertama, ini memberi Anda lebih banyak kendali atas props yang dilemparkan ke dalam komponen, dan kedua, ini memberi Anda kendali atas kinerja menggunakan pemilihan ulang.
Sering terjadi bahwa kita perlu menggunakan kembali satu komponen, tetapi dengan bagian penyimpanan yang berbeda. Ternyata untuk ini kita hanya perlu menulis wadah lain dan mengembalikannya bila perlu. Artinya, hubungan Banyak dengan satu (banyak adalah wadah, satu adalah komponen. Bagi saya, ini nyaman dan secara konseptual)
Saya juga ingin memberikan contoh yang lebih sering dalam mendukung penampung sebagian besar komponen.
Kami memiliki larik data (larik pengguna, misalnya), yang kami terima dari beberapa API. Kami juga memiliki gulungan tak terbatas, yang tidak akan ditolak oleh pelanggan. Kami menggulir ke bawah untuk waktu yang sangat lama dan memuat sekitar 10k + data. Dan sekarang kami telah mengubah beberapa properti dari satu pengguna. Aplikasi kita akan sangat lambat karena:
- Kami memasang penampung global ke seluruh halaman dengan daftar pengguna
- Saat mengubah satu bidang dari salah satu elemen array pengguna, array BARU dengan elemen dan indeks baru dikembalikan di peredam pengguna
- Semua komponen yang ditempatkan di pohon komponen UsersPage akan digambar ulang. Termasuk setiap komponen Pengguna (elemen array)
Bagaimana Anda bisa menghindari ini?
Kami membuat kontainer
- array dengan pengguna
- elemen array (satu pengguna)
Setelah itu, dalam komponen, yang dibungkus dalam wadah "array dengan pengguna", kita mengembalikan wadah "elemen array (satu pengguna)" dengan kunci (prop diperlukan react) dilemparkan ke sana, indeks
Dalam wadah "elemen array (satu pengguna)" di mapStateToProps kami adalah yang kedua sebagai argumen, kami mengambil ownProps dari komponen yang dikembalikan kontainer (di antaranya adalah indeks). Dengan indeks, kami menarik langsung dari toko hanya satu elemen dari array.
Lebih lanjut, akan jauh lebih mudah untuk mengoptimalkan penggambaran ulang hanya elemen yang diubah (seluruh array digambar ulang, karena di reducer kita membuat semacam peta yang mengembalikan array BARU dengan indeks baru untuk setiap elemen) - di sini kita akan dibantu dengan memilih kembali
array
kontainer: elemen kontainer:
element-selector:
Jika ada tambahan, saya akan membacanya dengan senang hati di komentar.