Get best of the week

Redux Toolkit tidak lagi diperlukan?

Masalah jumlah kode boilerplate yang sangat besar saat menggunakan Redux diketahui semua orang, semua orang memecahkannya sebaik mungkin. Dan kami menggunakan kruk dan sepeda yang berbeda pada proyek yang berbeda, tanpa kehilangan harapan menemukan sesuatu yang terstandarisasi dan nyaman. Sedikit lebih dari setahun yang lalu, kami putus asa dengan pencarian kami dan serius mengambil solusi untuk masalah ini. Apa yang terjadi dijelaskan di bawah ini.

Kisah penampilan


Perusahaan kami sedang mengembangkan proyek untuk startup di seluruh dunia. Dan untuk orang-orang gila yang terinspirasi ini, yang paling penting (atau salah satunya) adalah waktu. Sebelumnya memasuki pasar - peluang bertahan hidup yang lebih tinggi. Oleh karena itu, kami selalu berusaha mengurangi waktu pengembangan tanpa mengorbankan kualitas, dan mengurangi jumlah kesalahan yang disebabkan oleh faktor manusia. Sebagian besar, kami memilih sesuatu yang standar dan lebih atau kurang stabil. Dalam hal ini, tidak ada yang siap yang dapat ditemukan, jadi mereka menyingsingkan lengan baju mereka dan mulai melihat apa yang bisa disikluskan di sini.



Seperti biasa, kami mulai dengan uraian masalah dan mendapatkan yang berikut:

  • Setiap pengembang memiliki aksennya sendiri yang halus saat menulis kode, sulit untuk mencapai implementasi konsep "kode yang dipersonalisasikan";
  • Banyak kode (boilerplate, copy-paste dan semua masalah berikutnya), 100+ baris pada CRUD;
  • Banyak waktu dihabiskan untuk menulis hal-hal dasar. Anda akan melupakan satu hal, yang lain: mengatur pemuatan, menangani kesalahan, dll.;
  • Struktur toko berbeda dari proyek ke proyek, dan kadang-kadang di antara berbagai bagian proyek.

Pertanyaan yang diajukan dengan benar atau masalah yang dirumuskan adalah setengah dari solusi. Setelah berpikir sebentar, kami memperkenalkan aturan untuk pembentukan toko, menjelaskan strukturnya dan memutuskan untuk memperbaiki dan menyisir kode. Terlepas dari kenyataan bahwa basis kode kami tidak terlalu besar, kami segera menemukan jumlah kode yang perlu diubah.

Sementara PM bingung tentang di mana mendapatkan beberapa jam lebih banyak hari, ada beberapa penggemar yang menghasilkan dan menerapkan ide sederhana ke titik banalitas. Ya, ide-ide cerdik, setelah muncul, selalu tampak sederhana. Dan idenya adalah ini: hanya menghasilkan potongan-potongan kode terpisah daripada menulis ulang secara manual. Saya tidak ingin menggunakan potongan dan mendapatkan lembar di pintu keluar, karena setiap perubahan menyebabkan bencana dan refactoring berulang, sehingga dengan cepat menghilangkan fungsi yang mengambil beberapa parameter sebagai input dan membangun peredam, aksi dan saga. Jadi versi pertama komunikasi lahir ( @ axmit / redux-communications) Nama "komunikasi" lahir entah bagaimana dengan sendirinya, karena perpustakaan ini menyatukan saga dan komponen. Dan begitulah seterusnya ...

Segera setelah itu, kebahagiaan datang. Baik, atau segera. Waktu pengembangan menurun sekitar 20% (seperti yang kami hitung - topik artikel terpisah). Pertama-tama, karena berkurangnya jumlah bug perayapan secara signifikan. Dan ini belum lagi fakta bahwa pengembang jauh lebih kecil kemungkinannya untuk melakukan kesalahan bodoh dengan tidak memperhatikan.



