Apakah mungkin tanpa Redux?

Hari ini Anda dapat menemukan banyak posisi di mana reaksi / reduks diperlukan. Bereaksi hebat, tidak ada pertanyaan. Pertanyaan untuk Redux adalah apakah mungkin tanpa itu. Jika Anda sedikit google, ada artikel yang solid di Habré , di mana penulis mengajukan pertanyaan yang sama. Dalam artikel dengan contoh sederhana (todoList), metode this.updateViews () dipanggil terlalu sering (tujuh hingga delapan kali) dan tampaknya lebih mudah dilakukan.

Gagasan utama di sini adalah model yang dapat diamati, bereaksi bertanggung jawab atas yang dapat diamati, satu-satunya yang tersisa adalah membuat model.

Sebelum membuat model, beberapa kata tentang desain (arsitektur) klien:

indeks - data mentah
sejarah - larik [model]
pengamat - model
lihat - kesalahan, fokus, bendera

index.jsx - titik masuk program untuk layar pengguna. Indeks membuat semua komponen dengan data default, membuat kueri sinkron, menggambar ulang komponen dengan data baru.

// index.jsx <History> <Observer> <HeaderView /> <MainView /> </Observer> </History> 

Observer.jsx bertanggung jawab untuk menyinkronkan model untuk beberapa tampilan. Misalnya, Petya mengisi formulir penawaran dan melihat pratinjau waktu-nyata di header halaman. Pengamat menyimpan objek model, menyediakan api: onModelChange (bidang, nilai) ke komponen turunan.

History.jsx adalah tumpukan objek model, di mana api: commit dan rollback.

Model.js adalah apa yang dapat dimasukkan oleh pengguna dengan pena - yaitu yang paling berharga. Data lain dalam model tidak perlu disimpan. Model bukan komponen reaksi, tetapi kelas js biasa.

 class Model { constructor(other = {}) {} // copy constructor (and default too) isEqual(other) {} // operator == less(other) {} // operator< swap(other) {} hash() {} fieldNameConstrains() {} //see below please } 

Pembuat salinan setidaknya diperlukan untuk Riwayat. Metode isEqual adalah untuk popup-unsaved-changes (yang jauh lebih nyaman daripada flag in state). Metode fieldNameConstrains adalah untuk bidang dependen.

Secara kasar, jika ada bidang dependen, mereka perlu diubah semua berturut-turut.

 class Model { // constrains // distance <== velocity * time velocityConstrains(newVelocity) { this.velocity = newVelocity; this.distance = this.velocity * this.time; } timeConstrains(newTime) { … } distanceConstrains(newDistance) { this.distance = newDistance; this.time = this.distance / this.velocity; } } 

Dari pengalaman pribadi, sesuatu seperti model.field.onchange tidak berfungsi, karena kadang-kadang Anda perlu memanggil pembuat salinan dan acara pertukaran tidak diperlukan sama sekali.

Lihat.jsx

 class View extends React.Component { state = { errors: {}, focus: {}, … } render() { … <input value={this.props.model.title} onChange={e => this.props.onModelChange('title', e.target.value)} /> … } } 

Validasi Validasi tidak perlu dilakukan dalam model. Ini harus dilakukan dalam tampilan (jangan lupa bahwa tampilan adalah layar pengguna dan tidak seluruh model dapat ditampilkan di layar). Validator adalah seperangkat predikat. Hanya ada dua algoritma untuk validasi: 1) kami menemukan semua kesalahan dalam formulir atau 2) kami menemukan kesalahan pertama. Sebagai contoh

 class View extends React.Component { onClickSaveButton() { const mapper = { title: () => model.title.length && !maxLenValidator(model.title, 25), price: () => !(model.price % 40 == 0), url: () => !urlValidator(model.url), … } const errors = map(mapper, (validator, key) => { return validator() ? key : undefined; }).filter(Boolean); } //       

Hak akses. Hal utama di sini adalah tetap tinggal dan tidak menggunakan warisan. Idenya adalah bahwa model tersebut berisi semua bidang dan kami memangkas bidang untuk peran. Artinya, ini adalah daftar putih, bidang yang tersisa dalam model tetap secara default. Satu langkah ditambahkan untuk validasi - kami membuat proyeksi objek validasi (itu juga mapper, lihat di atas), yaitu, kami hanya memvalidasi bidang yang diperlukan.

Tentang produksi. Pendekatan ini telah berputar dalam produksi selama satu tahun sekarang - ini adalah antarmuka untuk membuat kampanye iklan, termasuk spanduk. Bentuk kompleksitas yang berbeda-beda - mulai dari satu model ke layar, diakhiri dengan banyak model dari jenis yang berbeda. Di sini Anda dapat menambahkan bahwa backend suka mengirim struktur bersarang, Anda tidak boleh malu dan hanya menyimpan struktur datar dalam tampilan.

Tentang metode model isEqual. Di suatu tempat di utils.js akan ada metode isEqual dan isEqualArray:

  function isEqual(left, right) { return left.isEqual(right); } isEqualArray(v1, v2) { if (v1.length !== v2.length) { return false } for (var k = 0; k != v1.length; k++) { if (!isEqual(v1[k], v2[k])) { return false; } } return true; } 

Anda perlu mencoba untuk tidak membuat model bersarang. Jangan lupa bahwa modelnya adalah data pengguna, bukan struktur data.

Referensi:

→ Waktu
→ Dua