Hari ini kami memberikan perhatian Anda pada bagian pertama dari terjemahan materi, yang dikhususkan untuk pengembangan aplikasi React skala besar. Saat membuat aplikasi satu halaman menggunakan Bereaksi, sangat mudah untuk mengacaukan basis kodenya. Ini mempersulit proses debug aplikasi, membuatnya sulit untuk memperbarui atau memperpanjang kode proyek.
Ada banyak perpustakaan yang baik dalam ekosistem Bereaksi yang dapat digunakan untuk mengelola aspek-aspek tertentu dari suatu aplikasi. Kami akan membahas beberapa dari mereka dengan detail. Selain itu, beberapa rekomendasi praktis akan diberikan di sini. Jika proyek harus diukur dengan baik, akan sangat berguna untuk mengikuti rekomendasi ini sejak awal bekerja di sana. Di bagian terjemahan ini, kami akan berbicara tentang perencanaan, tindakan, sumber data, dan API. Langkah pertama dalam mengembangkan aplikasi Bereaksi skala besar, yang akan kita lihat, adalah perencanaan.
Bagian 1:
Pedoman praktis untuk mengembangkan aplikasi Bereaksi skala besar. Perencanaan, Tindakan, Sumber Data, dan APIBagian 2:
Pedoman praktis untuk mengembangkan aplikasi Bereaksi skala besar. Bagian 2: manajemen negara, peruteanPerencanaan
Paling sering, pengembang melewatkan tahap kerja pada aplikasi ini. Hal ini disebabkan oleh kenyataan bahwa selama proses perencanaan tidak ada pekerjaan yang dilakukan pada penulisan kode. Tetapi pentingnya langkah ini tidak bisa diremehkan. Anda akan segera belajar mengapa demikian.
▍Mengapa Anda berencana ketika mengembangkan aplikasi?
Pengembangan perangkat lunak membutuhkan koordinasi banyak proses. Pada saat yang sama, semuanya sangat mudah bisa lepas kendali. Hambatan dan ketidakpastian yang ditemukan dalam proses pengembangan dapat membahayakan waktu proyek.
Membantu memenuhi tenggat waktu adalah tahap perencanaan proyek yang dapat membantu Anda. Pada tahap ini, "berbaring di rak" semua fitur yang harus dimiliki aplikasi. Jauh lebih mudah untuk memperkirakan berapa lama waktu yang dibutuhkan untuk membuat modul individual kecil, daftar yang ada di tangan programmer, daripada mencoba, dalam pikiran, untuk memperkirakan ketentuan pengembangan seluruh proyek.
Jika beberapa programmer mengambil bagian dalam proyek besar (seperti biasanya terjadi), maka kehadiran rencana pra-dikembangkan, dokumen tertentu, akan sangat memudahkan interaksi mereka satu sama lain. Bahkan, berbagai tugas yang dirumuskan dalam dokumen ini dapat ditugaskan untuk masing-masing pengembang. Kehadirannya akan membantu anggota tim untuk mengetahui apa yang dilakukan rekan mereka.
Dan akhirnya, berkat dokumen ini, Anda dapat melihat dengan jelas bagaimana kemajuan proyek ini. Pemrogram sering berpindah dari mengerjakan satu bagian aplikasi ke yang lain, dan kembali ke apa yang mereka lakukan sebelumnya, lebih lama dari yang mereka inginkan.
Pertimbangkan proses perencanaan aplikasi.
▍Langkah 1: halaman dan komponen
Hal ini diperlukan untuk menentukan tampilan dan fungsionalitas setiap halaman aplikasi. Salah satu pendekatan terbaik di sini adalah menggambar setiap halaman. Anda dapat melakukan ini baik menggunakan
alat mockup , atau secara manual di atas kertas. Ini akan memberi Anda pemahaman yang baik tentang informasi apa yang harus ada pada setiap halaman. Inilah tampilan tata letak halaman.
Tata Letak Halaman (diambil dari sini )Dalam tata letak di atas, Anda dapat dengan mudah mengidentifikasi entitas wadah induk dan anak-anaknya. Nantinya, wadah induk akan menjadi halaman aplikasi, dan elemen yang lebih kecil akan jatuh ke folder
components proyek. Setelah Anda selesai menggambar layout - tulis masing-masing nama-nama halaman dan komponen.
▍Langkah 2: tindakan dan peristiwa
Setelah Anda memutuskan komponen aplikasi, pikirkan tindakan apa yang akan dilakukan pada masing-masing komponen. Nantinya, dari komponen ini, tindakan ini akan dikirim.
Pertimbangkan toko online di halaman beranda yang menampilkan daftar produk yang direkomendasikan. Setiap elemen dari daftar ini akan disajikan dalam proyek sebagai komponen terpisah. Biarkan nama komponen ini menjadi
ListItem .
Contoh beranda toko online (diambil dari sini )Dalam aplikasi ini, tindakan yang dilakukan komponen pada bagian
Product disebut
getItems . Beberapa aktivitas lain yang mungkin dimasukkan pada halaman ini mungkin termasuk
getUserDetails ,
getSearchResults , dan sebagainya.
▍Langkah 3: data dan model
Ada beberapa data yang terkait dengan masing-masing komponen aplikasi. Jika data yang sama digunakan oleh beberapa komponen aplikasi, maka mereka akan menjadi bagian dari pohon negara terpusat. Pohon negara dikelola menggunakan
Redux .
Data ini digunakan oleh banyak komponen. Akibatnya, ketika data diubah oleh satu komponen, itu tercermin dalam komponen lain.
Buat daftar data serupa untuk aplikasi Anda. Ini akan menjadi diagram model. Berdasarkan daftar ini, akan dimungkinkan untuk membuat reduksi.
products: { productId: {productId, productName, category, image, price}, productId: {productId, productName, category, image, price}, productId: {productId, productName, category, image, price}, }
Mari kita kembali ke contoh di atas dengan toko online. Bagian produk yang direkomendasikan dan produk baru menggunakan tipe data yang sama yang digunakan untuk mewakili produk individual (seperti
product ). Jenis ini akan berfungsi sebagai dasar untuk membuat salah satu reduksi aplikasi.
Setelah mendokumentasikan rencana tindakan, saatnya untuk mempertimbangkan beberapa detail yang diperlukan untuk mengatur lapisan aplikasi yang bertanggung jawab untuk bekerja dengan data.
Tindakan, Sumber Data, dan API
Ketika aplikasi Anda tumbuh, sering terjadi bahwa sejumlah besar metode dikaitkan dengan repositori Redux. Kebetulan struktur direktori semakin memburuk, menyimpang dari kebutuhan nyata aplikasi. Semua ini menjadi sulit dipertahankan, menambahkan fitur-fitur baru pada aplikasi menjadi lebih rumit.
Mari kita bicara tentang bagaimana Anda dapat menyesuaikan beberapa hal untuk menjaga kode repositori Redux tetap bersih dalam jangka panjang. Banyak masalah dapat dihindari jika, dari awal, modul dibuat agar sesuai untuk digunakan kembali. Layak untuk melakukan hal itu, meskipun pada awalnya mungkin tampak seperti kelebihan, tidak perlu menyulitkan proyek.
▍ Desain API dan Aplikasi Klien
Selama penyiapan awal penyimpanan, format data yang berasal dari API sangat memengaruhi struktur penyimpanan. Seringkali, data harus dikonversi sebelum dapat ditransfer ke reduksi.
Baru-baru ini,
banyak yang telah dikatakan tentang apa yang dibutuhkan dan apa yang tidak perlu dilakukan ketika merancang API. Faktor-faktor seperti kerangka kerja backend dan ukuran aplikasi memiliki dampak tambahan pada bagaimana API dirancang.
Dianjurkan, seperti dalam pengembangan aplikasi server, untuk menyimpan fungsi tambahan dalam folder terpisah. Ini mungkin, misalnya, fungsi untuk memformat dan memetakan data. Pastikan bahwa fungsi-fungsi ini tidak memiliki efek samping (lihat artikel
ini pada fungsi murni).
export function formatTweet (tweet, author, authedUser, parentTweet) { const { id, likes, replies, text, timestamp } = tweet const { name, avatarURL } = author return { name, id, timestamp, text, avatar: avatarURL, likes: likes.length, replies: replies.length, hasLiked: likes.includes(authedUser), parent: !parentTweet ? null : { author: parentTweet.author, id: parentTweet.id, }
Dalam contoh kode ini, fungsi
formatTweet menambahkan kunci baru (
parent ) ke objek tweet dari aplikasi front-end. Fungsi ini mengembalikan data berdasarkan parameter yang diteruskan ke sana, tanpa memengaruhi data di luarnya.
Di sini Anda dapat melangkah lebih jauh dengan memetakan data ke objek yang dijelaskan sebelumnya yang strukturnya sesuai dengan kebutuhan aplikasi front-end Anda. Namun, Anda dapat memvalidasi beberapa kunci.
Sekarang mari kita bicara tentang bagian-bagian aplikasi yang bertanggung jawab untuk melakukan panggilan ke
API .
▍ Organisasi kerja dengan sumber data
Apa yang akan kita bicarakan di bagian ini akan langsung digunakan oleh Redux untuk mengubah keadaan aplikasi. Bergantung pada ukuran aplikasi (dan, di samping itu, pada waktu yang dimiliki oleh programmer), Anda dapat mendekati desain gudang data menggunakan salah satu dari dua pendekatan berikut:
- Tanpa menggunakan agen (kurir).
- Menggunakan agen
▍ Merancang repositori tanpa menggunakan agen
Dengan pendekatan ini, selama konfigurasi penyimpanan, mekanisme untuk mengeksekusi
GET ,
POST dan permintaan
PUT untuk setiap model dibuat secara terpisah.
Komponen berinteraksi dengan API tanpa menggunakan agenDiagram sebelumnya menunjukkan bahwa setiap komponen mengirimkan tindakan yang memanggil metode dari penyimpanan data yang berbeda. Begini caranya, dengan pendekatan ini, metode
updateBlog dari file
BlogApi akan terlihat:
function updateBlog(blog){ let blog_object = new BlogModel(blog) axios.put('/blog', { ...blog_object }) .then(function (response) { console.log(response); }) .catch(function (error) { console.log(error); }); }
Pendekatan ini menghemat waktu ... Dan pada awalnya itu juga memungkinkan Anda untuk membuat perubahan pada kode tanpa khawatir tentang efek samping. Tetapi karena ini, proyek akan memiliki sejumlah besar kode berlebihan. Selain itu, melakukan operasi pada kelompok objek akan membutuhkan banyak waktu.
▍ Merancang repositori menggunakan agen
Dengan pendekatan ini, dalam jangka panjang, proyek lebih mudah dipertahankan, lebih mudah untuk melakukan perubahan. Basis kode tidak menjadi tercemar dari waktu ke waktu, karena pengembang terhindar dari masalah menjalankan permintaan paralel menggunakan aksioma.
Komponen berinteraksi dengan API menggunakan agenNamun, dengan pendekatan ini, sejumlah waktu diperlukan untuk pengaturan awal sistem. Dia kurang fleksibel. Ini baik dan buruk, karena tidak memungkinkan pengembang untuk melakukan sesuatu yang tidak biasa.
export default function courier(query, payload) { let path = `${SITE_URL}`; path += `/${query.model}`; if (query.id) path += `/${query.id}`; if (query.url) path += `/${query.url}`; if (query.var) path += `?${QueryString.stringify(query.var)}`; return axios({ url: path, ...payload }) .then(response => response) .catch(error => ({ error })); }
Kode untuk metode
courier dasar
courier . Semua penangan API dapat memanggilnya, mengirimkannya data berikut:
- Minta objek yang berisi informasi terkait URL. Misalnya, nama model, string kueri, dan sebagainya.
- Payload berisi header permintaan dan tubuhnya.
▍ Panggilan API dan tindakan internal aplikasi
Saat bekerja dengan Redux, perhatian khusus diberikan pada penggunaan tindakan yang telah ditentukan sebelumnya. Ini membuat perubahan data yang terjadi dalam aplikasi dapat diprediksi.
Menentukan sejumlah besar konstanta dalam aplikasi besar mungkin tampak seperti tugas yang mustahil. Namun, pelaksanaan tugas ini sangat disederhanakan berkat fase perencanaan yang telah kami ulas sebelumnya.
export const BOOK_ACTIONS = { GET:'GET_BOOK', LIST:'GET_BOOKS', POST:'POST_BOOK', UPDATE:'UPDATE_BOOK', DELETE:'DELETE_BOOK', } export function createBook(book) { return { type: BOOK_ACTIONS.POST, book } export function handleCreateBook (book) { return (dispatch) => { return createBookAPI(book) .then(() => { dispatch(createBook(book)) }) .catch((e) => { console.warn('error in creating book', e); alert('Error Creating book') }) } export default { handleCreateBook, }
Cuplikan kode di atas menunjukkan cara sederhana untuk menggunakan metode sumber data
createBookApi dengan tindakan Redux. Metode
createBook dapat dengan mudah diteruskan ke metode
dispatch Redux.
Selain itu, perhatikan bahwa kode ini disimpan dalam folder tempat file tindakan proyek disimpan. Demikian pula, Anda dapat membuat file JavaScript yang menyatakan tindakan dan penangan untuk model aplikasi lainnya.
Ringkasan
Hari ini kita berbicara tentang peran fase perencanaan dalam pengembangan proyek skala besar. Kami juga membahas di sini fitur-fitur organisasi aplikasi dengan sumber data. Bagian selanjutnya dalam artikel ini akan fokus pada pengelolaan keadaan aplikasi dan pengembangan antarmuka pengguna yang dapat diskalakan.
Pembaca yang budiman! Di mana Anda mulai mengembangkan aplikasi Bereaksi?