Linus Torvalds pernah berkata: “Obrolan tidak berharga. Tunjukkan kodenya. ”Dan saya sepenuhnya setuju dengannya. Saya tidak akan mengutip atau menulis ulang dok atau memberikan lembar kode di sini.Saya hanya akan memberikan contoh kecil. Tautan ke deskripsi lengkap tentang perpustakaan dan kotak pasir dengan contoh-contoh juga dapat ditemukan di akhir artikel.

Pertimbangkan tugas khas - kita perlu membuat CRUD untuk beberapa entitas. Ambil contoh tugas. Saya menganggap tidak berguna untuk menggambarkan versi standar, sebagai itu akan memakan banyak ruang, dan semua orang yang menemukan editor cenderung membayangkan bagaimana penampilannya. Dan untuk mendapatkan komunikasi, Anda perlu melakukan hal-hal berikut:

1. Jelaskan transportasi, tanpa itu di mana saja

const basePath = `/api/task`;

const taskTransport = {
   add: task => axios.post(`basePath`, task).then(r => r.data),
   get: id => axios.get(`${basePath}/${id}`).then(r => r.data),
   update: task => axios.put(`${basePath}/${task.id}`, task).then(r => r.data),
   delete: id => axios.delete(`${basePath}/${id}`, task),
   getCollection: () => axios.get(basePath).then(r => r.data)
};

2. Jelaskan namespace nama
const namespace = 'task';

3. Buat strategi untuk menciptakan komunikasi
const strategy = new CRUDStrategy({
   namespace,
   transport: taskTransport
});

4. Buat komunikasi
const taskCommunication = buildCommunication(strategy);

5. Hubungkan reduksi dan kisah dari komunikasi, seperti biasa
taskCommunication.reducers
taskCommunication.sagas

6. Setelah itu, tetap menghubungkan sisi ke komponen
taskCommunication.injector(MyComponent)

7. Dan mulai menggunakan
componentDidMount() {
   const { getTaskCollection } = this.props;
   getTaskCollection();
}

render() {
   const { taskCollection } = this.props;
   return  taskCollection.data.map(item => <span>{item.title}</span>)
}

Sebenarnya, baik transportasi dan komponen perlu dibuat dalam hal apa pun, dan kode komunikasi lengkapnya adalah sebagai berikut:

import { taskTransport } from './task.transport';
import { CRUDStrategy, buildCommunication, StoreBranch } from '@axmit/redux-communications';
 
const namespace = 'task';
 
const strategy = new CRUDStrategy({
   namespace,
   transport: taskTransport
});
 
export const taskCommunication = buildCommunication(strategy);


Ini semua yang perlu Anda lakukan untuk memiliki CRUD yang berfungsi penuh. Jika Anda perlu melakukan sesuatu yang lebih rumit, Anda dapat memperluas komunikasi CRUD atau menggunakan Komunikasi BaseC. Dalam kasus ekstrem, di balik tudung itu masih editor kuno yang baik dengan semua fitur-fiturnya. Fleksibilitas belum terpengaruh. Transport ditempatkan di layer terpisah, dan implementasinya bisa apa saja. Kami memiliki graphQL di proyek kami dan pertanyaan sederhana menggunakan aksioma, dan kami tidak mengalami kesulitan dalam hal ini. Seorang pembaca yang penuh perhatian mungkin telah memperhatikan bahwa perpustakaan mengekspor kisah-kisah, dan ini adalah salah satu keterbatasan yang paling signifikan. Jika karena alasan tertentu Anda tidak dapat menggunakan kisah-kisah, perpustakaan ini, sayangnya, tidak cocok untuk Anda.

Kenapa sekarang?


