Ketika datang untuk mengembangkan aplikasi Bereaksi, dalam hal arsitektur kode, proyek kecil seringkali lebih fleksibel daripada yang besar. Tidak ada yang salah dengan membuat proyek seperti itu menggunakan pedoman praktis yang ditujukan untuk aplikasi yang lebih besar. Tetapi semua ini, dalam kasus proyek-proyek kecil, mungkin sama sekali tidak perlu. Semakin kecil aplikasinya, semakin "merendahkan" itu merujuk pada penggunaan solusi sederhana di dalamnya, mungkin tidak optimal, tetapi tidak memerlukan banyak waktu untuk implementasinya.
Meskipun demikian, saya ingin mencatat bahwa beberapa rekomendasi yang akan diberikan dalam materi ini ditujukan untuk Bereaksi aplikasi skala apa pun.
Jika Anda belum pernah membuat aplikasi produksi, maka artikel ini dapat membantu Anda mempersiapkan pengembangan solusi skala besar. Sesuatu seperti ini bisa menjadi salah satu proyek Anda selanjutnya. Hal terburuk yang dapat terjadi pada seorang programmer adalah ketika dia bekerja pada sebuah proyek dan menyadari bahwa dia perlu memperbaiki sejumlah besar kode untuk meningkatkan skalabilitas dan rawatan aplikasi. Semuanya terlihat lebih buruk jika tidak ada unit test di proyek sebelum refactoring.
Penulis materi ini meminta pembaca untuk mengambil kata-katanya untuk itu. Dia berada dalam situasi yang sama. Jadi, dia mendapat beberapa tugas yang perlu diselesaikan dalam waktu tertentu. Pada awalnya, dia berpikir bahwa semua yang dia lakukan sangat bagus. Sumber pemikiran tersebut adalah bahwa aplikasi webnya, setelah melakukan perubahan, terus bekerja, dan pada saat yang sama terus bekerja dengan cepat. Dia tahu bagaimana menggunakan Redux, bagaimana membangun interaksi normal antara komponen antarmuka pengguna. Baginya, dia sangat memahami konsep reduksi dan tindakan. Dia merasa kebal.
Tapi di sini masa depan merayap.
Setelah beberapa bulan mengerjakan aplikasi, lebih dari 15 fitur baru ditambahkan. Setelah itu, proyek menjadi tidak terkendali. Kode yang menggunakan pustaka Redux menjadi sangat sulit dipelihara. Mengapa ini terjadi? Pada awalnya, bukankah proyek itu tampak seperti kehidupan yang panjang dan tak berawan?
Penulis artikel itu mengatakan bahwa, dengan mengajukan pertanyaan serupa, ia menyadari bahwa ia telah menanam bom waktu di proyek itu dengan tangannya sendiri.
Pustaka Redux, jika digunakan dengan benar dalam proyek-proyek besar, membantu, ketika proyek tersebut tumbuh, untuk menjaga kode mereka dalam keadaan yang didukung.
Berikut adalah 11 tips untuk mereka yang ingin mengembangkan aplikasi Bereaksi scalable menggunakan Redux.
1. Jangan letakkan kode tindakan dan konstanta di satu tempat
Anda mungkin menemukan beberapa tutorial Redux di mana konstanta dan semua tindakan ditempatkan di tempat yang sama. Namun, pendekatan ini, seiring pertumbuhan aplikasi, dapat dengan cepat menyebabkan masalah. Konstanta perlu disimpan secara terpisah, misalnya di
./src/constants . Akibatnya, untuk mencari konstanta, Anda harus melihat hanya satu folder, dan tidak beberapa.
Selain itu, pembuatan file terpisah yang menyimpan tindakan terlihat sangat normal. File-file tersebut merangkum tindakan yang berhubungan langsung satu sama lain. Tindakan dalam satu file, misalnya, mungkin memiliki kesamaan dalam hal apa dan bagaimana mereka digunakan.
Misalkan Anda sedang mengembangkan permainan arcade atau permainan peran dan menciptakan kelas
warrior (prajurit),
sorceress (penyihir) dan
archer (pemanah). Dalam situasi seperti itu, Anda dapat mencapai dukungan kode tingkat tinggi dengan mengatur tindakan sebagai berikut:
src/actions/warrior.js src/actions/sorceress.js src/actions/archer.js
Akan jauh lebih buruk jika semuanya jatuh ke dalam satu file:
src/actions/classes.js
Jika aplikasi menjadi sangat besar, maka mungkin lebih baik menggunakan kira-kira struktur pemecah kode berikut menjadi file:
src/actions/warrior/skills.js src/actions/sorceress/skills.js src/actions/archer/skills.js
Hanya sebagian kecil dari struktur seperti itu yang ditampilkan di sini. Jika Anda berpikir lebih luas dan konsisten menggunakan pendekatan ini, Anda akan berakhir dengan sesuatu seperti kumpulan file ini:
src/actions/warrior/skills.js src/actions/warrior/quests.js src/actions/warrior/equipping.js src/actions/sorceress/skills.js src/actions/sorceress/quests.js src/actions/sorceress/equipping.js src/actions/archer/skills.js src/actions/archer/quests.js src/actions/archer/equipping.js
Inilah yang terlihat dari file
src/actions/sorceress/skills untuk objek
sorceress :
import { CAST_FIRE_TORNADO, CAST_LIGHTNING_BOLT } from '../constants/sorceress' export const castFireTornado = (target) => ({ type: CAST_FIRE_TORNADO, target, }) export const castLightningBolt = (target) => ({ type: CAST_LIGHTNING_BOLT, target, })
Berikut adalah isi dari file
src/actions/sorceress/equipping :
import * as consts from '../constants/sorceress' export const equipStaff = (staff, enhancements) => {...} export const removeStaff = (staff) => {...} export const upgradeStaff = (slot, enhancements) => { return (dispatch, getState, { api }) => {
Alasan kami mengatur kode dengan cara ini adalah karena fitur baru terus ditambahkan ke proyek. Ini berarti bahwa kita perlu bersiap untuk penampilan mereka dan pada saat yang sama berusaha untuk memastikan bahwa file tidak dibebani dengan kode.
Pada awal pekerjaan pada proyek, ini mungkin tampak tidak perlu. Tetapi semakin besar proyek itu, semakin kuat kekuatan pendekatan semacam itu akan terasa.
2. Jangan letakkan kode peredam di satu tempat
Ketika saya melihat bahwa kode reduksi saya berubah menjadi sesuatu yang mirip dengan yang ditunjukkan di bawah ini, saya mengerti bahwa saya perlu mengubah sesuatu.
const equipmentReducers = (state, action) => { switch (action.type) { case consts.UPGRADING_STAFF: return { ...state, classes: { ...state.classes, sorceress: { ...state.classes.sorceress, equipment: { ...state.classes.sorceress.equipment, isUpgrading: action.slot, }, }, }, } case consts.UPGRADED_STAFF: return { ...state, classes: { ...state.classes, sorceress: { ...state.classes.sorceress, equipment: { ...state.classes.sorceress.equipment, isUpgrading: null, current: { ...state.classes.sorceress.equipment.current, [action.slot]: action.staff, }, }, }, }, } case consts.UPGRADE_STAFF_FAILED: return { ...state, classes: { ...state.classes, sorceress: { ...state.classes.sorceress, equipment: { ...state.classes.sorceress.equipment, isUpgrading: null, }, }, }, } default: return state } }
Kode seperti itu, tidak diragukan lagi, dapat dengan cepat menyebabkan banyak kekacauan. Oleh karena itu, yang terbaik adalah mempertahankan struktur kerja dengan negara dalam bentuk yang sesederhana mungkin, dengan tujuan pada tingkat minimum sarang mereka. Sebagai gantinya, Anda dapat mencoba menggunakan komposisi reduksi.
Trik yang berguna dalam bekerja dengan reduksi adalah membuat peredam dengan urutan lebih tinggi yang dihasilkan pereduksi lainnya. Baca lebih lanjut di sini.
3. Gunakan nama variabel informatif
Variabel penamaan, pada pandangan pertama, mungkin tampak seperti tugas dasar. Namun pada kenyataannya, tugas ini mungkin salah satu yang paling sulit.
Pemilihan nama variabel umumnya relevan dengan pedoman praktis untuk menulis kode bersih. Alasan mengapa ada yang namanya "nama variabel" secara umum adalah karena aspek pengembangan kode ini memainkan peran yang sangat penting dalam praktik. Pemilihan nama variabel yang tidak berhasil adalah cara yang pasti untuk membahayakan diri Anda dan anggota tim Anda di masa depan.
Pernahkah Anda mencoba mengedit kode orang lain dan pada saat yang sama mengalami kesulitan dalam memahami apa sebenarnya kode ini? Pernahkah Anda menjalankan program asing dan ternyata tidak berjalan seperti yang diharapkan?
Saya berpendapat untuk membuktikan bahwa dalam kasus seperti itu Anda telah menemukan apa yang disebut "kode kotor".
Jika Anda harus berurusan dengan kode serupa dalam aplikasi besar, maka ini hanya mimpi buruk. Sayangnya, ini sering terjadi.
Ini satu kasus dari kehidupan. Saya mengedit kode kait Bereaksi dari satu aplikasi dan pada saat itu mereka mengirim saya tugas. Itu untuk menerapkan dalam aplikasi kemampuan untuk menampilkan informasi tambahan tentang dokter. Informasi ini seharusnya ditunjukkan kepada pasien yang mengklik gambar profil dokter. Itu perlu untuk mengambilnya dari tabel, itu harus sampai ke klien setelah memproses permintaan berikutnya ke server.
Ini bukan tugas yang sulit, masalah utama yang saya temui adalah bahwa saya harus menghabiskan terlalu banyak waktu untuk menemukan di mana tepatnya apa yang saya butuhkan berada dalam kode proyek.
Saya mencari kode di
info kata,
dataToSend ,
dataObject , dan untuk orang lain yang, menurut
dataObject saya, terkait dengan data yang diterima dari server. Setelah 5-10 menit, saya berhasil menemukan kode yang bertanggung jawab untuk bekerja dengan data yang saya butuhkan. Objek tempat mereka berakhir disebut
paymentObject . Menurut pendapat saya, objek yang terkait dengan pembayaran dapat berisi sesuatu seperti kode CVV, nomor kartu kredit, kode pos pembayar, dan informasi serupa lainnya. Objek yang saya temukan memiliki 11 properti. Hanya tiga di antaranya yang terkait dengan pembayaran: metode pembayaran, pengidentifikasi profil pembayaran, dan daftar kode kupon.
Situasi tidak membaik juga karena saya harus membuat perubahan pada objek ini yang diminta untuk menyelesaikan tugas sebelum saya.
Singkatnya, Anda disarankan untuk tidak menggunakan nama yang tidak jelas untuk fungsi dan variabel. Berikut adalah contoh kode di mana nama fungsi
notify tidak mengungkapkan artinya:
import React from 'react' class App extends React.Component { state = { data: null }
4. Jangan mengubah struktur atau tipe data dalam aliran data aplikasi yang sudah dikonfigurasi
Salah satu kesalahan terbesar yang pernah saya buat adalah mengubah struktur data dalam aliran data aplikasi yang sudah dikonfigurasi. Struktur data baru akan membawa peningkatan kinerja yang sangat besar, karena menggunakan metode cepat untuk mencari data dalam objek yang disimpan dalam memori, alih-alih beralih pada array. Tapi sudah terlambat.
Saya meminta Anda untuk tidak melakukan ini. Mungkin sesuatu seperti ini hanya dapat diberikan kepada seseorang yang tahu persis bagian mana dari aplikasi ini yang dapat mempengaruhi.
Apa konsekuensi dari langkah seperti itu? Misalnya, jika sesuatu pertama adalah sebuah array, dan kemudian menjadi objek, ini dapat mengganggu operasi banyak bagian aplikasi. Saya membuat kesalahan besar dengan meyakini bahwa saya dapat mengingat semua tempat dalam kode yang dapat dipengaruhi oleh perubahan dalam penyajian data terstruktur. Namun, dalam kasus seperti itu, selalu ada beberapa kode yang dipengaruhi oleh perubahan, dan yang tidak ada yang ingat.
5. Gunakan potongan
Saya dulu adalah penggemar editor Atom, tetapi beralih ke VS Code karena fakta bahwa editor ini sangat cepat dibandingkan dengan Atom. Dan dia, dengan kecepatannya, mendukung sejumlah besar kemungkinan yang berbeda.
Jika Anda juga menggunakan Kode VS, saya sarankan untuk menginstal
ekstensi Project Snippets . Ekstensi ini memungkinkan pemrogram untuk membuat cuplikan khusus untuk setiap ruang kerja yang digunakan dalam suatu proyek. Ekstensi ini bekerja dengan cara yang sama seperti mekanisme Use Snippets yang dibangun dalam VS Code. Perbedaannya adalah ketika bekerja dengan Project Snippets,
.vscode/snippets/ dibuat di proyek. Tampak seperti gambar berikut.
Isi folder .vscode / snippets /6. Buat unit, end-to-end dan tes integrasi
Ketika ukuran aplikasi bertambah, menjadi lebih menakutkan bagi programmer untuk mengedit kode yang tidak tercakup oleh tes. Sebagai contoh, mungkin saja seseorang mengedit kode yang disimpan di
src/x/y/z/ dan memutuskan untuk mengirimkannya ke produksi. Jika pada saat yang sama perubahan yang dilakukan mempengaruhi bagian-bagian proyek yang tidak dipikirkan oleh pemrogram, maka semuanya dapat berakhir dengan kesalahan yang akan ditemui pengguna nyata. Jika ada tes dalam proyek, programmer akan tahu tentang kesalahan jauh sebelum kode mulai diproduksi.
7. Brainstorm
Programmer, dalam proses memperkenalkan fitur baru ke dalam proyek, sering menolak untuk bertukar pikiran. Ini terjadi karena aktivitas semacam itu tidak terkait dengan penulisan kode. Ini sering terjadi terutama ketika sangat sedikit waktu yang dialokasikan untuk tugas tersebut.
Dan mengapa, Anda harus melakukan brainstorming selama pengembangan aplikasi?
Faktanya adalah bahwa semakin kompleks aplikasi menjadi, semakin banyak perhatian programmer harus membayar ke bagian masing-masing. Brainstorming membantu mengurangi waktu yang diperlukan untuk memperbaiki kode. Setelah diadakan, programmer dipersenjatai dengan pengetahuan tentang apa yang mungkin salah selama penyelesaian proyek. Seringkali programmer, saat mengembangkan aplikasi, bahkan tidak repot-repot memikirkan setidaknya sedikit tentang bagaimana melakukan segala sesuatu dengan cara terbaik.
Itulah mengapa brainstorming sangat penting. Selama acara semacam itu, programmer dapat mempertimbangkan arsitektur kode, berpikir tentang bagaimana membuat perubahan yang diperlukan untuk program, melacak siklus hidup dari perubahan ini, dan membuat strategi untuk bekerja dengannya. Tidaklah layak untuk memulai kebiasaan menjaga semua rencana secara eksklusif di kepala Anda sendiri. Inilah yang dilakukan oleh programmer yang terlalu percaya diri. Tetapi mengingat sepenuhnya semuanya tidak mungkin. Dan, begitu sesuatu terjadi kesalahan, masalah akan muncul satu demi satu. Ini adalah prinsip domino dalam aksi.
Brainstorming juga berguna dalam tim. Misalnya, jika dalam pekerjaan seseorang mengalami masalah, ia dapat beralih ke materi sesi curah pendapat, karena masalah yang muncul bersamanya mungkin sudah dipertimbangkan. Catatan yang dibuat selama sesi curah pendapat mungkin memainkan peran rencana untuk memecahkan masalah. Paket ini memungkinkan Anda menilai dengan jelas jumlah pekerjaan yang dilakukan.
8. Buat aplikasi mockup
Jika Anda akan mulai mengembangkan aplikasi, Anda perlu membuat keputusan tentang bagaimana tampilannya dan bagaimana pengguna akan berinteraksi dengannya. Ini berarti bahwa Anda perlu membuat tata letak aplikasi. Anda dapat menggunakan berbagai alat untuk ini.
Moqups adalah salah satu alat
aplikasi mockup yang sering saya dengar. Ini adalah alat cepat yang dibuat menggunakan HTML5 dan JavaScript dan tidak memaksakan persyaratan khusus pada sistem.
Membuat aplikasi tiruan sangat menyederhanakan dan mempercepat proses pengembangan. Tata letak memberikan informasi kepada pengembang tentang hubungan antara masing-masing bagian aplikasi, dan tentang jenis data apa yang akan ditampilkan pada halaman-halamannya.
9. Rencanakan aliran data dalam aplikasi
Hampir setiap komponen aplikasi Anda akan dikaitkan dengan beberapa data. Beberapa komponen akan menggunakan sumber data mereka sendiri, tetapi sebagian besar komponen menerima data dari entitas di atasnya dalam hierarki komponen. Untuk bagian-bagian aplikasi di mana data yang sama dibagi oleh beberapa komponen, ada baiknya untuk menyediakan beberapa penyimpanan informasi terpusat yang terletak di tingkat atas hirarki. Dalam situasi seperti itu perpustakaan
Redux dapat memberikan bantuan yang sangat berharga bagi pengembang.
Saya merekomendasikan hal ini saat mengerjakan aplikasi, buat diagram yang menunjukkan cara data bergerak dalam aplikasi ini. Ini akan membantu dalam membuat model aplikasi yang jelas, apalagi, kita berbicara tentang kode dan persepsi aplikasi oleh programmer. Model seperti itu akan membantu, di samping itu, dalam penciptaan reduksi.
10. Gunakan fitur akses data
Ketika ukuran aplikasi bertambah, jumlah komponen juga bertambah. Dan ketika jumlah komponen bertambah, hal yang sama terjadi dengan frekuensi menggunakan penyeleksi (react-redux ^ v7.1) atau
mapStateToProps . Misalkan Anda menemukan bahwa komponen atau kait Anda sering mengakses fragmen status di berbagai bagian aplikasi menggunakan konstruk seperti
useSelector((state) => state.app.user.profile.demographics.languages.main) . Jika demikian, itu berarti Anda harus berpikir tentang membuat fungsi akses data. File dengan fungsi seperti itu harus disimpan di tempat umum tempat komponen dan kait dapat mengimpornya. Fungsi serupa dapat berupa filter, parser, atau fungsi lain untuk transformasi data.
Berikut ini beberapa contohnya.
Sebagai contoh,
src/accessors mungkin berisi kode berikut:
export const getMainLanguages = (state) => state.app.user.profile.demographics.languages.main
Ini adalah versi menggunakan
connect , yang dapat ditemukan di sepanjang jalur
src/components/ViewUserLanguages :
import React from 'react' import { connect } from 'react-redux' import { getMainLanguages } from '../accessors' const ViewUserLanguages = ({ mainLanguages }) => ( <div> <h1>Good Morning.</h1> <small>Here are your main languages:</small> <hr /> {mainLanguages.map((lang) => ( <div>{lang}</div> ))} </div> ) export default connect((state) => ({ mainLanguages: getMainLanguages(state), }))(ViewUserLanguages)
Berikut adalah versi yang menggunakan
useSelector terletak di
src/components/ViewUserLanguages :
import React from 'react' import { useSelector } from 'react-redux' import { getMainLanguages } from '../accessors' const ViewUserLanguages = ({ mainLanguages }) => { const mainLanguages = useSelector(getMainLanguages) return ( <div> <h1>Good Morning.</h1> <small>Here are your main languages:</small> <hr /> {mainLanguages.map((lang) => ( <div>{lang}</div> ))} </div> ) } export default ViewUserLanguages
Selain itu, berusahalah untuk memastikan bahwa fungsi-fungsi tersebut tidak berubah, tanpa efek samping. Cari tahu mengapa saya memberikan rekomendasi seperti ini di
sini .
11. Kontrol aliran data dalam properti menggunakan destrukturisasi dan sebarkan sintaks
Apa manfaat menggunakan
props.something membangun di atas
something membangun?
Begini tampilannya tanpa menggunakan perusakan:
const Display = (props) => <div>{props.something}</div>
Di sini sama, tetapi dengan penggunaan destrukturisasi:
const Display = ({ something }) => <div>{something}</div>
Menggunakan destrukturisasi meningkatkan keterbacaan kode. Tetapi ini tidak membatasi dampak positifnya pada proyek. Menggunakan destrrukturisasi, programmer dipaksa untuk membuat keputusan tentang apa yang sebenarnya diterima komponen dan apa yang sebenarnya dihasilkannya. Ini menyelamatkan siapa saja yang harus mengedit kode orang lain karena harus melihat setiap baris metode
render untuk mencari semua properti yang digunakan komponen.
Selain itu, pendekatan ini memberikan peluang yang berguna untuk menetapkan nilai properti default. Ini dilakukan di awal kode komponen dan menghilangkan keharusan untuk menulis kode tambahan di badan komponen:
const Display = ({ something = 'apple' }) => <div>{something}</div>
Anda mungkin telah melihat sesuatu seperti contoh berikut sebelumnya:
const Display = (props) => ( <Agenda {...props}> {' '} // Agenda <h2><font color="#3AC1EF">Today is {props.date}</font></h2> <hr /> <div> <h3><font color="#3AC1EF">▍Here your list of todos:</font></h3> {props.children} </div> </Agenda> )
Konstruksi seperti itu tidak mudah dibaca, tetapi ini bukan satu-satunya masalah mereka. Jadi, ada kesalahan. Jika aplikasi juga menampilkan komponen anak, maka
props.children ditampilkan di layar dua kali. Jika pekerjaan pada proyek dilakukan dalam tim dan anggota tim tidak cukup hati-hati, kemungkinan kesalahan seperti itu cukup tinggi.
Jika Anda merusak properti, kode komponen akan lebih jelas, dan kemungkinan kesalahan akan berkurang:
const Display = ({ children, date, ...props }) => ( <Agenda {...props}> {' '} // Agenda <h2><font color="#3AC1EF">Today is {date}</font></h2> <hr /> <div> <h3><font color="#3AC1EF">▍Here your list of todos:</font></h3> {children} </div> </Agenda> )
Ringkasan
Dalam artikel ini, kami meninjau 12 rekomendasi untuk mereka yang mengembangkan aplikasi Bereaksi menggunakan Redux. Kami harap Anda menemukan sesuatu di sini yang bermanfaat bagi Anda.
Pembaca yang budiman! Kiat apa yang akan Anda tambahkan ke yang ada di artikel ini?