Keputusan untuk menulis artikel muncul setelah membaca artikel ini . Menyodok alat ini, saya terkejut menemukan bahwa komunikasi jauh lebih sederhana, lebih ringkas, memberikan struktur toko yang lebih jelas dan pada saat yang sama tidak kalah dalam fleksibilitas. Setelah duduk dan memilah satu jam dengan sumber-sumber dari contoh ke redux-toolkit, saya menulis ulang untuk komunikasi. Saya mencoba membuat minimum perubahan agar lebih mudah melacak perbedaannya, walaupun, menurut saya, struktur contohnya sangat membingungkan. Saya secara khusus meninggalkan komentar pada kode untuk membuatnya lebih mudah untuk membandingkan bagaimana itu dan bagaimana jadinya. Perhatikan file dan irisan * .communication.ts yang mereka ganti.



Fakta bahwa jumlah baris jauh lebih kecil dan kode itu sendiri terlihat jauh lebih menyenangkan (subyektif) tidak begitu penting, karena di prod kami memiliki komunikasi yang cukup berat. Ada satu lagi perbedaan penting. Kode ini bersifat deklaratif. Kami hanya menentukan apa dan di mana kami ingin mendapatkan dan apa yang harus dilakukan dengan data, dan bagaimana melakukannya - kami tidak peduli sama sekali.
Kesimpulan - redux-toolkit harus digunakan untuk penyesuaian, untuk semua yang lain ada MasterCa ... @ axmit / redux-communications .

Untuk meringkas


  • Kode ini menjadi konsisten di semua proyek dan dengan semua pengembang. Masalah serupa diselesaikan secara seragam, dan solusinya sering disampaikan dalam paket terpisah dan digunakan kembali di masa depan. Pada saat yang sama, jumlah kode telah menurun secara signifikan.
  • Juni menerima aliran yang jelas dan dapat dimengerti.
  • Lanjut usia bersukacita bahwa mereka tidak perlu menulis banyak kode boilerplate dan sedang memikirkan cara lain untuk meningkatkan komunikasi.
  • Debugging disederhanakan, dan struktur toko menjadi sederhana dan mudah dipahami oleh setiap pengembang di perusahaan.
  • Transisi antara proyek atau bagian sistem yang berbeda tidak menyebabkan sakit kepala.
  • PM juga senang. Jumlah bug telah menurun - pelanggan puas. Menulis menjadi lebih mudah - pengembang senang. Apa lagi yang dibutuhkan PM untuk kebahagiaan?
  • Anda dapat pindah ke komunikasi secara bertahap atau bahkan menggunakan pendekatan hybrid (komunikasi + irisan).

Tentu saja, perpustakaan juga memiliki kekurangan.

  • Tanpa kode sampel dan dokumentasi, memahaminya cukup sulit.
  • Mengubah struktur toko untuk sewenang-wenang tidak akan berhasil, karena Pada struktur toko itulah semua otomatisasi didasarkan. Tetapi perlu dicatat bahwa dalam pekerjaan kami, kami tidak pernah mengalami kesulitan dengan ini.
  • Anda hanya dapat bekerja dengan saga. Thunk tidak cocok dengan kita, dan kita selalu menggunakan saga, jadi ini bukan masalah bagi kita. Tetapi jika karena alasan tertentu kisah-kisah tidak cocok untuk Anda, maka Anda tidak akan dapat menggunakan perpustakaan.

Saya berharap, terlepas dari kekurangan yang ada, perpustakaan kami akan bermanfaat bagi seseorang. Jika Anda memiliki saran untuk perbaikan atau pertanyaan tentang penggunaannya, silakan menulis, saya akan senang untuk membahasnya.
Jika ada analog yang lebih keren yang tidak dapat kami temukan - beri tahu saya, kami pasti akan mempelajarinya!

Deskripsi lengkap tentang perpustakaan dapat ditemukan di sini , dan cari secara online di sini .

Kode lengkap contoh yang ditulis ulang untuk komunikasi dari dok ReduxToolkit ada di sini , tetapi Anda dapat menyodoknya di sini .

More articles:


All Articles